From nobody Tue Jan 5 01:36:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5521AD0C1 for ; Tue, 5 Jan 2016 01:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czbhy8ak4G1P for ; Tue, 5 Jan 2016 01:36:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E132E1AD0BE for ; Tue, 5 Jan 2016 01:36:44 -0800 (PST) Received: from [192.168.10.141] ([80.92.119.18]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LikQP-1ZffFP3nzR-00cw9b for ; Tue, 05 Jan 2016 10:36:43 +0100 To: "oauth@ietf.org" References: <5672DBE7.30101@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <568B8EAA.5080404@gmx.net> Date: Tue, 5 Jan 2016 10:36:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5672DBE7.30101@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="X3bj2UDp6Pllo3ltOhiKf3Ck9tHlwoKko" X-Provags-ID: V03:K0:+aJxFPg6UZqAW+jsHf5K5paW5vl0SotilS1qcloigQ3pxA9zUWY oUU9yjAKokNllfBUbdGRRSQnwJbI8zO2hOWrvcc06lNHaW8pE7d5awHgOCkDihEK+NMBaW+ /qvhtCv+rTkjcil+rmEfbrdX0Id2Z0+mC/uJqIAX3DuJj7UY+7ilcUAU4z8cD3FZHqmiqib xQlzK+jVQgN64wd+PAS1A== X-UI-Out-Filterresults: notjunk:1;V01:K0:vNFSBItx1X0=:2ShBpstf4Y9JInASvMiD1h O9qRjZeMgF4L6NOWEKbDxZxTW2fsZUIgaFry7UBe8F8F6w3K5pFFrPO5yEchq98zLBTSTwrs1 tqnQsbmfqFLGFQqe80RfX4oVXadiXyU4J0f0Q6KeFbMcMn+qF8iEDCMXNTE2pN2puaph2nX8n YYDWBoQCFB5pGUFEdCGWAP3ajQVWd3kZSg9i7G8pyIHEC++GBGd9U4TnI9NykXsQB0bzsh302 Ir+lQVTA99oVgsWVypMs2V31dHmadgNXF6KAoZTo2dcwhsT0XFz1kTVK4ebYL1h6ff7VdCp1+ sEE+b+D6srS7UDMhw887lPhEqGFDNynamh+iUnCsnIW263neY/33KxbklOVODiv43NvShbiLe nI5scxs2mdDaPs5FtWQ7h8iZegaMmkHEos0T3d+pHtujrJ8RdXTfg16nhJiXzmBmvmEKr+N/d RKeEymg3G7Gms+BQx2Oa/9fZnZnDtiC0YitJJTiZBhj2DoSdQMEnBl/dTY+RYTH8uBor08ome 9brrWD21/CkYGyPoJCiUO/OMs2xpXKG6yxb17wGn1GljgkqRrYzr1lPRxr+haM2Khw+coGkhm /KgVMP9P/J9cwPP/BRhYidlxwS7w9jfgoN1Ov3olQJCkUnquZXR7rlu0Iftz+r80geswOPpyt NgLBeujJgbByUgAGhovk82B8d6v87xQeKpj9F/qEeaU/xAW/sLI1Cp9JzhsAvyUng7gZUvMY/ e7d1YghB4icAcESzYNgxB5dciLWMokLdLqH3zGIaifYAJFR8OC4vAyKfDIQ= Archived-At: Subject: Re: [OAUTH-WG] OAuth Recharting X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 09:36:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X3bj2UDp6Pllo3ltOhiKf3Ck9tHlwoKko Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would like to bring this item to your attention again since it may have gotten lost due to the holidays. Please let us know whether you have some additional remarks for the new OAuth charter text. I believe the charter text is phrases generic enough to cover the items we have been talking about in 2015. I will post a few additional mails about the specifications I believe should be dealt with in 2016. Ciao Hannes & Derek On 12/17/2015 04:59 PM, Hannes Tschofenig wrote: > Hi all, >=20 > at the last IETF meeting in Yokohama we had a rechartering discussion > and below is proposed text for the new charter. Please take a look at i= t > and tell me whether it appropriately covers the discussions from our > last meeting. >=20 > --------------- >=20 > Charter Text >=20 > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. >=20 > The OAuth 2.0 protocol suite already includes >=20 > * a procedure for enabling a client to register with an authorization > server, > * a protocol for obtaining authorization tokens from an authorization > server with the resource owner's consent, and > * protocols for presenting these authorization tokens to protected > resources for access to a resource. >=20 > This protocol suite has been enhanced with functionality for > interworking with legacy identity infrastructure (e.g., SAML), token > revocation, token exchange, dynamic client registration, token > introspection, a standardized token format with the JSON Web Token, and= > specifications that mitigate security attacks, such as Proof Key for > Code Exchange. >=20 > The ongoing standardization efforts within the OAuth working group > focus on increasing interoperability of OAuth deployments and to > improve security. More specifically, the working group is defining proo= f > of possession tokens, developing a discovery mechanism, > providing guidance for the use of OAuth with native apps, re-introducin= g > the device flow used by devices with limited user interfaces, additiona= l > security enhancements for clients communicating with multiple service > providers, definition of claims used with JSON Web Tokens, techniques t= o > mitigate open redirector attacks, as well as guidance on encoding state= > information. >=20 > For feedback and discussion about our specifications please > subscribe to our public mailing list. >=20 > For security related bug reports that relate to our specifications > please contact <>. If the reported bug > report turns out to be implementation-specific we will > attempt to forward it to the appropriate developers. >=20 > --------------- >=20 >=20 > Ciao > Hannes >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 --X3bj2UDp6Pllo3ltOhiKf3Ck9tHlwoKko 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 iQEcBAEBCgAGBQJWi46rAAoJEGhJURNOOiAtp4sIAJEmnNxf9Mu2juv4DQxGW2U+ Nso63HyaHQPrfg3VmN1nupRg/FMZQEWa6vL/whgFCo9v0ug8H8LD/OLeV0Bdb6Md z1HGdxrvg4Vcrfv4knQpt8KtgYLOIWP369fe2/x3dg2+h2HIRab5sJWBOWtVKUiL i/yoyaCH3VTHj1ZFpXpKzV+o1nUtU5lQs2V1RSNuH380a3oR3cymelKY2WTS7KgQ P6O/OmBBJM0tTxPuvSFblXNFlLoKTr27hp/F3hnqKqb2itS6mi9Yws8ZUsvgUGkp oqZdGDlcQpcepS4k1JXU1e2w1TQPFagQyv4Kz+aN35KN4dT8TlbUw4LiwuWgITE= =LYh4 -----END PGP SIGNATURE----- --X3bj2UDp6Pllo3ltOhiKf3Ck9tHlwoKko-- From nobody Tue Jan 5 04:28:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2A81B2D21 for ; Tue, 5 Jan 2016 04:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKuyvEXVfenh for ; Tue, 5 Jan 2016 04:28:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE25B1B2A51 for ; Tue, 5 Jan 2016 04:28:37 -0800 (PST) Received: from [192.168.10.141] ([80.92.119.18]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LbPza-1Zn7FJ1jOk-00kwvv for ; Tue, 05 Jan 2016 13:28:35 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <568BB6F2.5090407@gmx.net> Date: Tue, 5 Jan 2016 13:28:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HkU3lNn7SFRtm6gpgiJ1jku28l952K0tv" X-Provags-ID: V03:K0:yoaxjmXWXQZEYOfjgmwV9v5HPMe1+PeWfaSUqpwKF3XUeZNaReq vDpdsn+Vte6A0YvrWNOk6NBchDA6LW55FMpwyJ1AhDFmDDXjd6NxhSmigNfQ4hR2XPRAQs6 D95xwqdNqoILNACuL6bFedzfYJ3DwO2q6JYAuNU3OFpOjiQQnOvtU2pX7Jids6iCkmuqfx4 69UrT6by/BJkJboAILQ2g== X-UI-Out-Filterresults: notjunk:1;V01:K0:JtfbdmbXbOU=:H6kFQuwfCp8QPVpwc0GWoQ ankguxVFBWDkuZMnuKrudgDJANzsmRNOLRxnFQ+vB/EUsBbxNxppEk8Zl++epQ+PyWNnVJec2 mv2wmCiX8qGuEpissWk5oCz0IRcS0RxwifJz58+32sY7FQqQvoZDv50AJcL9bUHQsYLKHRLy5 aY8Mi5D5SH59b7PMA2jcEI9MVSfatTC6W8I3fmNLGM8fe545C3OP/0/oHLvU1PMaincrCu7Qo tWq8i/qspqK1ev22W/Y9NiBZBt+vWWm9ZxZTdw9FnLwet5/VtB2qZL3LSMk7KtWkKXZmYKEU2 tbPb/91ewnv71CpO06c4WTW1No1oy444vHU+CX3ROlZSkEdpRsWL9NK/RMtWrwISC1cZZ3HIu g1VdcaiATEOPmmhazSHNzaHNaMOY8bWwGnsSTnR/tHPLchgOWV3aHlzl0+2cV1aJQ0tO56e25 UlcpIKwrqFCJQEaqTZVOEfQPXkrj7SYwruwfA7iW7W0e1/B/+z9u5xb/hhFRPqB/HYR/ZviT6 JPFDv8LKKfqiHnliMJBmE1RdTQKtjuRWkE96OfvPDbN6TiTAhg8eJZ+CjzcblPtk03qo6oxjA kgpNOV6B0wTgUSAunes0QsVEJXKsvsX59EqYB1qzXfc6I0h/6yKkRTRO1MBzvZOaASr4vJxsW Tvx9mbl3LAuMZEDfGF/uV+C06qbhpPWSsS+uBtdg6YPbn+Z3FqYBqxw8Nl8HEbMtdoofUesaI FRZxroHdtHxRBW27ImURtdlKs/0vEg5dYr1Ene3YzIlk0yrXpzVYVQVvETA= Archived-At: Subject: [OAUTH-WG] OAuth WG -- Quick Status Update X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 12:28:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HkU3lNn7SFRtm6gpgiJ1jku28l952K0tv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, as you have seen from my previous mail we are currently in the process of rechartering the working group. We are doing this to pick up some new work given the progress we have made over the last couple of months and to also take into account recent work that help to increase interoperability of OAuth 2.0 deployments but also to provide bug fixes. While we have the rechartering discussions we also have to complete the currently scheduled work items. Here is a short update on where we are with our WG items: --- Token Exchange --- The specification was updated mid December to reflect the decisions at the Prague IETF meeting. In addition to the update of the open issue resolution Brian, John and Chuck joined the authors list for their contributions. Please take a look at the updated draft and let us know whether the document is ready for WGLC. Here are the minutes from the Prague IETF meeting: https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth I would need a few volunteers to review the document. Here is the draft: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 --- OAuth 2.0 JWT Authorization Request --- The chairs issued a WGLC on this document and several issues have been raised. John & Nat are in charge of addressing those comments and I have asked Nat to collect the open issues and to post them to the list. This should give us an idea where we are right now with the document and how to resolve the open issues. --- Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs) --- This document has been approved by the IESG already for publication, as you have seen here: http://www.ietf.org/mail-archive/web/oauth/current/msg15325.html --- OAuth 2.0 Proof-of-Possession (PoP) Security Architecture --- This document is already in IESG processing but I have asked Kathleen to delay the publication given that we ran into scoping issues, as discussed on the list. See http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html I will post a separate mail to the list to discuss a way forward for this document. --- OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution --- This document is on-hold, pending the completion of the architecture. --- HTTP Signing --- The draft that describes the solution has expired but Justin presented the work and the open issues at the Yokohama IETF meeting (see https://www.ietf.org/proceedings/94/slides/slides-94-oauth-3.pdf). I will also post a separate mail about how to proceed with it. Ciao Hannes & Derek --HkU3lNn7SFRtm6gpgiJ1jku28l952K0tv 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 iQEcBAEBCgAGBQJWi7byAAoJEGhJURNOOiAtpNIH/3lxYe/fYN4Ozlv7ZuJS90mS sqdfYwfuiawxthPucvJS9caxCXf6YWxAM010Ft9OwFsYaavOk9tTEknSOomqT1d4 cwGbFV/J38EYxIq4Vyik/5DQQQFsChcQFBvoUrab7K7NYRZuV1U2P4SKldbuf8Zf zp+Xbf95JgKIXak8z4ohElqeyOEU8Kqmu0U29YKS+RMseBznDZpnPX2/z2L2PKPq bWKYl2SMbmn/giX7856s3RxJkhcQ1Gf+EGJu7/xqxuG5jf9JADYywZRcjKzrkOKo m1tps19qgY0+IyoF++OpzcxSJfaEEcD8eBnwW4C2/9Ucb/49jEyU9U/mDuAxXaQ= =JkRc -----END PGP SIGNATURE----- --HkU3lNn7SFRtm6gpgiJ1jku28l952K0tv-- From nobody Tue Jan 5 13:40:51 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB231A92F3 for ; Tue, 5 Jan 2016 13:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVhkxwy0TRFc for ; Tue, 5 Jan 2016 13:40:47 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 A6B321A92F0 for ; Tue, 5 Jan 2016 13:40:47 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id 1so153483597ion.1 for ; Tue, 05 Jan 2016 13:40:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:content-type; bh=4QgMsk/OWwIn3eQZEoAFg3KnnY+IalOZP0eh2PxfDlY=; b=A5X9v85aHXiyfVrEWPpzdZTcAXjVJA7qd3Lt8XrSEf0k5arHxrsNe153U6u38CDav3 WufPY+IsSHOHDQDlcsgfC3xaqycebpwAJ8AXL/POsBki/GWWS7JWWcSLj0DW5vNfUgFg gC5iB8PSrrDrK+L5YP4KSLXywGVLnHK+wOETs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=4QgMsk/OWwIn3eQZEoAFg3KnnY+IalOZP0eh2PxfDlY=; b=e1MEfi5n5lkNrvHF2fwKTtdNGBdE/UVr3JILBJLWWtaeDVVYkWOmZ9NY/UJmGor0OB 8o8uun6fh+j+N5eOfPo2nYqzAha0bdkcIb0rhTxKOhOJpboTq+ruN5dJLihc8kWSzrH3 Oz2wi0QEHjcav3ZpmQSOBCJGr9P5pSu948bzP2w9ahzwR3pPgmR5F3FYBGui2aMPXIGG BnSLs4opD0cDD6aFJ/N8XcjQfSen4YW5Jg2qZS6iW9DhrxLHQTyXuuk0MOx+ByMDeVGL Meb86u7hDE8ypRltvjlVCl2GR5rFhwv3IMKfezzW5Mx+O0QhFv9TyDPMXS2dHxvQ4ESs K+yA== X-Gm-Message-State: ALoCoQlRqB3HJC5WaWkMQEBMMgqLRxMCJ3QJK1+oPDRZiMNkxpxFlw/APBLuXQxj1qacLccYyt7WD95sEd0C039VbLMzKL+l+OlgOawvXBDgU0+S+g4o83c= X-Received: by 10.107.16.226 with SMTP id 95mr54849664ioq.147.1452030046522; Tue, 05 Jan 2016 13:40:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.133 with HTTP; Tue, 5 Jan 2016 13:40:17 -0800 (PST) From: Brian Campbell Date: Tue, 5 Jan 2016 14:40:17 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a113ecda02067fb05289d17e3 Archived-At: Subject: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us -03 announcement redux X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 21:40:50 -0000 --001a113ecda02067fb05289d17e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On the off chance that it was missed in the final throes of 2015, I'd like to re-announce the publication of a new revision of the OAuth 2.0 Token Exchange draft. http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 Due to the substantial changes in this draft, I'd encourage (a.k.a. beg) WG participants to review the document. As Mike said, this draft reconciles the differences in approaches taken in the previous working group draft and draft-campbell-oauth-sts while incorporating working group input and rough consensuses from the in-person discussions in Prague and mailing list discussions. Changes from -02 are summarized in Appendix D http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#appendix-D and the more meaningful are copied here: o Updated the format of the request to use application/x-www-form- urlencoded request parameters and the response to use the existing token endpoint JSON parameters defined in OAuth 2.0. o Changed the grant type identifier to urn:ietf:params:oauth:grant- type:token-exchange. o Removed the Implementation Considerations and the requirement to support JWTs. o Changed "on_behalf_of" to "subject_token", "on_behalf_of_token_type" to "subject_token_type", "act_as" to "actor_token", and "act_as_token_type" to "actor_token_type". o Added a "want_composite" request parameter used to indicate the desire for a composite token rather than trying to infer it from the presence/absence of token(s) in the request. o Added an "audience" request parameter used to indicate the logical names of the target services at which the client intends to use the requested security token. o Added a "resource" request parameter used to indicate the URLs of resources at which the client intends to use the requested security token. o Specified that multiple "audience" and "resource" request parameter values may be used. o Defined the JWT claim "act" (actor) to express the current actor or delegation principal. o Defined the JWT claim "may_act" to express that one party is authorized to act on behalf of another party. o Defined the JWT claim "scp" (scopes) to express OAuth 2.0 scope- token values. o Added the "N_A" (not applicable) OAuth Access Token Type definition for use in contexts in which the token exchange syntax requires a "token_type" value, but in which the token being issued is not an access token. o Added examples. And the (known) outstanding issues are listed in Appendix C http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#appendix-C but also copied here: o Should there be a way to use short names for some common token type identifiers? URIs are necessary in the general case for extensibility and vendor/deployment specific types. But short names like "access_token" and "jwt" are aesthetically appealing and slightly more efficient in terms of bytes on the wire and url- encoding. There seemed to be rough consensus in Prague ('No objection to use the proposed mechanism for a default prefix' from https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth) for supporting a shorthand for commonly used types - i.e. when the value does not contain a ":" character, the value would be treated as though "urn:ietf:params:oauth:token-type:" were prepended to it. So, for example, the value "jwt" for "requested_token_type" would be semantically equivalent to "urn:ietf:params:oauth:token- type:jwt" and the value "access_token" would be equivalent to "urn:ietf:params:oauth:token-type:access_token". However, it was a fairly brief discussion in Prague and it has since been suggested that making participants handle both syntaxes will unnecessarily complicate the supporting code. o Provide a way to include supplementary claims or information in the request that would/could potentially be included in the issued token. There are real use cases for this but we would need to work through what it would look like. o Understand and define exactly how the presentation of PoP/non- bearer tokens works. Of course, the specifications defining these kinds of tokens need to do so first before there is much we can do in this specification in this regard. o It seems there may be cases in which it would be desirable for the authenticated client to be somehow represented in the issued token, sometimes in addition to the actor, which can already be represented using the "act" claim. Perhaps with a "client_id" claim? ---------- Forwarded message ---------- From: Mike Jones Date: Mon, Dec 14, 2015 at 1:05 AM Subject: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us To: "oauth@ietf.org" I=E2=80=99m happy to report that a substantially revised OAuth 2.0 Token Ex= change draft has been published that enables a broad range of use cases, while still remaining as simple as possible. This draft unifies the approaches taken in the previous working group draft and draft-campbell-oauth-sts, incorporating working group input from the in-person discussions in Prague and mailing list discussions. Thanks to all for your interest in and contributions to OAuth Token Exchange! Brian Campbell deserves special recognition for doing much of the editing heavy lifting for this draft. The core functionality remains token type independent. That said, new claims are also defined to enable representation of delegation actors in JSON Web Tokens (JWTs). Equivalent claims could be defined for other token types by other specifications. See the Document History section for a summary of the changes made. Please check it out! The specification is available at: =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 An HTML-formatted version is also available at: =C2=B7 http://self-issued.info/docs/draft-ietf-oauth-token-exchange-0= 3.html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1509 and as @selfissued . _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --001a113ecda02067fb05289d17e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On the off chance that it was missed in the final thr= oes of 2015, I'd like to re-announce the publication of a new revision = of the OAuth 2.0 Token Exchange draft.

http://tools.ietf.org/html/dra= ft-ietf-oauth-token-exchange-03

Due to the substantial changes i= n this draft, I'd encourage (a.k.a. beg) WG participants to review the = document. As Mike said, this draft reconciles the differences in approaches= taken in the previous working group draft and draft-campbell-oauth-sts while incorporating worki= ng group input and rough consensuses from the in-person discussions in Prague= and mailing list=20 discussions.

Changes from -02 are summarized in Appendix = D http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#a= ppendix-D and the more meaningful are copied here:
=
   o  Updated the format of the request to use application/x-www-form-
      urlencoded request parameters and the response to use the existing
      token endpoint JSON parameters defined in OAuth 2.0.
   o  Changed the grant type identifier to urn:ietf:params:oauth:grant-
      type:token-exchange.
   o  Removed the Implementation Considerations and the requirement to
      support JWTs.
   o  Changed "on_behalf_of" to "subject_token",
      "on_behalf_of_token_type" to "subject_token_type"=
, "act_as" to
      "actor_token", and "act_as_token_type" to "a=
ctor_token_type".
   o  Added a "want_composite" request =
parameter used to indicate the
      desire for a composite token rather than trying to infer it from
      the presence/absence of token(s) in the request.
  =C2=A0o  Added =
an "audience" request parameter used to indicate the logical
      names of the target services at which the client intends to use
      the requested security token.
   o  Added a "resource" request parameter used to indicate the U=
RLs of
      resources at which the client intends to use the requested
      security token.
   o  Specified that multiple "audience" and "resource"=
 request
      parameter values may be used.
   o  Defined the JWT claim "act" (actor) to express the current =
actor
      or delegation principal.
   o  Defined the JWT claim "may_act" to express that one party i=
s
      authorized to act on behalf of another party.
   o  Defined the JWT claim "scp" (scopes) to express OAuth 2.0 s=
cope-
      token values.
   o  Added the "N_A" (not applicable) OAuth Access Token Type
      definition for use in contexts in which the token exchange syntax
      requires a "token_type" value, but in which the token being=
 issued
      is not an access token.
   o  Added examples.

And the (known) outstanding issue= s are listed in Appendix C http://tools.ietf.org/html/draft-ietf-= oauth-token-exchange-03#appendix-C but also copied here:
   o  Should there be a way to use short names for some common token
      type identifiers?  URIs are necessary in the general case for
      extensibility and vendor/deployment specific types.  But short
      names like "access_token" and "jwt" are aesthetic=
ally appealing
      and slightly more efficient in terms of bytes on the wire and url-
      encoding.  There seemed to be rough consensus in Prague ('No
      objection to use the proposed mechanism for a default prefix' fro=
m
      https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth) for
      supporting a shorthand for commonly used types - i.e. when the
      value does not contain a ":" character, the value would be =
treated
      as though "urn:ietf:params:oauth:token-type:" were prepende=
d to
      it.  So, for example, the value "jwt" for "requested_t=
oken_type"
      would be semantically equivalent to "urn:ietf:params:oauth:token=
-
      type:jwt" and the value "access_token" would be equiva=
lent to
      "urn:ietf:params:oauth:token-type:access_token".  However, =
it was
      a fairly brief discussion in Prague and it has since been
      suggested that making participants handle both syntaxes will
      unnecessarily complicate the supporting code.

   o  Provide a way to include supplementary claims or information in
      the request that would/could potentially be included in the issued
      token.  There are real use cases for this but we would need to
      work through what it would look like.

   o  Understand and define exactly how the presentation of PoP/non-
      bearer tokens works.  Of course, the specifications defining these
      kinds of tokens need to do so first before there is much we can do
      in this specification in this regard.

   o  It seems there may be cases in which it would be desirable for the
      authenticated client to be somehow represented in the issued
      token, sometimes in addition to the actor, which can already be
      represented using the "act" claim.  Perhaps with a "cl=
ient_id"
      claim?


=C2=A0
---------- Forwarded message ----------
From: Mike Jones <Michael.Jones@microsoft.com>Date: Mon, Dec 14, 2015 at 1:05 AM
Subject: [OAUTH-WG] OAuth 2.0 Token= Exchange: An STS for the REST of Us
To: "oauth@ietf.org" <oau= th@ietf.org>


I=E2=80=99m happy to report that a substantially rev= ised OAuth 2.0 Token Exchange draft has been published that enables a broad= range of use cases, while still remaining as simple as possible.=C2=A0 Thi= s draft unifies the approaches taken in the previous working group draft and draft-campbell-oauth-sts, incorporating working gr= oup input from the in-person discussions in Prague and mailing list discuss= ions.=C2=A0 Thanks to all for your interest in and contributions to OAuth T= oken Exchange!=C2=A0 Brian Campbell deserves special recognition for doing much of the editing heavy lifting for this d= raft.

=C2=A0

The core functionality remains token type independen= t.=C2=A0 That said, new claims are also defined to enable representation of= delegation actors in JSON Web Tokens (JWTs).=C2=A0 Equivalent claims could= be defined for other token types by other specifications.

=C2=A0

See the Document History section for a summary of th= e changes made.=C2=A0 Please check it out!

=C2=A0

The specification is available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://tools.ietf.org/html/dra= ft-ietf-oauth-token-exchange-03

=C2=A0

An HTML-formatted version is also available at:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://self-issued.info= /docs/draft-ietf-oauth-token-exchange-03.html

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<= u>

=C2=A0

P.S.=C2=A0 This note was also posted at http://self-issued.info/?p=3D1509 and as @selfissued.


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


--001a113ecda02067fb05289d17e3-- From nobody Wed Jan 6 02:19:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 054491ACE53 for ; Wed, 6 Jan 2016 02:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY2moEVfL5ze for ; Wed, 6 Jan 2016 02:19:23 -0800 (PST) Received: from p3plsmtpa11-08.prod.phx3.secureserver.net (p3plsmtpa11-08.prod.phx3.secureserver.net [68.178.252.109]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8FF91ACDE1 for ; Wed, 6 Jan 2016 02:19:23 -0800 (PST) Received: from [192.168.0.112] ([77.77.164.50]) by p3plsmtpa11-08.prod.phx3.secureserver.net with id 2aKM1s00A15ZTut01aKNlz; Wed, 06 Jan 2016 03:19:23 -0700 To: oauth@ietf.org References: From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <568CEA28.6070204@connect2id.com> Date: Wed, 6 Jan 2016 12:19:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------060507050603050207060803" Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us -03 announcement redux X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 10:19:27 -0000 This is a multi-part message in MIME format. --------------060507050603050207060803 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Brian, 1. The introduction is excellent! Previous versions were lacking in this regard and readers were left guessing or unaware about key aspects of the spec and how to make use of it. Good work! 2.1. Are clients allowed to mix or include both "resource" and "audience" request parameters at the same time? A.1. Wouldn't the impersonation example be more straightforward if the returned token is an access token? I see that a "N_A" token is also demonstrated there, but that could confuse readers if the main point is to show an impersonation example. A.1 + A.2. It is stated that the client is anonymous. But is that really so if the supplied JWTs are apparently signed by the client and the AS will have to verify them? Overall I'm very pleased with this new version! Cheers, Vladimir On 05/01/16 23:40, Brian Campbell wrote: > On the off chance that it was missed in the final throes of 2015, I'd l= ike > to re-announce the publication of a new revision of the OAuth 2.0 Token= > Exchange draft. > > http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 > > Due to the substantial changes in this draft, I'd encourage (a.k.a. beg= ) WG > participants to review the document. As Mike said, this draft reconcile= s > the differences in approaches taken in the previous working group draft= and > draft-campbell-oauth-sts while incorporating working group input and ro= ugh > consensuses from the in-person discussions in Prague and mailing list > discussions. > > Changes from -02 are summarized in Appendix D > http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#appendix-= D > and the more meaningful are copied here: > > o Updated the format of the request to use application/x-www-form- > urlencoded request parameters and the response to use the existin= g > token endpoint JSON parameters defined in OAuth 2.0. > o Changed the grant type identifier to urn:ietf:params:oauth:grant-= > type:token-exchange. > o Removed the Implementation Considerations and the requirement to > support JWTs. > o Changed "on_behalf_of" to "subject_token", > "on_behalf_of_token_type" to "subject_token_type", "act_as" to > "actor_token", and "act_as_token_type" to "actor_token_type". > o Added a "want_composite" request parameter used to indicate the > desire for a composite token rather than trying to infer it from > the presence/absence of token(s) in the request. > o Added an "audience" request parameter used to indicate the logica= l > names of the target services at which the client intends to use > the requested security token. > o Added a "resource" request parameter used to indicate the URLs of= > resources at which the client intends to use the requested > security token. > o Specified that multiple "audience" and "resource" request > parameter values may be used. > o Defined the JWT claim "act" (actor) to express the current actor > or delegation principal. > o Defined the JWT claim "may_act" to express that one party is > authorized to act on behalf of another party. > o Defined the JWT claim "scp" (scopes) to express OAuth 2.0 scope- > token values. > o Added the "N_A" (not applicable) OAuth Access Token Type > definition for use in contexts in which the token exchange syntax= > requires a "token_type" value, but in which the token being issue= d > is not an access token. > o Added examples. > > > And the (known) outstanding issues are listed in Appendix C > http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#appendix-= C > but also copied here: > > o Should there be a way to use short names for some common token > type identifiers? URIs are necessary in the general case for > extensibility and vendor/deployment specific types. But short > names like "access_token" and "jwt" are aesthetically appealing > and slightly more efficient in terms of bytes on the wire and url= - > encoding. There seemed to be rough consensus in Prague ('No > objection to use the proposed mechanism for a default prefix' fro= m > https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth) for= > supporting a shorthand for commonly used types - i.e. when the > value does not contain a ":" character, the value would be treate= d > as though "urn:ietf:params:oauth:token-type:" were prepended to > it. So, for example, the value "jwt" for "requested_token_type" > would be semantically equivalent to "urn:ietf:params:oauth:token-= > type:jwt" and the value "access_token" would be equivalent to > "urn:ietf:params:oauth:token-type:access_token". However, it was= > a fairly brief discussion in Prague and it has since been > suggested that making participants handle both syntaxes will > unnecessarily complicate the supporting code. > > o Provide a way to include supplementary claims or information in > the request that would/could potentially be included in the issue= d > token. There are real use cases for this but we would need to > work through what it would look like. > > o Understand and define exactly how the presentation of PoP/non- > bearer tokens works. Of course, the specifications defining thes= e > kinds of tokens need to do so first before there is much we can d= o > in this specification in this regard. > > o It seems there may be cases in which it would be desirable for th= e > authenticated client to be somehow represented in the issued > token, sometimes in addition to the actor, which can already be > represented using the "act" claim. Perhaps with a "client_id" > claim? > > > > > ---------- Forwarded message ---------- > From: Mike Jones > Date: Mon, Dec 14, 2015 at 1:05 AM > Subject: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us= > To: "oauth@ietf.org" > > > I=92m happy to report that a substantially revised OAuth 2.0 Token Exch= ange > draft has been published that enables a broad range of use cases, while= > still remaining as simple as possible. This draft unifies the approach= es > taken in the previous working group draft and draft-campbell-oauth-sts,= > incorporating working group input from the in-person discussions in Pra= gue > and mailing list discussions. Thanks to all for your interest in and > contributions to OAuth Token Exchange! Brian Campbell deserves special= > recognition for doing much of the editing heavy lifting for this draft.= > > > > The core functionality remains token type independent. That said, new > claims are also defined to enable representation of delegation actors i= n > JSON Web Tokens (JWTs). Equivalent claims could be defined for other t= oken > types by other specifications. > > > > See the Document History section for a summary of the changes made. Pl= ease > check it out! > > > > The specification is available at: > > =B7 http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03= > > > > An HTML-formatted version is also available at: > > =B7 http://self-issued.info/docs/draft-ietf-oauth-token-exchange-= 03.html > > > > -- Mike > > > > P.S. This note was also posted at http://self-issued.info/?p=3D1509 an= d as > @selfissued . > > _______________________________________________ > 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 Vladimir Dzhuvinov :: vladimir@connect2id.com --------------060507050603050207060803 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Brian,

1. The introduction is excellent! Previous versions were lacking in this regard and readers were left guessing or unaware about key aspects of the spec and how to make use of it. Good work!

2.1. Are clients allowed to mix or include both "resource" and "audience" request parameters at the same time?

A.1. Wouldn't the impersonation example be more straightforward if the returned token is an access token? I see that a "N_A" token is also demonstrated there, but that could confuse readers if the main point is to show an impersonation example.

A.1 + A.2. It is stated that the client is anonymous. But is that really so if the supplied JWTs are apparently signed by the client and the AS will have to verify them?


Overall I'm very pleased with this new version!

Cheers,

Vladimir



On 05/01/16 23:40, Brian Campbell wrote:
On the off chance that it was missed in the final throes of 2015, I'd like
to re-announce the publication of a new revision of the OAuth 2.0 Token
Exchange draft.

http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03

Due to the substantial changes in this draft, I'd encourage (a.k.a. beg) WG
participants to review the document. As Mike said, this draft reconciles
the differences in approaches taken in the previous working group draft and
draft-campbell-oauth-sts while incorporating working group input and rough
consensuses from the in-person discussions in Prague and mailing list
discussions.

Changes from -02 are summarized in Appendix D
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#appendix-D
and the more meaningful are copied here:

   o  Updated the format of the request to use application/x-www-form-
      urlencoded request parameters and the response to use the existing
      token endpoint JSON parameters defined in OAuth 2.0.
   o  Changed the grant type identifier to urn:ietf:params:oauth:grant-
      type:token-exchange.
   o  Removed the Implementation Considerations and the requirement to
      support JWTs.
   o  Changed "on_behalf_of" to "subject_token",
      "on_behalf_of_token_type" to "subject_token_type", "act_as" to
      "actor_token", and "act_as_token_type" to "actor_token_type".
   o  Added a "want_composite" request parameter used to indicate the
      desire for a composite token rather than trying to infer it from
      the presence/absence of token(s) in the request.
   o  Added an "audience" request parameter used to indicate the logical
      names of the target services at which the client intends to use
      the requested security token.
   o  Added a "resource" request parameter used to indicate the URLs of
      resources at which the client intends to use the requested
      security token.
   o  Specified that multiple "audience" and "resource" request
      parameter values may be used.
   o  Defined the JWT claim "act" (actor) to express the current actor
      or delegation principal.
   o  Defined the JWT claim "may_act" to express that one party is
      authorized to act on behalf of another party.
   o  Defined the JWT claim "scp" (scopes) to express OAuth 2.0 scope-
      token values.
   o  Added the "N_A" (not applicable) OAuth Access Token Type
      definition for use in contexts in which the token exchange syntax
      requires a "token_type" value, but in which the token being issued
      is not an access token.
   o  Added examples.


And the (known) outstanding issues are listed in Appendix C
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#appendix-C
but also copied here:

   o  Should there be a way to use short names for some common token
      type identifiers?  URIs are necessary in the general case for
      extensibility and vendor/deployment specific types.  But short
      names like "access_token" and "jwt" are aesthetically appealing
      and slightly more efficient in terms of bytes on the wire and url-
      encoding.  There seemed to be rough consensus in Prague ('No
      objection to use the proposed mechanism for a default prefix' from
      https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth) for
      supporting a shorthand for commonly used types - i.e. when the
      value does not contain a ":" character, the value would be treated
      as though "urn:ietf:params:oauth:token-type:" were prepended to
      it.  So, for example, the value "jwt" for "requested_token_type"
      would be semantically equivalent to "urn:ietf:params:oauth:token-
      type:jwt" and the value "access_token" would be equivalent to
      "urn:ietf:params:oauth:token-type:access_token".  However, it was
      a fairly brief discussion in Prague and it has since been
      suggested that making participants handle both syntaxes will
      unnecessarily complicate the supporting code.

   o  Provide a way to include supplementary claims or information in
      the request that would/could potentially be included in the issued
      token.  There are real use cases for this but we would need to
      work through what it would look like.

   o  Understand and define exactly how the presentation of PoP/non-
      bearer tokens works.  Of course, the specifications defining these
      kinds of tokens need to do so first before there is much we can do
      in this specification in this regard.

   o  It seems there may be cases in which it would be desirable for the
      authenticated client to be somehow represented in the issued
      token, sometimes in addition to the actor, which can already be
      represented using the "act" claim.  Perhaps with a "client_id"
      claim?




---------- Forwarded message ----------
From: Mike Jones <Michael.Jones@microsoft.com>
Date: Mon, Dec 14, 2015 at 1:05 AM
Subject: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us
To: "oauth@ietf.org" <oauth@ietf.org>


I’m happy to report that a substantially revised OAuth 2.0 Token Exchange
draft has been published that enables a broad range of use cases, while
still remaining as simple as possible.  This draft unifies the approaches
taken in the previous working group draft and draft-campbell-oauth-sts,
incorporating working group input from the in-person discussions in Prague
and mailing list discussions.  Thanks to all for your interest in and
contributions to OAuth Token Exchange!  Brian Campbell deserves special
recognition for doing much of the editing heavy lifting for this draft.



The core functionality remains token type independent.  That said, new
claims are also defined to enable representation of delegation actors in
JSON Web Tokens (JWTs).  Equivalent claims could be defined for other token
types by other specifications.



See the Document History section for a summary of the changes made.  Please
check it out!



The specification is available at:

·       http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03



An HTML-formatted version is also available at:

·       http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03.html



                                                          -- Mike



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

_______________________________________________
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


-- 
Vladimir Dzhuvinov :: vladimir@connect2id.com
--------------060507050603050207060803-- From nobody Wed Jan 6 06:29:55 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6011F1B2C2E for ; Wed, 6 Jan 2016 06:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrGYaeV0U-Jf for ; Wed, 6 Jan 2016 06:29:52 -0800 (PST) Received: from p3plsmtpa12-07.prod.phx3.secureserver.net (p3plsmtpa12-07.prod.phx3.secureserver.net [68.178.252.236]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 555951B2C25 for ; Wed, 6 Jan 2016 06:29:52 -0800 (PST) Received: from [192.168.0.112] ([77.77.164.50]) by p3plsmtpa12-07.prod.phx3.secureserver.net with id 2eVq1s00H15ZTut01eVrrc; Wed, 06 Jan 2016 07:29:52 -0700 To: "oauth@ietf.org" From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <568D24DD.3050501@connect2id.com> Date: Wed, 6 Jan 2016 16:29:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000102000203010304000808" Archived-At: Subject: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 14:29:53 -0000 This is a cryptographically signed message in MIME format. --------------ms000102000203010304000808 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I just noticed PKCE support is missing from the discovery metadata. Is it a good idea to add it? Cheers, Vladimir --=20 Vladimir Dzhuvinov --------------ms000102000203010304000808 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+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAxMDYxNDI5NDlaMC8GCSqGSIb3DQEJBDEiBCArKG1byssxNsOtTgQkcD/Ha6A4OhQp BK1qSc6ZOmjuvzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQBK18pqAFhn 7yw7KAf4d5CP2X4Bi/yqw4MDeAlZdkaDYsLWQXFQTh+j0GZC4DLLURZIPKbMg+duXYkDhD56 wTednNLE3WRTuA/vCqEc3ncXjjcoplFfn8B/CCpidOXDCbhuR3noArXYGkGwyRO+9dTREmJj 4EJYJveBfUqU0CzuwI4YPmxAhOLt27F3PsqhBiJmHdjEk47z1XwlTaLuNGn9EF4kYV25OZsx sNSu88DCVShc36cNLCLH6rUQ+y1NUVquTWdGmt3IVqiYfUvv1bPd3l8oj4d6mXUyoRbmkFF3 t9Q5/a0Tkyr6AOls9004+YDVvNDPSZrDic7jTBRcwBgMAAAAAAAA --------------ms000102000203010304000808-- From nobody Wed Jan 6 06:40:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1F21B2C58 for ; Wed, 6 Jan 2016 06:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaP_v2gzazti for ; Wed, 6 Jan 2016 06:40:38 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DD31B2C3C for ; Wed, 6 Jan 2016 06:40:37 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id l9so266531843oia.2 for ; Wed, 06 Jan 2016 06:40:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s0PuZ0wlfEJOowjzNJa6cCEQG47xU70W+TXSf+73eAI=; b=rApganwGo+0qu1FFgbM6AM/+rGwtj/0YIN2yv1oryutcTOV19vOOXHPulbpLlMqSu4 4FRAnYuoqaSz/YLHSbYN+U1iZaE9arLduFxkd2EU0j8hqEAahz3dngBDEQrTehC7G4JG 83oV5L9VCnGzNilSeHintkVgOr8LLDO31Q923385sU+dsbvT25kcZOCLpqNVJJEAvSLy ex4L1IYsJFRGh4WYiqoB/z8aWNQ2dxDCNnI8uzichmALiAWx0aaGs97efOLWgndZ1Leh DWKEIvpGB2p6Ls2BPWTJ2sP/TOJVf55iettWb+fpOVfRPA+mr/B5iiOA36tkNxXGtulx +aFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=s0PuZ0wlfEJOowjzNJa6cCEQG47xU70W+TXSf+73eAI=; b=MflUkEN8ek+tCaLUgXrCnbBFnJAGSbYapJseWNIJvY8yK0PO8AUFeE8DeMhSnT9X2t aFO49qN/qVQWfYZ8fQnj+ZrfYcFgUYub17rjSMv7+3zohymqYZ9O502cKT/UOiNjpjLb aHJoLm68WgmUTgHIWouG9GCAE1xRrdt72Xi8cpmgZbFliewtOtkX5g6y0yyLS0WPV2uf 9ejF05qXoCxXdnvOQtK+dhE7z/X4nvJlS5srEp2qNXgkMSgaSHFZk8ATVMOB+oVZOBt2 2zuacPFxT+nRdVly8g4ZJxtJX1x+YBCAM7I9eUPXzOCJXabMJmEc+ZFvyxVXy1vX8EEM bIbw== X-Gm-Message-State: ALoCoQlwLN2o0ma903yw/BsoVW1zP94dBseJpqmdnto91fxYBmKqrnfcpa31HnKd/NNdjwnZxD47XS59s/nt7cf750OVGG874A== X-Received: by 10.202.226.141 with SMTP id z135mr38204582oig.21.1452091237132; Wed, 06 Jan 2016 06:40:37 -0800 (PST) Received: from [10.2.2.45] (75-147-25-205-NewEngland.hfc.comcastbusiness.net. [75.147.25.205]) by smtp.gmail.com with ESMTPSA id sw1sm3443182obc.21.2016.01.06.06.40.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 06 Jan 2016 06:40:36 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <568D24DD.3050501@connect2id.com> Date: Wed, 6 Jan 2016 09:40:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <568D24DD.3050501@connect2id.com> To: Vladimir Dzhuvinov X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 14:40:39 -0000 Good point. Now that PKCE is a RFC we should add it to discovery. John B. > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov = wrote: >=20 > I just noticed PKCE support is missing from the discovery metadata. >=20 > Is it a good idea to add it? >=20 > Cheers, >=20 > Vladimir >=20 > --=20 > Vladimir Dzhuvinov >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Jan 6 09:25:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE101B2E16 for ; Wed, 6 Jan 2016 09:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hfb3L3bO39G for ; Wed, 6 Jan 2016 09:25:44 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 27A781B2E1B for ; Wed, 6 Jan 2016 09:25:44 -0800 (PST) Received: by mail-ob0-x234.google.com with SMTP id xn1so31021887obc.2 for ; Wed, 06 Jan 2016 09:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=39+96gJglHAcPqa9OnDt0b/BSSlKpWitpLrxCTYtkqg=; b=aSTkAhlVWXoqbRnM9bs5ca6FbEN+4HIZMi9okqTlMm85FCzxana7kTguPdpVWPDyQe 8U7q6W+rBFyOJDlmTxC4uc8oMy9Tn8M0W8JAt4TawL3ZHOytEHTEUdgRktgnP+4ZYorY brXROaBVYbJPvWbaN/+4gSfJJ8/ybXbRPb1rJv+cEvPwZX3imoCdcQ6ZgHrPb/1t5j3T rrq4Qx3k5xFmW/V5t1kYVvGusBQCAZ+ugohilXCXeFwYqzIT1/njNzqU4aHxoa8w3jXy 2Pjt/lh+w7ME4KK6iWRxnEfv/vTVMZMbhWus3XfHNtGWvxx8dLZ3mb2Hpf52RPR40Fpr rf2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=39+96gJglHAcPqa9OnDt0b/BSSlKpWitpLrxCTYtkqg=; b=KDhVcHhEpvHOyBDbAj8vZ7ydBMbusaUuMa++tCbsoS2fcmTreRojFYJgr6YqCRNWCp ZE+Udn3kR94IvvxBbqhp/yWOQnpJaL1i6x7cTcZH2swCX6MMucVJXD7kzysMVQE11uLx 5Zih7c3PJeRjqBtDw85KQIK86D3T7Wv29+XBe9C5qCOBNG5jPSxjky8TAO76wBmffsid pF5YUC4RBJQANPhEdLAfGjLAqe21SRFjYdeVYlzS9oyMXB4TKfmxPY1D3DbTtKDj4niU HAHGityumq4xEVQ+YH5Nj3iCkXzmWocYBX2h4JEuZIz5Z/Hbcz+j/VOjOB9kGspzCHsE yRDQ== X-Gm-Message-State: ALoCoQkcrDxJlatCkx5JYXco/XDw332Bb5RftoWv8WEkSYLxng1MVy8Ye8HMCw7djGUAl81gDbJHbOhDolcTzHB5FHxRbKr9ru75QRYTj6ezAjOwPHYPiBA= X-Received: by 10.182.130.162 with SMTP id of2mr58954779obb.57.1452101143371; Wed, 06 Jan 2016 09:25:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Wed, 6 Jan 2016 09:25:23 -0800 (PST) In-Reply-To: References: <568D24DD.3050501@connect2id.com> From: William Denniss Date: Wed, 6 Jan 2016 09:25:23 -0800 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=089e013cbb2cd47a930528ada4fd Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 17:25:45 -0000 --089e013cbb2cd47a930528ada4fd Content-Type: text/plain; charset=UTF-8 +1 On Wed, Jan 6, 2016 at 6:40 AM, John Bradley wrote: > Good point. Now that PKCE is a RFC we should add it to discovery. > > John B. > > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov > wrote: > > > > I just noticed PKCE support is missing from the discovery metadata. > > > > Is it a good idea to add it? > > > > Cheers, > > > > Vladimir > > > > -- > > 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 > --089e013cbb2cd47a930528ada4fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Wed, Jan 6, 2016 at 6:40 AM, John Bradley <= ve7jtb@ve7jtb.com> wrote:
Good point.=C2=A0 Now= that PKCE is a RFC we should add it to discovery.

John B.
> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov = <vladimir@connect2id.com&= gt; wrote:
>
> I just noticed PKCE support is missing from the discovery metadata. >
> Is it a good idea to add it?
>
> Cheers,
>
> Vladimir
>
> --
> 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

--089e013cbb2cd47a930528ada4fd-- From nobody Wed Jan 6 10:00:03 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF54F1A004D for ; Wed, 6 Jan 2016 10:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z2Xj9J1mMWt for ; Wed, 6 Jan 2016 09:59:59 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) (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 E51321A0047 for ; Wed, 6 Jan 2016 09:59:58 -0800 (PST) Received: from [79.253.5.21] (helo=[192.168.71.102]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aGsLr-0008M6-Uq; Wed, 06 Jan 2016 18:58:28 +0100 To: William Denniss , John Bradley References: <568D24DD.3050501@connect2id.com> From: Torsten Lodderstedt Message-ID: <568D5610.6000506@lodderstedt.net> Date: Wed, 6 Jan 2016 18:59:44 +0100 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="------------000508090203060009020508" X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2016 18:00:02 -0000 This is a multi-part message in MIME format. --------------000508090203060009020508 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit +1 Am 06.01.2016 um 18:25 schrieb William Denniss: > +1 > > On Wed, Jan 6, 2016 at 6:40 AM, John Bradley > wrote: > > Good point. Now that PKCE is a RFC we should add it to discovery. > > John B. > > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov > > wrote: > > > > I just noticed PKCE support is missing from the discovery metadata. > > > > Is it a good idea to add it? > > > > Cheers, > > > > Vladimir > > > > -- > > 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 > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------000508090203060009020508 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit +1

Am 06.01.2016 um 18:25 schrieb William Denniss:
+1

On Wed, Jan 6, 2016 at 6:40 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Good point.  Now that PKCE is a RFC we should add it to discovery.

John B.
> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
>
> I just noticed PKCE support is missing from the discovery metadata.
>
> Is it a good idea to add it?
>
> Cheers,
>
> Vladimir
>
> --
> 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



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

--------------000508090203060009020508-- From Christian.Mainka@rub.de Thu Jan 7 00:51:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB281A87D0 for ; Thu, 7 Jan 2016 00:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.129 X-Spam-Level: X-Spam-Status: No, score=-0.129 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xv_Dsf5W1c4m for ; Thu, 7 Jan 2016 00:51:33 -0800 (PST) Received: from mx1.mail.ruhr-uni-bochum.de (out1.mail.ruhr-uni-bochum.de [134.147.53.149]) (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 8F7161A87CE for ; Thu, 7 Jan 2016 00:51:32 -0800 (PST) Received: from mx1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx1.mail.ruhr-uni-bochum.de (Postfix mo-ext) with ESMTP id 3pbhBC2QYrz4wH8 for ; Thu, 7 Jan 2016 09:51:31 +0100 (CET) Received: from mx1.mail.ruhr-uni-bochum.de (localhost [127.0.0.1]) by mx1.mail.ruhr-uni-bochum.de (Postfix idis) with ESMTP id 3pbhBC1TCrz4w7s; Thu, 7 Jan 2016 09:51:31 +0100 (CET) X-Envelope-Sender: X-RUB-Notes: Internal origin=134.147.42.227 Received: from mail1.mail.ruhr-uni-bochum.de (mail1.mail.ruhr-uni-bochum.de [134.147.42.227]) by mx1.mail.ruhr-uni-bochum.de (Postfix mi-int) with ESMTP id 3pbhBC093Jz4w1h; Thu, 7 Jan 2016 09:51:30 +0100 (CET) Received: from [134.147.40.26] (rhino.nds.ruhr-uni-bochum.de [134.147.40.26]) by mail1.mail.ruhr-uni-bochum.de (Postfix) with ESMTPSA id 3pbhB9718FzyTT; Thu, 7 Jan 2016 09:51:29 +0100 (CET) References: <568CFAB1.1080508@rub.de> From: Christian Mainka X-Enigmail-Draft-Status: N1110 X-Forwarded-Message-Id: <568CFAB1.1080508@rub.de> Message-ID: <568E2712.2080201@rub.de> Date: Thu, 7 Jan 2016 09:51:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <568CFAB1.1080508@rub.de> Content-Type: multipart/mixed; boundary="------------030507040703080605020605" X-Virus-Scanned: clamav-milter 0.98.7 at mx1.mail.ruhr-uni-bochum.de X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Thu, 07 Jan 2016 01:14:20 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] [OAuth-WG] [Review] draft-bradley-oauth-jwt-encoded-state-05 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 08:53:32 -0000 This is a multi-part message in MIME format. --------------030507040703080605020605 Content-Type: multipart/alternative; boundary="------------050804010006030002000705" --------------050804010006030002000705 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, this mail is just a forward to the OAuth Mailing List. (see below) Best Regards - Christian -------- Forwarded Message -------- Subject: [Review] draft-bradley-oauth-jwt-encoded-state-05.pdf Date: Wed, 6 Jan 2016 12:29:53 +0100 From: Christian Mainka To: ve7jtb@ve7jtb.com, torsten@lodderstedt.net, hzandbelt@pingidentity.c= om CC: Vladislav Mladenov Hi John, Torsten, Hans, as discussed in Darmstadt, Vladi and me took a look at the jwt-encoded-state document. You can find our thoughts in the attached pdf. Best Regards, - Vladi / Christian --=20 M.Sc. Christian Mainka Horst G=C3=B6rtz Institute for IT-Security=20 Chair for Network and Data Security=20 Ruhr-University Bochum, Germany Universit=C3=A4tsstr. 150, ID 2/411 D-44801 Bochum, Germany Telefon: +49 (0) 234 / 32-26796 Fax: +49 (0) 234 / 32-14347 http://www.nds.rub.de --------------050804010006030002000705 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

this mail is just a forward to the OAuth Mailing List. (see below)

Best Regards
- Christian


-------- Forwarded Message --------
Subject: [Review] draft-bradley-oauth-jwt-encoded-state-05.pdf
Date: Wed, 6 Jan 2016 12:29:53 +0100
From: Christian Mainka <Christian.Mainka@rub.de>
To: ve7jtb@ve7jtb.com, torsten@lodderstedt.net, hzandbelt@pingidentity.com
CC: Vladislav Mladenov <vladislav.mladenov@rub.de> 


Hi John, Torsten, Hans,

as discussed in Darmstadt, Vladi and me took a look at the
jwt-encoded-state document.
You can find our thoughts in the attached pdf.

Best Regards,
- Vladi / Christian

-- 
M.Sc. Christian Mainka
Horst Görtz Institute for IT-Security 
Chair for Network and Data Security 
Ruhr-University Bochum, Germany

Universitätsstr. 150, ID 2/411
D-44801 Bochum, Germany

Telefon: +49 (0) 234 / 32-26796
Fax: +49 (0) 234 / 32-14347
http://www.nds.rub.de


--------------050804010006030002000705-- --------------030507040703080605020605 Content-Type: application/pdf; name="draft-bradley-oauth-jwt-encoded-state-05.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-bradley-oauth-jwt-encoded-state-05.pdf" JVBERi0xLjYNJeLjz9MNCjI3MCAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNvZGUvRmlyc3Qg NjYvTGVuZ3RoIDU3OC9OIDkvVHlwZS9PYmpTdG0+PnN0cmVhbQ0KaN6klc1q20AUhV/lvsHM nTujmYFgaNKmi1IwTnbGi5CIko1VLAXct6+qc5QId9Naq2Pjq4O++3OcingxCVkliqUiWiRF kxykFi8liWptRL2Jxmb8oFG0yVnUgmgNRW5u3KfjsRv6faOj106aADFIhCRIA8mQAqmTaIpU 1Iao1EA1KuoCPQNMD+6uOw7tceglTYbue/vy+nTbnfd+/NpokFzDwW2fTmORTF5u1/bd2+m5 7UeKL+fh68PwNLSS/fTj/egneXoJtz11zw/tsHfbz/fusT0Ph83G7bqp3LvHXz/b0fhHu9mM Rnfd2/hgcd9eX/o9mUCaIBlABe//p7eTKmstgOfdtZ9s2WX1rIYEPgOZO3jZkHX90OajH5r/ ux988cBxcprzMCHzKCFYj4BuBayHgdvggh6JwcXgYnAxuBhcDC4GlwgXrhY3i4vFvYpwiXCJ cIlwiXBJcElwSXBJcOEWc4k1cbkbjo1HorySwJUIqFvMTFcucVoMLV09tAyMjGZkNCNzjYFW QFYAVubxcoZo/4Ir2zquYh9cJV7LVYBQgFCBUIFQgVAxz4p5VjSiohEVdBUulTP2nhvOHsw7 nuYlv7zL0qw8TK+Ly/Th2m6ob0iQqYVKsvfQmW+Yh4pLXW6tjyuRkGhEQq5dhaREYfSqEiUQ JcwBygTlsJSJpIwkJaoylJSppOGvg9W1MWuL/x01vRqdOagMQuUtKqNQmYXKMFSmoTIONc7/ JvES0VYeryJciYiI/XfE3wIMAG7cLPgNCmVuZHN0cmVhbQ1lbmRvYmoNMjcxIDAgb2JqDTw8 L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA0L0xlbmd0aCA2OC9OIDEvVHlwZS9PYmpTdG0+ PnN0cmVhbQ0KaN6yVDBQsLHRd0osTnXLzyvRd84vLcpMLdJ3zUvOT8nMS1cwNDEHKgnSDy5N KqksSNUPARKGYFIfpMHODiDAALeOFW8NCmVuZHN0cmVhbQ1lbmRvYmoNMjcyIDAgb2JqDTw8 L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCA4OTMvTGVuZ3RoIDI4NjIvTiAxMDYvVHlwZS9P YmpTdG0+PnN0cmVhbQ0KaN7sWltv28oR/gX9Dwv34dgotNz7xXEcpAkOGrTJcZO0fTjNAyVR R2pkSaDoOsmv7ze8SUojWaZpow81IEtLLme/ue7McKU1TDBpLfMuMClYcIpJyWLEVfolcVXj p7FMGvz0uIifFnOUZNLpwBQueSWYwrxg8Y15URumLFNCRqYcpgqMPb4DxvSIxxg/tY1M0yPG MA2SFhe1wiNYVGt8R4zp0WCZBr3gMAa9CMTa41EjGSBoCeKaHsVzRuAbz9EtHTBWIIHnDEha izGWcphsiARAGwcSAmOQCNEyA3oxSGZwSTjPwJKReM7iksJiVoEUmCxJQWQQoTFRMUAyDkJx mOfxECRpAphxmBdx0eERAbk6C1KQo3MgITDGEgZ8QwHWWs8A1brgmMe8IEkz+I6eedwSEKYP WAIgPB5RASoDCQP8gOwshBKINIgHzPPgJxBpPIylvRCORcm8hDAB2SuAi5p5jYvRYEnoMdKS YD5iKQ8QtHQArhiwJHBFWoqMAdiDglQliIJRmIXA6kaQIQX8AE1JuCyULUvbAhWYFAseOpIS kwMZDWwsRNCQMJYQAVcSCkGmBnFGsk4JI4skfKkIMJkeNBANdCaxcLQQkoRsohd0hcBquhKA 1tGVSHDBGTEuhaIxTRCarBxCg4HCXiStICytrOkJL3CNsApSpDQlQw5jQ74hiEHiH6yAQ0Nc KkhNwqghIBKIK/kkBDAAMEr/ycOUhfYuLpKXV/j3Dk84uOH7y8vk1a+S4xl8BBefklfLRZEt ivUpmy3YMh9nOSuWbLxkt9O0eMH+Mf1KN4rpbM1G6Tp7cZa8yrO0mC0Xr9MiO319Dg+0kKKX EbyKPwj5kxA/nSU/M5O8+Zj8afbbdI5P8W5ZZMnb7+Yb3c5/9/ZUiGwYUz0a6HEYDUyIcjAc T0aDMPZwN1iQmuiz5Aq2SqwkV8vVzaqMLDT66006vlrOwMmvOnruICUVFCeDMUJzpzfj9r6X +Fab+9X4U/L+1enFiy/Xc/bvLF+D0+cnENfJi8uL4XL8leHGYv38ZFoUq/Mkub295beaL/Pf EhljTL5Mi+v5STXp/Msk3ZmIcTlzPZpm12mC4WCcFmkC8gmemaTnL6/e/L1Z9OUoXw7T4lzi Npe6mrBeZaPnJwpX1Am7vFix8Sx/fjIv8pPLi/UqXWzGbF18nWfPTybQ8GA9+5adS2h8VTwr si/FIIVWFufzbFI8Gy3ny/z896L8e1ZO/+fvbjPS2vlimV+n8+piSa++cnJ5pL1cJITq8iJZ 4UPyuzxL3mejAloyPMpK6tqRlhw3stISot+n5MPN8F+nf15eX8M805x9u2EfAfyMrhdfV9nG tJKPp6NpPlsXs3Rxlnykey8Xi2VxeQnT/xkEk19W2YJN0vk6S67SHPRgNqY0mxKKk4pcwlXm 4SONamP51C5Xmtv31F/i8yH52/s39DmtNV0sl/M1n2XFpFT2ajxJ8slIIficwf/+WArtV7gf g/tVonCORwrdXAWEeuk4PBiBksPrNwD+Mlt8fpz1jXJcb9b3MJPQ7/rD0cqHPatLrIedBDsc vrAji8ARHo0T3Hvd3/L7mFfaccT+dnlvOHaK7suTQxd5Ovqc5RsQ4zydFOtkdJOT9SX7JOHg EsgdouCmTCsUR9g2Ag7SpyT2KUJZsI5USBlOW4iKkvSCDIoLqw4vv0vtdbYuElX7VoRpe6jY IRvygRbwQXKrbReG8pt1kWUbluazUbZYZ4PZYrLcw1VEcEeeoTSnfVzDyOHiGpxKe2+eYhO6 4KFIfSx3AimZVRyJARIqbuL9aeqKZvBk9U4YTplftDxYpEFIw7iSpqvwkSBB7i1VE8F86EzU biO1iJKUU7dIsYlqfX+iZgdpQ7VB2pFo2EEaBNxog9RiKWPvT9TvIq2p1kh7IuoCd2FD1Edu /f2JSlmbfoSZWut4EJQ5xnJbcZT8dKApdpHWVBukPVE1CIAbQ0WxwkMHQ5V6m3+tEXQ2/BvN o3440ppqg7QrVbNjqUoi8m5ZqkYmYh+OtSbbYO1Kddf/62yhxXpMunAE1iYJqbF2peq3LMAg 3zdbHoAEQ0V9f5puB2lDtUHalWrYRhost2XBWiJFUY+U+OFIa6o10s5U4zZSj23VbJAGgy39 4Uhrqg3SjlSV2LZU4yT31IWoLdV4xZ19ONaabIO1I1Uld7DWWWiL9Zg09AisNdkGa0eqKu5g 1cjmBEwAxDVBDzx0cABld6HWVBuoPVFFhSO3XEB75H+6a65W5rRGKNStus5p4VBcWd1btea8 2Vstakn5psbCyI/wbQmADhHpZ38AvN1froJXbH1KoEwRimnrqYBCfYkAqLomgP3WCftYsvsq L1T7HlUC8YD1FczFAgAKMNkvAHcYgIN9arcBIAWsynbN1EuZOosyrpWpc1inX5biwcLLSZTX omzsk9E4Bc+L5il0qrE16dACgK8iC3oMAO6wAOriqxHAMcVXP+srDesJ/XU27m0BEu5kQtVX DfRax1Lgos6a9fcPFO5/IVAoi+VDu/lrFKjeHbf59yRTS++dDKfXIgpbEO1myiJM6SdhXwZO 79GQpAt6iYb4GJiGnYm7In8/3BvUA2UnX6P4ptTOcEnv+QyK7ycBoLzngckQkFFLehvILYaI 2kbKJwlqUVBQaQAYbSioPAKAfU1CDVNHfSa9gwPKplktkRJaLbu2P57Gp+Nhn960CEufPqpH 2JNSK5k2AGqZPgKAcLhHWmc/9U71CNnP3qAGc/ZtpqK0om3jEVKVfTulFpI67Q0AbSzXj5Ir hcNxrQFQx7VHAGAPvwVpupr01r9rSzNs+XTTJqt8+qguWU8uhaRHhLb1oSM8zB3X+ujTpJuG Rm3SRzU0eirSIPIyN6gL3/pdUsfCN27pVAuPhFbVOtXICJRUnft+XUP/gbZ3RbIOpiiLo+r8 wkduv8VqMvmKZNe3KHKniVCrpyLZVTtyu4ZukrNaPcfkZgeavSVJ6BeFRENSkWQ75O/S9a9x 37/GfxS+KpKdm/zb3tP0t2qNd21vbXuPtga7RtOJ0s5i0+jeiKxIaonw2ZI0kkevensDLc3B 7FpFi/xDwZIt9e60cFxr9RQHITQqKToc2ACoW2udAdCZH6w4yMazYpmXIOhN9R0oqMRramYd HNnJUTVzP+1FaTW1CSghEJBBXWMqAxx9y+AgitgeRGhkcMxBhF6r/LbMKw8NdC+yDojgUE8S Va3bqrSqHbxrpaXsU5Za7rBxtX3Wyri6VxqHJesOGFfTaa2N66hOa08VdFXCt8dHjCjblMcc H+kgg3BIBk29U8ngCXvD9O7AbnqzykIGD2jNHhbBoRjT5HSNCLqet9ne4psiSmITtceVUXu5 KqZ5lo4H63SS8dHyeu/JMQVr3vQFq5Nb3fuC03Sx/pYuxsNsXvBbLLfKs/X6bgAUNwO9k4Im LSI2hZk730nVB5Td7gFl0R5Q/q/jxk5I4aTA7qx2jhu/3X/73dvTqMfaDNVkkMaJHxgxHg2i GeqB0kG7icjGOnV0uljunC524vvTxdgTgoweWZeG39K5bsE3o/auUUiZdHO3GtWyQk3q6aQ3 XaVCClghNVvmcUKH+uTr65t8NF0XeTYbTbPF5tjrhyKffc5+uel47DV+f+xV6Qp5dey15uOu Y6+NzvQdh8pHy3HGYEisWH4mJvYrM0h91Nnxdr4RO2fH5XgkshSKHU6GA5OZySCIsR0EhNdh CtnrSfiBdtWPz47bVp8Glqy3xu39Wr/t/VbD/z87fvfZ8V2zuOOIeCVcZ6AMTaeBKmX4uk5+ xCPiTj7YV/4jwABWgQe1DQplbmRzdHJlYW0NZW5kb2JqDTI3MyAwIG9iag08PC9GaWx0ZXIv RmxhdGVEZWNvZGUvRmlyc3QgNC9MZW5ndGggMjY3L04gMS9UeXBlL09ialN0bT4+c3RyZWFt DQpo3nSSS04EMQwFr9IXwB3/bWk0h2AFRNxgxI77kwVpBkfZtVSVtP1e4mjH7Xa2LuPj9Xx7 /zhe5Aih4+v78fg8cQtax8bPzEOhTYoLZQeJialiwwDzxMypcFVEGohHI5+KVIWZQdUZrym1 KkQGxqZ53WIdUbaL+EL/LRIVqzhwhgtPJasiSsAaSPKrjDRiNwC1epwtAdP1Oo2LIQrCLm2O SbQohCNvJ7GpcFXICMgtVKcii4ICrqaMUxl5M213sYU+h0lesUVCjqpwlkWxKEJj1+S/EbIq mgLjZTWbt3DJW9Bg/CNsbipdt4VoYWY26ki92rTu2wS8h+5YFLa8pCxC7fB+/xFgAIwe7KUN CmVuZHN0cmVhbQ1lbmRvYmoNMjc0IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJz dCAxMy9MZW5ndGggMTA4L04gMi9UeXBlL09ialN0bT4+c3RyZWFtDQpo3jK0MFcwUDC0MFMw M1CwsdF3SixOdcvPK9GPSixIc8nMS09KLCnW90vMTQWKuCTpB5cmlVQWpOqHAAlDMKkPUm5n h6zXIzWnLLUkMzlR3zUvOT8FaIqCkaEB0J4giEkgedwmAQQYAIFMMFENCmVuZHN0cmVhbQ1l bmRvYmoNMjc1IDAgb2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9GaXJzdCAyOS9MZW5ndGgg NzUyL04gNC9UeXBlL09ialN0bT4+c3RyZWFtDQpo3qxU227TQBD9Av5hZCRIhLx3X5sYVUVI PLSEkvJS+rCx143Bsc16Q5p+PWOn9IJUCSEieeOzc9nZM2csRAQMhAghUfgnQakBCghkDLMZ fQ8iph8700Cp697QhbamcWMAg3N6bnJ3GXJBMChmJGERRMmAFBvRFf28Xbl9h4Ftt+3ocng9 bprWZRlmP17gcobZ4iFbltGTS47B7PBc0RNrtKva5p12ZvIuFYyHjLOQc4nrG8ZfM/Z6ijUq evq8+ex0EppIB5IZXwUi8pXUia+FML5RZZGIuIhyHU7pAjiT47XGYrGsaESftrpYtFXj+ksl IiKT4Pf1QElJpHyE7+wyYUQl8t5+h68OhCmhiIgTkHFCYiXQKyRKYRJOgiAeOfs2uWicsb2z psrXppneE3nRFMbWVWPocpKvbdW7SqP5D2af7Zt46JuMAxKpGEQYEC6xc0wSgQyoUJEokn/X O57IJ73j971r8QLI2WS5NpDX1XD86cXnJfw0tir34Nba4WLgu9mDNaXBAnNTwGo/7nrfq8KD Tlu9MUgEVD04u+0deuimAKwCrk1jrHZjDN0OtECOh9q2hrYEjWkqWwwp3J5Mn9eSiCR/pCXk 7amYRMLYYzEpuYpChmIKZKB8JYqVH6NwfMkNXymto7Io0BHrRg42G7w3KisOngjrILPzk8ns 7c2mHijpsbS5h+x5b7PZqi32gIamn3tr57qU0t1uR3aStPaa8iRJ6M3abWrv4JTelPqJI+LR s0fpbDRF6BfaaYrpKcaUOj1efPjy+9Dj3LYr7VKOZhTCwaHvTD73cJSJ8CCbdVBUdu7VznrZ rO9084Chd/vazL0Suff76takHAXQuSNnbpyv6+q6SWtTuqO8rVubvmTj72h0//piZ6rrtUub 1m50fdgc893teNm/yefVj23rjlBDh5f/J6QZHW6fzWiHz9CnbHqYJpQL4Ry/nyEJwgh4FI8Q Zwnh3Uyfta66fRjlJRL0/BT/EmAA5Zqo5w0KZW5kc3RyZWFtDWVuZG9iag0yNzYgMCBvYmoN PDwvRmlsdGVyL0ZsYXRlRGVjb2RlL0ZpcnN0IDEwMy9MZW5ndGggMTU4OS9OIDEyL1R5cGUv T2JqU3RtPj5zdHJlYW0NCmje7Fhdb9s2FP0F/Q+ECrQJVkn8FCXHcZClK9YNbbM0WB+aPNAS FWmVJVWi67i/fQ+7lBzXdhbHDbo9JYAlXpLi1z3n3MtQwRFGVAgkZQjvEIWSwjtCJGBQCAQi kgZQsD8uEOUcUcmgL2eIhrYPp4hFlECBII4J9IFmLmkEBYl4SBkaDv3jU3i8RSRiMOHZaOSf fCQeRvaHPXzpn1Sl0aVp9z5o1Oi4mkx0mSBTIX0d10Ue56aYI6gzeVUik2n0RRV5ojqzSpGT K+MgBZ84+rp2UJ6iuqm+5IlOvH3/pNFdz5fK6L2XA4pJgAkOCOERkT9h8hzj5/v+K9iQ/2a1 ncIuw2X72zd7QkexShh3xxE8OAsklIhyRaJYgIWIRcCho5po2JDdgvFPUSjslv3Tqp7W3Vlb 6+xkb3h0PSnQF920sLRDB47CORoNx1UyR9BQtodOZkw98P3ZbObNmFc1Vz6Josi/zsykcPpO g+tUrXUEu+vZxpmeKB9MF45J+TC8D9+kanB8+vrPm0mP46YaKzMg0OwR1ndoax0fOhRqqING wxoleXPoFKZxRsO2VuU3G7VmXuhDJwXvuW3+VQ8IeLM2B0ZfGxc8dFUOCp2ag7gqqmbwFHd/ B133iycznV9lZlBWzUQVfWU33qLGGT0MC88+TytzAIDoCx0q+iJAY1G3io+hbzc1Gvo1/Ozx j/b9Mx2bj5xHHqcAb8o8CUzhgextTqx96b+fjv/ae1uZ/Ou+LZt5rf1z2Ll/vhdnTd6aXJX7 /rmtPi7LyoxGQIIOZu9qXaJUFa32T1UDWwFg8B4YdmaAHhCDksALcYRkZC3GOutyOVMHqM3R FzyjAb6HZ++OpyZD+aQ/0O6Q+qq4SjRKi2q2hTiUSC5WiMP91+f+r+DNwnoUTkRvEIlIIVaJ pIMkEoxwV4QRc3kkInecKgUPrjhhY5APtQ/cIeEad6LO+mOqktMqh118pIR5AmTLukRgCYdE PSaCpb1sZ3ACoD3L9t6+fOThLjzcASt3kojCSmxwYQzegfWQgA32HgoZW5Do914tVYO+TpGl 0DdCLWH1MFaFt1hFe2gsWNUDZVdWyfuiV6YMyttOlZI8TTWsItZorM1Mw9qcvG0XYUpNE+fo ovm5gmME/ZrqFsGSuw9biB8vUNXcVMBTlXOkkyuNYtXq9mgLM2F79HuYCTGOrjKTcEIYjUOX MS1crrFwx3GkXRlqEeE0JakKLTPFGjMhP9hgJsPUC4BpJAq9iFvGhR6NVuyb9jD0QAm+tff2 IzN3i5Db8bYIhW17KxQC/PrC0bOnhB08DIZ3kz6KvFD2zqS4Jzu2NtRTSf5r0gdik/SyB13P +QUE7+H8XYNztjk4Y5EXQF7Qj85FZ+2mKDvkw9bDmaphIa1NW6xnfvtwbp3e5lc2MbJOBa83 89roBCTF+ZQngLusmhaJ7V5CEgXAsAmUQrXKG5skmVmFPul56100F815ZkfrPxhrSLM2syyd vICGWE1bjSoLhVkOpVpXdQHQWGRntvEGN3ZslAJ2FguzqZldJyy5zMurF2iW5XFmNzFWCaRi KjZ5rLem6pzxLak64YKvZRhK0LEOAuxqGmqXYxm6ERWJKzTBSqg4FBG7laqvixrnj6n6dwnR d8C0U51egQCuC3naFbP9x/bxPyH34sn92L1TDG3GE0iBOIiglQkmWG+vCMWPu0bALXxDnjgO PEluxE/Qztox4eFiKU+4lyYrUSvydLF30lRti97nRqMz/RkCiEGvANW6maPTBvKN2B7hxf42 ajMerqUsG8xmQq5lKCGTGMjtJjSEu4NmkRtySV0d0bHAmsg4DW5nKJw+knlXMu/s1H/F/EuA ir3W2f903Fm4XHAD1i0oA1TCphnczwgkCNja0mNYLLjxC9BOp39fGVCE9TzhBFD/MJ4weSuM w9x4yRPOOuuHhvFFojbWpU7hHgWSNm1ha12ldZc7qVqrokUKYfxDNkcwDcgO3LvmS42aZRUo V6babMstgDA4wG3RkkmyHi0piRkNYxeuZrHLwzBwxwpzN5ZKcZlSlojxrWgp6SrBWPhIsIek 7bugoYt19wPizhAkIATQCEIO3H0txAXlvb0C8u8MQf8IMADCIc2GDQplbmRzdHJlYW0NZW5k b2JqDTEgMCBvYmoNPDwvQWNyb0Zvcm0gMTg4IDAgUi9EZXN0cyA4IDAgUi9NZXRhZGF0YSAx NDggMCBSL05hbWVzIDE4OSAwIFIvUGFnZXMgMyAwIFIvVHlwZS9DYXRhbG9nPj4NZW5kb2Jq DTIgMCBvYmoNPDwvQXV0aG9yKCkvQ3JlYXRpb25EYXRlKEQ6MjAxNTEyMTYwOTM3MjYtMDUn MDAnKS9DcmVhdG9yKGh0bWwycHMgdmVyc2lvbiAxLjAgYmV0YTcpL0tleXdvcmRzKCkvTW9k RGF0ZShEOjIwMTYwMTA2MTIyNDQwKzAxJzAwJykvUHJvZHVjZXIoR1BMIEdob3N0c2NyaXB0 IDkuMDYpL1N1YmplY3QoKS9UaXRsZShkcmFmdC1icmFkbGV5LW9hdXRoLWp3dC1lbmNvZGVk LXN0YXRlLTA1IC0gRW5jb2RpbmcgY2xhaW1zIGluIHRoZSBPQXV0aCAyIHN0YXRlIHBhcmFt ZXRlciB1c2luZyBhIEpXVCk+Pg1lbmRvYmoNNSAwIG9iag08PC9GaWx0ZXIvRmxhdGVEZWNv ZGUvTGVuZ3RoIDEyOTI+PnN0cmVhbQ0KeJytV11z2joQffev2OGl6UxQsMEY940mtE2HfJQ4 07m30wdhL6DGtqgkN81j+8vvSjYQoPc2DReS2GDpaD/Ont18hQ7zoWPfzTUtvJNJBHPt+WDf au6FYR96Hfod9AYQhfEAFHozz+2yz796fn3fXNICXieEEkPMYkhmXo3sQ0Q/UZf5ASSFd3SJ 5l6qO/hIf0Q5h7dKVkt4wus9g9eKZzk+HMMoYy+TL57vs8Gg40My9o7OS4OqRNM+U3xmngK4 /7omg16+qLHKDDPQhptKv4LR9yUqUWBpeP6fCAmDscwyVNpgZiwWbRUKCeN9VSL40TEEHb// G0POsDI6XSAkmOOdLGD41mI9z6vm9Y7B37zMppibg7Ga1ypez9x+hikWU1Tghy4qIWF1Q9bv EtdsSptlozKVmaVKmnNRaBAlGArN1bAyCwhcjhCWXPECiQJQabuWw/uPCeE9psju+ZllSnta k6otOeG1v9ybNtoDMWs75HbHmhV0WdTvBA5mONVG8XQVxWQhdA0FSyW/iQw1nU62LGQGM6no Q5oLog4YCTU0SKICPSmkwn0bKeWWabpebJ0RJeEU3AhZAp/KyrgAaNTafiNKAn4UkcauljO/ tYkM2/Fjgl8romZ91piX84rPce0Uwh0+AJVqpqF1cXuTtI7rK1xeufvJ6MPt+WR0Zu9v3g3H 4/VNvWLfMXp6dTtuNti7DdTp1cXF6PKsRrsY/kUX4iq0rq6T86vL4bhVZ13oxr5MppU1HLhC G9cp2jCgWiryNANOGUGdKjGlD7STdo0S74NXC9KfiFe3P4CQ/CABdPI1eXMKge/HVn7WkH+m hz0/ZGGwhQqftvD+zMReELHerpGH2tgfsHjb889OctvdOLJP2msmZd7RjZNJkLO6GC6wkHbt Y7KtCmVHpukbXU0LYUydqFmV55DKmu9linAviNJE7n02uWKzBeAOfn6G/ci3DvXCgHXDgXP1 9ek1RIMDwhd0ItYPtjAdnw/IctCNWDfYN/OQLAdRwOL+FmadZBJj+2AryRTy7eRpV3z3TR9f VaTLhlWj1WLS77kokfonNYudpm1ZwfUdvJGKcv3jfJS8+ckALiUpullwA5KQFMztjKCh4A/A cy0hE6TAYlqZlVztG8F3qaZZrWo57bUmppVSVkDWqxqoxjUiJh1/AKv6fdbpQTemCDehXRiz fHVyknGqFuofd6TIAs2MSTU/cf1DnzRGnRxSuYHPev2tg5vCDTv2wVNyWnezTTC/8VyselnB v4uiKmwItfhOLaw0C/2LvFq624SRMldL8hmzYxoglzlP7R1ByamWuVPr6UOT50fpI2UvH5qU GJq8KHvnTi5EyZdU+kslbNsn6a807juh6awZUizTFUWofRIFaXyjo2lXKhzFsGiOJraVdlvL DaekRHTGnOY2zVo7bfNflOxekHKhG/aovW9Pe7bzHp3K5YMS84Wx9BZruzZf/0h/uikIbBlA oiptXBRtMdH4qa3S0XRRGjETdY/7pS5uWiNNA1JZ3g/JNHeGDYtG9Q2z3WFgPcisdtfK/AVT N7c8vxCCMGR+D4KgT4Nd9D/Ja9xh0WALcx2pTfBe0FSDc57XiubHdkt7Haya/debJjLBnCYs EhFy14GcrdhoAXoRC/04drFa/xtC4sZz9miibIb938z6n65p0AL/8yqo5AXcN2GYvPUict8P Q5+Ra4UXBuHmY+7d0Pp/AI17fkoNCmVuZHN0cmVhbQ1lbmRvYmoNNyAwIG9iag08PC9PUE0g MS9UeXBlL0V4dEdTdGF0ZT4+DWVuZG9iag0xNiAwIG9iag08PC9SNyA3IDAgUj4+DWVuZG9i ag0xNyAwIG9iag08PC9SOSA5IDAgUj4+DWVuZG9iag0xOSAwIG9iag08PC9GaWx0ZXIvRmxh dGVEZWNvZGUvTGVuZ3RoIDE3NTE+PnN0cmVhbQ0KeJy9Wdty2zYQfddX7OQlzUyM8H7pmxO3 TTNpklpK85DJdCASlNDwFgC0o741X95dUpQhxW3HIWvLtkYieHD27GIB7n4Ch7ng0Gv/nlWL J5cxbPTCBXqpzSIMIwgc/EuCBOIwTUCJRbGg0f31Twu3R4D9W1bB0xWipJCyFFbFYkB2Icbf 2GeuB6tq8R08Wv2x+GG1+HUx3HZXpMhlXtAj/VwboWphzi4ULwwc/Zyv10pcSW5EfraSphTH ly9EJqq1UOA5bkiE/JBFPpq4eokMAf569PCG492sTQMWR44HsYeQPc+tMe33T54Y1WkjBJPC FKxRmyelzEStxZmsi2aCKL6T4EQ3030BWYMoCpEZaGowWwE56gBNQZOceX6MA89clyWJ48Iq 7w1uuzXS4UbiHU2BN0kNeZN1lagNA3hTCq4FkKTimiDxw3hZE+wBbtAv40oUXVnuHgPXNH4H udCZkmsBu6ZToORmazTwOkdQbZTMaGoN19Js6ZsW2aMPCMs0X9F51uQC/1VtUxMBEJ+N4hn6 GgrVVMfDoULZ91CyzsoOb13Kqi1lIfGGp8sLeDk4AgziEN+Rak5Kfnsk+GnMYojihDlJ75ml 6K2EYIK3g9BlbmSjsoNr/cSha6e+pQhYUfDBS7HhJbxRzZXUvdykP7oKWvoqR4NJ/6YzcM2V 4rXZoRy3uPdIIIK/XVCG2nn+sBzozhVfl0QWXYdLlyJncMu3S5wkLHHTFCInYjG+kx7uBHVp 8VKms/Ew3jDTqCbvBu8Bu+MLjlPe3SwMUo/FwREhb1oGDdHI1B2gpnEb1bcRp5Ab1bfxUL4V Bpg2lMJeLF+/gndiDavmo6ghK7ms9D2obxPyJ6qf+MzxZ1XfQpxC7qC+hYfy/cZLifuHrDf9 Sh8c0XLFK4Hb73+thlnUtwiFE9WPMXuGB/UD2kuUGKzjcCk+dbgZwY+4Owu1o0Rp9in7L1W0 X4aAgytedoLBfPZZpKbaF6bMiw/2TWLnOg5uXzZiwKbkVtdNWOgdAaJ+S4onPCrAs1LSlnC/ adUmE02UPoiZn1rSB8wb7SuF1jcG3qd9Fqmp9uEROXRnDS0LMWBTUtcYWhYg6neJx0g85AiN +7c0/bMArHd9FvtZ6w6T1/8qvUVmqvR4iIrm3TMsxCkp57BnWHh0Xjp/dU6HPI1nSsWHk/09 L2yL0FT18fAbh7OqbyFOIXdQ38KjlCOyTkk8u3+TB2ZRfyYDY0JMWTLrjmYjRnPsaDbgmPEx +eRS7Q8P9xn4Npl4ovRJzNI0mVN6CzFiUx4VRuktwIP0vzQ5Poruixn3Kb1FZqr0MUamO6v0 FmI0x2ZrAx6kx4xTYMapcbctKQPdm/QWmanSR3hw85MZ072NOIXcmO5tPJTvPPtYN9elyDei L8fdrUAxi/ozGUjqhx7zw1nVtxCTOdS38FC+V42qMNNcUcYvhBJ1Ju7ggVnUtwhNVT9wWBDP qr6FeN62os7lZzifkn2ChHneES7KeDEWe59LbRp1j4nH4jElukh8D/PqzXZ73plto/RDOM9z hc+PdwmrGe2zSPX2nQWeSxfODoXdfFrJFTN3Sp2XwAlYcpPV7JJrP2/YDzuZGGhg/0T3mvQC jzl74eSfw/7fqsY0WVPC+wli+D4usQj8xGXO3tmXPz6L4iCd0reJfZYGR6Af4HFvzJEJQ2nf 8WjwaWlfC3WFz7HL56/fvryAVqgC0xHwGsRnnhmgxkq9gaypWq6kHns74paS/gO1P7D+js8O D6wCX9+RIVL/OEKJDa46zH35vp6PD9n75+ysr3n0NVypAX8pkPvTASBTdI64oo9UW+wruqXg H/lG4Kex+bOVKqe5jMQFIG1f9y2HTBooyub6tNVAC0gDp1ZSV5pDS2vgg+8oUd2gQLwQ5Q54 ng89JPjUUeHvYBt1KE6E6ttR/6KG2XIDuA1QiwpxJbkQzR1mHsqnh25UMWweTX0Lfap6DyUj +OXtcgUdNaho4h7iaMZmnG/doC7PVKM1LGU/zwn50wpne1Ph7FtB9Q4QAjGHMq/FEFDoa6m3 Qt+05dB9fQD2vpRGi7KgYOAqH6vF/GgtqmH2W42ljl3fxkVKbUPZjkMlsi2vpa7gGjkJjKkK nSnbcixDc4MBvu6M6D36tblrsVeGGlVImJ92EF68W2Fi+PYOnxuwMAAPF2cSx2NeiEN3Ul4I I+qV26AfeoUpAoZu6lCCHtq5SUijTxPDsM6/DhZGN8Uu80aVniqel2L3GIQBXjKrR/7D5xYD XMOLrhbgxo+pVx7B6c/7N7RevQ+jiBGL4Hpv9eVPOBUZTKfzCKpF6IU3H8vFEsf/Dal/bA8N CmVuZHN0cmVhbQ1lbmRvYmoNNTYgMCBvYmoNPDwvUjcgNyAwIFI+Pg1lbmRvYmoNNTcgMCBv YmoNPDwvUjkgOSAwIFI+Pg1lbmRvYmoNNTkgMCBvYmoNPDwvRmlsdGVyL0ZsYXRlRGVjb2Rl L0xlbmd0aCAxNDAxPj5zdHJlYW0NCnicrVdbc9o4FH73rzjTl25nEhXb2MBjWtjddJrQBmc6 O508CFuANr5QSQ5l39pfvudIJjaUaachQMLF0neu33fkL9BjPvTo2bynhff6ZgBL7flAT7X0 oiiGfg//hv0hDKLREJTwFh6ttte/eL5FgOYtLeBNgigjGLERJAvPIfswwNcgZH4ASeH9Aa+S f71J4n303LbfRYp9FvQt0mVphCqFOR8rvjCw97iYz5V4kNyI7DyRJhf7l8ciFcVcKAh6fkQO hRGLQwwxeY8eAiQrAe8+JVDwLcwFaFEa2EizqmoDEs0ulTRbWKvKiNTIqjyzV9tLr156vs+G w56/Q2zXIvAMPuOKxyT8Xjr9YciGMeYiZAOX0ps/3w4iF8cTExsEEev3u5h3Z1ApF9W86oYG vMwgrcqFzDArkucULlo+96M+YZw/Bp79GPgEA+96+bTIe2ih34k8fobIW8w75uqf5pLKLjUs lBBgKkhXVaXx00r8LGC+xpDXinqvG/wC0ymNhlqL85QjDNeEBC+0wZUvYM0VLwR2NFok+IP+ MUpQM9Ouas2/1ALmW7v/osa2VPI/bq3MhHpAiG8Xs+/s6S2GPIsxuNC1QnAKY2M2Il514Jr0 2rDh3Wx6DZ/EHJLqXpSYcy4LG/55ZDdiegPsybgX7NJLe6cU9EHkSmBStDmST2xWLTWmvloA J1ofSe8JfBz1nX+xP2TxYNTpy9EJifPDmIX9PVCi5Jpi5Xm+BS2XJfaDZahTlKcTKwx6DEX+ xwhO0ZQwDhiOj70ISFNEmart2rS+T2y9g5FPyw/ZdEpYj5XpxWwwGj2TYuwq0wHFymxWJA1r vs0rbvXRcFnqpqGJtZlYSCrYSijBbMRxhDjo3mGHq8X6SIfi42by8fbyZjJmSB4ly+XODH3k gLyXC8nnOOucNC8kNj/JDgnWyx3IXFUbjRe00NpOLrPiBlJelpWhWbdEFmn0E+WF4zWpMqKS 2TratjjOXOrIh8zCpRpELgoSzUabGgltVFCj/qGWVkULwtNUYEuT/wdk1mtkrdCwFKVQVvlk +zOJMQa2FFkL1fC/u8N6sQtACk2K+Jhrl9V7mf04q22q306vribX48kY5GJHtm73Yj4u2zTb BAi4F1sS+AwdbD2jzS49TvOMlTpMOu2QWtdC/RSsRcKwG/sOj44oP8NMaNHs7+nt+zGWtsWR ZZrXmcupsUedySkKGIQ+C4fQjwIWRsPnGsyDgI3iPdA7JA/PMDInGDiyccEhe3DuHmfP9ENy Ob2+eE95kQW2Ci/WlOrNSjTl2R8oN81A2XDdyRylNjvSSOLr+mgjda3StMd1L+Ab/pfKmTHo y3enEy1v9T5nD5YDMU4BHnqxWTYrma6aKiZwdTtL4HqaEJMdubDKSJUWC8mYEvXLZeNS+8Ou 8ZyTziWilVTWIdddLVJaK0X0zrABX1u/rHW0PBdo0h6Uuq6363Icx92+btqwY5cIUaydmgil 4eriH3L0ATNkJU1XCKMLnIQtSi7Ehm/PkDO1nZBlBYVzgyM1YCE2UMiyNkKfEZMwPVWN7hNc mlfpfYex92JDHqCaPPC8bgPjUNb2vqGrvCXgnciYWGgXsxbnFqVqJ41NhfV+R+B3fB2oTVPM FueUuwU/YEifYNBnfjR4rsMJnub8eA/0bk+IMKa5oORgzbI63WkxnlZnjrx4kvfjI7MP+fUr 9jazr+HKlj4Tsh1SrksdSTuS25lauwod0JfXx+fAL802I65hx6PGu7aRXeXARi4zx0ZyIBqx vjX0RvEsF9i3wgDPWecudULcQeq9q0sB/uCM7lZjOHx8/sCXAsK7XY/ELIZNU9Sbv7yBT/XE czhuLbwoiNqvuTfD9f8DxuxB+A0KZW5kc3RyZWFtDWVuZG9iag03MCAwIG9iag08PC9SNyA3 IDAgUj4+DWVuZG9iag03MSAwIG9iag08PC9SOSA5IDAgUj4+DWVuZG9iag03MyAwIG9iag08 PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE0NDA+PnN0cmVhbQ0KeJytV01z2kgQvetX dHHJpspo0QcSOhJD1riSOAG5cki5XIM0wMTSyNaM7LC33V++PTPCkoCU7bXxJ6j15nX366eZ OxjYDgzUV/03ya0/5yGsheWA+irX1nAYgD/An5E/gnAYjaCk1spS0fr6neVoBKj/JDl8iBEl gsiOIF5ZBtmBEL9Dz3ZciHPrD3gf/7SmsfXNMre9FClwbNfXSDMuacmp7E9KspLQeY2Xy5Le MyJp2o+ZzGj38oQmNF/SEtyBM1SEvKEdeJhi/AkZAkhSrqm8zhi/ua5K9v6d5Tj2aDRwdgH4 uvgazy6+jD/ZAJfzGSQFl4RxxtcgNxSyIiGSFVy/qQQuRdaUS2ACZAFLipA1TklTVtIEmaor mImKreSmKNnfGsLGWNezw2Dg7pYn4glKQpaKCUtxTbba7lh1cAFZ3eNickMk/mKizemuokLC AxEYhbRlcYTFT3m8MvPp6cXnz9Mvk+kEixPjuj0M7cE/599jmE3+hSQjLIfbsrhHggIIVJzh gs36NW+G7FZFqanjvTVY6+I9ySoKny8XMZYUqyLYmmMdGW+gCOSE812alIuqxCXrnGlJVUcI cLrO2JotUShIa0mWLGNyq8MaKEVDkJzWyz6wLNPLJommRLJs23BQvYSUrVa4BhYwJZI0SMXy J3a8UxxTk4RwBYmC0Qi3KGJdflMAWJVFjtexne1e3WZkS9MOmmGoU0uIoH1somCS3dNaGUq0 gkKxameH4YYF/vMopSPik9cbIjZPDcU4SagQEBc3lIO6wZDCKzMpGoIqtSVSDPyqzBo2lCdF qmRbrMw80ZXs5wVqckOy1e5TDVv/X+AIIbB51wCNF6ezmSoStl01SSu/vqVHNMdrqTjWRTuB By2LHXxLSdkaZ0ductOemrumsH+J1/DZuge3pETN4FS32m+WXyAbagr0TmB/F/ADYx698WUu 66IxDkbgB77teiNtkPOPp+HQ+Nv/NFxv4NpB0AG9gg0lKS2xjx9xNBkXkvAEy8ZM4XGxvus5 6rb+oz7SXeamJFi63nzhDoPeianf75qBMyY3sDgb9zH4RIVxtcCh7iS5oXs6cdwRLBkqgvC0 UZgRlo7NzcQ0benVyj4YHzgyPrEaF/yeT79dzubTCebfdQo1r6/opxOoZ7PvBHbotNsZvaKd +LSzg1EH9AozUirUVVf5aHdRJphWCUp5udXJjBeqjLq5jjdQIEeay4So8BbdM7Lfz3omuk8g nMnbggtqK+Q9m0me5TKnqpnPdJdHUzmYxBe6izGVjgUfcxcltN+4yp5jtJ58z3QVM4SNuRz4 3tuaixPZQ/BclE8YvpG31IbVBn3CWx7dw+gwGqj7j5nM2WLouB1vabWi8RQMMp6yZx/HLUbL A23oWaaCKx5YSdObF3jKW1iJjyX2A3BHgT3wwjfyEj/w7IHfAb3SffEiV1040pcXOM2+l+j+ He/LE8ZysH3RW0iFXuLOEDdsaap+mLqNZGYDpPfoClRzrTtaEy21ER64korGI4Co8sdZ1G0j 9dDrfSNqOskKQXGfWNJMHU5AbWUlwx2pKGp9JEWWMVEnwcwEKESzNeOIg8GbospS4IXUG1C1 MjI7dlJoZbs4u7j8NAG1P30LVbnhCD9QUxhFwRuJynMHNp4226BXRgPGwNrIL2PrRQ7W5Qjd 11iY73m25+/RRT2KKkHVmmkIXBWyPw0PxBwugEm958dzGB7TjFKwP0TiKaXW3fn38esyx7N3 hCTDyHacduaj12TuDO2h2wG9ap5XJnPfVyH7mZ+pfd9urm/oVkkbP9GmiqaAJ+EizylP8UCj YPzQRklFWs4fSpJmdHsCVOJaNjSv6a9bpo515xWnSOpE7XQC2H/9+IpncPCvdpoPbCRSJz// ywodlXcY2Hhrbg3dYfM2sxYY/x/zq6BtDQplbmRzdHJlYW0NZW5kb2JqDTgzIDAgb2JqDTw8 L1I3IDcgMCBSPj4NZW5kb2JqDTg0IDAgb2JqDTw8L1I5IDkgMCBSPj4NZW5kb2JqDTg2IDAg b2JqDTw8L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTUzND4+c3RyZWFtDQp4nK1YXW/b NhR9968g9NIVaDTr23pM03ZLsQJd4m4YiqBgJNpmow+XpOJ6b+0v37mk7Mh2MqC1kxaxZfLo 3sNz7r3yFzb2Azam3/5vUY9+vcrYXI8CRr9qPkqSlMVj/J/EE5Yl+YQpMZqNaLX9/MsosAis /1PU7OUUKDnL/ZxNZyOHHLAM/7LID0I2rUe/sOfTz6PX09GfI7ftR5HSwA9ji3TZGKEaYc5e KT4zbOfn/PZWiXvJjSjPptJUYvfjV6IQ9a1QLBwHCQUUJX4aIcXpH4iQselCMKl1hxXvzv9h Ws4bZnDt7d9T9vH5s4f4f4yJEMGPQWaIu9kUrt5cZEmQH0FJNA79NB1A3rCVNAtEeo1Ih7g/ FmqEE8vjg1CTI0KNg8RPwp1QOy2bOWI9J9izKI5pwVkQ+JPJOGDT0h7GMWnksZ+lY9w0iPws HCQyOSKRIEr9KB5i3jBezVsF4mvmNW0jPCZnTEKgc1xcs6VqjSgMJUsyKlp80hjN2plNPE2A Nz7MnNZ62kDFHltyxWsBxUOYrGkN3Pilk0qUPkGEkcuz1+/l7Im9dGcuG43YZq2quZGtU3ZR SUTEylbo5plhK94Y6Hwbj4M1LSulLqpWC3pN+847s0Di/zokLdQ97tIqnKxQL+yKBx8BkFBE U6j10pzCUMEk9ycsTWI/Ck9kqDAK/GgHc+uo18c5yjn1INj0GPfDMaiGw2B9V73gqaOijcPA jx+J9hjfxGnkj3ejdb7PQ7q+r/4HS33z8Nr7Drswr5TKY7wpNzIi2Q1X4rJdSch78vXOg3By 8fLi7PfrMEmBogRcVLR1LZpSlAyOYHqNd0bJYoDvQ6D7Butdw+GEdtds97zqBLsVZPZCCWpB 7HZtl1w6K+Dlobc8+MQl5vGu9GBILmvN3n24ngIMfi2qjoKU207Un/TnlbGrenfxSre0gXoW lvfSPa5tRRkdWDLB8UX5ibpBmE1wYYhJ0u0L1zVRiRJzJxoqd7aEuFysYMJxhr0HekF1K3EO xacF1wvvgLp9+OkT8HsHw9l5UQit+/UeN0/h/zzDGGwSjCCoXJaJ6JgZKfVzmmSGeMj8L17J km87kNXqQ1+wrCZ2I3y41brj9cMSFoNPhLyn7Xx/87B/1J025AC6F5gx+hFCt22xF3C/FXha 4DAM4xo3cQK/tG2iYegqcibxsfMOwZDAuenU1oCk8m9ou07537fDxfUx2o8SjMgTDMFQHM2H J9F+lAdgeAd0U7fvxJp6Z+kKYzimdQdjQbs/kf58nXcdNIZqgmBy2hY6BL2xc7Q1SymLYU28 kyi8UlSlI8DmHaRjAtjPuxcKIXVUd7FdsVpwjDOgZKu6DS1US0sSaC2bp7TIO5KXkQXJ8bDM D+RpZYhyXloNupBpjNKyFKcYZaIMBwHSwomf5Kc6ib6LD0FvLC/gTzuJQd/xIxJbCDfjYWCc yTm5jHKkqY6Jr0u4Ee1RWCgtis4NuZuCoHtHPsH3dlx8gnBPzZZ9/9vW2M3hbmXTnwreoX/j zmR1lA7TPjK1Ur0TaMVmb+rlhraQ22ymtle7Vm4jsI38qRi53oSIirNUYKtxbRjxKLxFzSw3 M/KHq0tME+WylY8N1UrMpQZriILr/vYCUw6eFz6BWM+OJTbY8+vjWkw0zv0sz6wM4hO0mCEe 3HtBBLoOcYVnE4FO8KZVc6HW7H3//APav4Hb7z11PcP/13wGDnTsulPi/ZhleSl4Qw9EkMkc d9VOJByfSVU+okGoBWrlxvDiDnLu7WBPa0bx2icrRK9dRYL0aVCseQOJt1rL22rTglZ8rXek g2HC5cQodQDNsJ2MYlZkpboGAXbTSlYVAu5xKhJA+diYaWg+IYVXMFaF1rDciGrZqXspVpvm R0nJoqu42tC1WshicSi3uWiEcg6AWRdtqV9YCuzyfuq0D25rFyTH8LM0FFue0KjmviN5qXhZ ifULBlPxyh98tfL66xLa1exth6IbZC/oK5aU7f98fM9BdHKz0XPqp2zVS/Hqt1EWkAqpf2Ss HiVh8vC2Gl1j/X+0BtifDQplbmRzdHJlYW0NZW5kb2JqDTEwMSAwIG9iag08PC9SNyA3IDAg Uj4+DWVuZG9iag0xMDIgMCBvYmoNPDwvUjkgOSAwIFI+Pg1lbmRvYmoNMTA0IDAgb2JqDTw8 L0ZpbHRlci9GbGF0ZURlY29kZS9MZW5ndGggMTEwOT4+c3RyZWFtDQp4nLVWXVPbRhR916+4 w0uaGdhaxpLsvHSIQxoyIU2wOn3I5GElXdlbJK3YXdl1f33v1cpgcNOGQm08BnT33I9zzpVu YCRCGPF7+M7r4MerBJY2CIHfZhlEUQyTEX2mkykk0WwKBoMy4Oj++k0Q9ggwfOU1vE4JZQYz MYO0DDxyCAn9JKciHENaBz/Ay/T34DwNPgf+2GOR4lCMJz3SRePQNOhO3hhZOrj3Ossyg2sl HRYnqXIV3r/8BnOsMzQwHoXRvYIe39o4EnFfz0SET+htOhXTcDbbwxMAC0cdlF0F80ph46zg BCdh4kNPxqciiUc014LmCnApmy3kPhLcSjqQBmGDGVg0azQWaqkaRx/6h7VK0zcngFIbyIze UJjlDGEoptNRCOmHHpfi5QABVhVIp7RB8fJFcFuAD0xXaPG2glw2sMQGDaeQYGRT6BrWsuqo KOVWYLuyVDkHA32MbrcE+SC3b4MKcE7m11QAoTbawbKjDqDsXEct9phWcAHKDhk4e4YEyCh9 wQU34lZ42AolKKCzFFEog7mrtiBtH+qxdDngHJmyPeLG/7te4lEsEiLPK2b8DIrZR9xppuLp fJdoFrrG/0M0nVXNchewIyDX+lqhBTr6Lr38EEGlc1n1V+Xy0YpaSbsaGMoks6dZqO/S9NPi FWS6a4pDPe168JVwIZp4NneFsihUQ83V0nFgPxJSFYluEIHMcwbJaKk4TdeVKaCVxqk7Ce5V 5nXo1eVFNcDspHUnqge9/7ZSlOKXs46tQvZolqRLkqeua2yKgazdaAifzi24Ios5m4IyKXM4 ADraaiLUHoMqaVweYOhwYI2BlIPLXxcptEYXXY7fdANk2+EUjf7ybA6yWmpD9q69yXlz5AYd XDd60xBF1AQVqZzFagek2Y6c4IFc9nh4mukm46ngO5g33ekzmG4fkVi/QtvqhsQFF41y/X2H B8M9XVjbofl+D9Zyy4LZqKriqdKsDNLMtN9drAYa759enN6if+M+Ym2tCj5PvzlaaRzNjp0b TZthochAV3hDW9PBW22WaLbUxUUDc8lNbMgSO51+K2u/NPnioKCVXLMpW4MnhCqzStkVFgMI tdCftSvVHj88Sdrb65bt1TooK5ICKeBumv9Sz7Hf7c4wzpGy9mg3yj3veQnvZFc+x0I/HYci TpJeCdFTHm5iMTslRe3jMSdnH89gTpOjxWT8DHstRX305EBLX7hr1g/S0JfKusFa3qx5JVUN MiPH/QRfGehg4RIbhc67mpmp5TXyYiAorxUaGRckhgl+JG0xZ1dv53BeKHLtK16Ilj3fUzMw YLCmjP2CbjtSRu6JI05kc7iiCO1plIzDiUgiP8L4GSjZx+M7LC9Y5bb/SMssEiM+y7S8NrKo cHsMtAZlJfYeRM//aOmJw8L7rkEIk2N+II3h4evLJ7o7Qvz1tpWYHhE3Q0NXPwdJyL1QtWEC dRCNo7s/q2BB8X8BwldOOA0KZW5kc3RyZWFtDWVuZG9iag0xMTIgMCBvYmoNPDwvUjcgNyAw IFI+Pg1lbmRvYmoNMTEzIDAgb2JqDTw8L1I5IDkgMCBSPj4NZW5kb2JqDTExNSAwIG9iag08 PC9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoIDE0NzE+PnN0cmVhbQ0KeJytV9tu20YQfedX DPTSBqDWXN5ZBAUS22nsxnFqKchDEARrciWx5kVerqyob+2Xd2ZJyZRsOBdGsiGJu3v2zJkz w+UtOIyDQ+/uMy2to6sI5o3Fgd5qbgVBCL6D/7EfQxQkMShpzSyabcZvLW4QoPtIS3g5RZQE EpbAdGa1yBwi/Is8xl2Yltav8Gz6t3U6tf6y2mXfixRy5voG6azSUlVSj0+UmGnYe724vlby LhdaZuNprgu5P3wiU1leSwWuw4M9Qt8fmhuw0PAJGR8QWxyzmCdJD48BTDRGAFcyy5VMdV5X tMGYR+3UseuxKHRQ1wx1xaAhLXJZaXix0ota5f8IWoJpu13JRkOZzxcariVeaPFkBjNVl6AX El5MCJpzFscOh+kbA5ijwlWG0643ZlILb4NoYCmUhnoGogKhtUhvQNeQ1tVs1cj+3Ge/GCRR ZZAKGss1zcxkkd+h/gLXZBJq/Jamsmlw7EZW9IFDuPeyRg6IJ3QHRNDthrg6xd2Jo0rlkmbJ 0gTESIrjVgpaCgsk3PL5nGcdUN40qzayslZEGbHqioSAyevL929OUKZ53mhDMsMveZVqGG21 +7xS+aiDuhPFSsI61wuQIl0gBMORXXJaLadIfH91y82If5CvZllXJFWD31OJQmVIDSEP0nPx fjKFUmjcsk0h5BnGmM9yXJBX5uJINCOMXeTlI5zOZtuFoijqNWVVU021oHk1pwyjedSG8i3w qlRNh/yQzoPo5D0fBTPMcbeZ4Y0+RLtokVf3ZN9fnXWSIpEFjpcoBCIQ9R+v0MALWMCTrkbd n1CjfcRdlV7UGUaaiq+W6aQuUZkKBSnbhHfRNwbm/MMUmhWmFD2rhZpL/bnIqxvStDMaLnyk VrfiU9YIDWtNURmZglkui45Z1wUW4g43JCKNTBFab7ZlUS4F+hyttwMpTWCyaQvM9ARCQsts qHBX1d4l1gFNa1hiCzY1KMqlVETM1IixpQl21EV03y/QeRuzxbzHaalqjZG102qzWUPOpN8o 1zB3+L7D/Cju3OH9BHf0EXfuOMbW2FaDKCiypwwy3ZfD5KrvF9M3sI+uBQmh651A1PwesQZ2 r7SomxW1ufqRhoNJxl5skw+Let7YHeQXzLlNGdZ1r/mSJTCqM6KBLkkFNipZpWqz3FmPLIzu FfjltG1ityv0ZnYPdJDRvjLbxLbV0At7WJq9IGIeb5MSDTmChCzx8CzUx6P7TXpT1etCZnNZ kj2HnSk8z2NBEBnw+GeQ7eEh2betpHd0sphJhdmThvA4MNP9B4b8ePXq2OU8+QTwUomsIrNM mA2jP+UG1rXKGtPeze29ApxsXHlWZdR05COO7L2uWnOQavAG+0XRjGz48VS7UYwX3CRiCW8D fnn8Drg/QEWP+yzw9zBtGJBgzw2Z7+7hoWRAAg9hiUfs5IClSarnuDQw3qUgO0zByeUZwjMe +XF01KXahguh8C6E/Smyn87g8x/PFg/pAcSNfMY7ey60Xv52dLRer5mapWO8qelasVrNj6gV HOG1oTrFAYvdvT1/Z61QmGccecz8YeST+V8LleHx9wStf5qR/6lTX1IzBZc5B131FR6YJBbH zegr+g2QL8AgQnC9GI8j904itgMUwmciFsZ7qPYDj9AeNlymuu4eo9zWbdxzaPETbns+oHQ6 v2ABhd63+mWgGlu/9Pb8ul+igAfol3M8veIt9AKtQn2zkBsbzvEHPQ29ZTARN3m5UgKNdD65 fAsf5PXTTpnk80pouo//e/5h8t+wRokP0k6M9e2wJAl33iHmQ9RyYnx67YM+tA5tQe2lPQS5 XoQrnvALPaLbw1yTBCzygUcJ4zz8RtsMFMJ3OfPDvT23tgkcGhkHCfNNuDtrSI3PYawX+umX Jd4aGzhf4YMpj2zSIoTD18d3Yi4h+rRji06Fdcf56g8r4kQXzwK4trQCN7j/WVgTnP8/d6SM cA0KZW5kc3RyZWFtDWVuZG9iag0xMzAgMCBvYmoNPDwvUjcgNyAwIFI+Pg1lbmRvYmoNMTMx IDAgb2JqDTw8L1I5IDkgMCBSPj4NZW5kb2JqDTEzMyAwIG9iag08PC9GaWx0ZXIvRmxhdGVE ZWNvZGUvTGVuZ3RoIDkyND4+c3RyZWFtDQp4nLVW227bOBB911cM+tItYNOirlRQFHE33q2N btMmKgo0yIMuY1uNLi5FJ/W+tV++Q8nxyk5aJBEq2ZAtDs/MnDkc8iuYjIOp7+0zKYzRmQ+L 2uCgb7kwXNcDx6SvcAT4biBAojE3tHUz/tXgDQJsH0kBr0NCCSBgAYRzo0Xm4NPHtxm3ICyM P+BF+MWYhMYHo532WCSPM8tpkKalQlmiGp7IaK5g7xrHscTrLFKYDsNM5bg/fIIJFjFKsEzu 6oBsl3k2pRi+pQgBLs7++tN3uXcJMKtKrAfwD4OoTGHG4E2WpxhL+jeAZ7Pz03fwCWOYlInc rFRWlfB99mny49ngxXODcyaEyW9ROxcN7jh4HJvcdRj3iAqb+S2jFCvoYHsQSzQwT3RBB3By OqV5jPuO8EdbPoiHaNOQNtDehtw29bzhLtH0MNGXe1E9MlVPy9On2ERb8aVSq6PR6Obmhsl5 MsQ0U5VklVyMsnJejehdTx5s4TJhdV2+Yk2iNnf0wNAigjzTuk10qxPR1UlXFeN8UclMLYta q2JMqoAefNgBJ+/g+YKZolt60SNlxw6YJbqgbWltT+j3vyjtPQIRBwL5+QJ42WMFNLLwaB3Y 1sNl0YejrSw6Lh8ki2BfFq9llOa4GVATGTTN5B2D8+gqK9Yy6oomrK6w/DV7JKawEdOTSdyu eI8L5vlBV0xBnz7ikJj2QO/tI8GdPkLqs35vG/FMj/lB8HDB9OHhVjAdn61inpgCbXyusJlp t1jj1QrLNPsG4x4x6t7t7MEyWtNVsi6wVLTL1cTJpqmOG5DhHY1fgKogRjoVFNU1phBvQC0R tIpaQmlwXkmE1TrOsyRq9saoJuU3NpeXGnsH2kp8aDokaf2rAvi4SvX+TQ7mKLFMsNYeZ6fn kxHJX9uN12pZyfo5jNNUYl1jvZ09q5bl7XqD7204P+5uyO+zcgHTlPLN1IaGD6KZFFGWH8E1 +l9UfNw+WFIVd4E+nk2P+u3qTTEcTnrh4lCjaikxSod1NEftftTvBGULzky/daK7uGTDablg 1HZkrbCEt1Waov6Zqnua0AmuVZ1QnUPM8aoqYPz3T4lTLeJx/j8io/Ma2R8ct95EZQ2fqSXG mKunlmn57xbgeEX22db8t9bL8ixm+Xv1WlIqt4Gwm0qmKy3MJopeVeM82Eljt5GggihnnTY5 +bbKyB/M1iUC9we6xXpweF28jxYI4nIX0QfjP22RyyoNCmVuZHN0cmVhbQ1lbmRvYmoNMTQ1 IDAgb2JqDTw8L1I3IDcgMCBSPj4NZW5kb2JqDTE0NiAwIG9iag08PC9SOSA5IDAgUj4+DWVu ZG9iag0xNDcgMCBvYmoNPDwvRGlmZmVyZW5jZXNbMTI5L3BhcmVubGVmdC9wYXJlbnJpZ2h0 XS9UeXBlL0VuY29kaW5nPj4NZW5kb2JqDTE0OCAwIG9iag08PC9MZW5ndGggMzc0MC9TdWJ0 eXBlL1hNTC9UeXBlL01ldGFkYXRhPj5zdHJlYW0NCjw/eHBhY2tldCBiZWdpbj0i77u/IiBp ZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+Cjx4OnhtcG1ldGEgeG1sbnM6eD0iYWRv YmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDUuNC1jMDA1IDc4LjE0NzMy NiwgMjAxMi8wOC8yMy0xMzowMzowMyAgICAgICAgIj4KICAgPHJkZjpSREYgeG1sbnM6cmRm PSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAg PHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6cGRmPSJo dHRwOi8vbnMuYWRvYmUuY29tL3BkZi8xLjMvIgogICAgICAgICAgICB4bWxuczp4bXA9Imh0 dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iCiAgICAgICAgICAgIHhtbG5zOnhtcE1NPSJo dHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIgogICAgICAgICAgICB4bWxuczpkYz0i aHR0cDovL3B1cmwub3JnL2RjL2VsZW1lbnRzLzEuMS8iPgogICAgICAgICA8cGRmOlByb2R1 Y2VyPkdQTCBHaG9zdHNjcmlwdCA5LjA2PC9wZGY6UHJvZHVjZXI+CiAgICAgICAgIDxwZGY6 S2V5d29yZHMvPgogICAgICAgICA8eG1wOk1vZGlmeURhdGU+MjAxNi0wMS0wNlQxMjoyNDo0 MCswMTowMDwveG1wOk1vZGlmeURhdGU+CiAgICAgICAgIDx4bXA6Q3JlYXRlRGF0ZT4yMDE1 LTEyLTE2VDA5OjM3OjI2LTA1OjAwPC94bXA6Q3JlYXRlRGF0ZT4KICAgICAgICAgPHhtcDpD cmVhdG9yVG9vbD5odG1sMnBzIHZlcnNpb24gMS4wIGJldGE3PC94bXA6Q3JlYXRvclRvb2w+ CiAgICAgICAgIDx4bXA6TWV0YWRhdGFEYXRlPjIwMTYtMDEtMDZUMTI6MjQ6NDArMDE6MDA8 L3htcDpNZXRhZGF0YURhdGU+CiAgICAgICAgIDx4bXBNTTpEb2N1bWVudElEPnV1aWQ6MTM0 ZWEyNmUtZGMxZi0xMWYwLTAwMDAtNGY5ODhhMGQ2ZDBmPC94bXBNTTpEb2N1bWVudElEPgog ICAgICAgICA8eG1wTU06SW5zdGFuY2VJRD51dWlkOjQzNGQzNGQ4LThiMjAtNDM4Mi1iMDll LTliYTc0ZGE2NzNhNjwveG1wTU06SW5zdGFuY2VJRD4KICAgICAgICAgPGRjOmZvcm1hdD5h cHBsaWNhdGlvbi9wZGY8L2RjOmZvcm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAg ICAgICA8cmRmOkFsdD4KICAgICAgICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZh dWx0Ij5kcmFmdC1icmFkbGV5LW9hdXRoLWp3dC1lbmNvZGVkLXN0YXRlLTA1IC0gRW5jb2Rp bmcgY2xhaW1zIGluIHRoZSBPQXV0aCAyIHN0YXRlIHBhcmFtZXRlciB1c2luZyBhIEpXVDwv cmRmOmxpPgogICAgICAgICAgICA8L3JkZjpBbHQ+CiAgICAgICAgIDwvZGM6dGl0bGU+CiAg ICAgICAgIDxkYzpjcmVhdG9yPgogICAgICAgICAgICA8cmRmOlNlcT4KICAgICAgICAgICAg ICAgPHJkZjpsaS8+CiAgICAgICAgICAgIDwvcmRmOlNlcT4KICAgICAgICAgPC9kYzpjcmVh dG9yPgogICAgICAgICA8ZGM6ZGVzY3JpcHRpb24+CiAgICAgICAgICAgIDxyZGY6QWx0Pgog ICAgICAgICAgICAgICA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiLz4KICAgICAgICAg ICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1yZXBhaXIiLz4KICAgICAgICAgICAgPC9yZGY6 QWx0PgogICAgICAgICA8L2RjOmRlc2NyaXB0aW9uPgogICAgICA8L3JkZjpEZXNjcmlwdGlv bj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSJ3Ij8+DQplbmRzdHJl YW0NZW5kb2JqDTE1NiAwIG9iag08PC9CQm94WzAuMCAwLjAgMTEuNTAwMyAxMS4wNjU2XS9G b3JtVHlwZSAxL0xlbmd0aCAyMC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jl c291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUv RXh0R1N0YXRlPj4+Pi9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9NV0ZPRm9ybSAxNTcgMCBS Pj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9SMCBncwovTVdGT0Zv cm0gRG8KDQplbmRzdHJlYW0NZW5kb2JqDTE1NyAwIG9iag08PC9CQm94WzAuMCAwLjAgMTEu NTAwMyAxMS4wNjU2XS9Gb3JtVHlwZSAxL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9MZW5n dGggOS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERl0vWE9iamVjdDw8L0Zvcm0gMTU4IDAgUj4+Pj4vU3VidHlwZS9Gb3JtL1R5cGUv WE9iamVjdD4+c3RyZWFtDQovRm9ybSBEbwoNCmVuZHN0cmVhbQ1lbmRvYmoNMTU4IDAgb2Jq DTw8L0JCb3hbMzk0LjkxNiAyNzEuMzY3IDQwNi40MTYgMjgyLjQzMl0vRmlsdGVyL0ZsYXRl RGVjb2RlL0Zvcm1UeXBlIDEvTGVuZ3RoIDEwMS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIC0z OTQuOTE2IC0yNzEuMzY3XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9G b3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiUzOMQ7DQAhE0Z5TzAkQ7OJZcx5LdmM3aXL9 UFgiHXrSH+FwGD6XmHKzxFdmLmUyMJbXMfAUbTrCWRTqwYU/yQo90dk+1I3EIWFTOTnb7jKq pXfY8G539T5wyCk/AQYA74sg4g0KZW5kc3RyZWFtDWVuZG9iag0xNjMgMCBvYmoNPDwvQkJv eFswLjAgMC4wIDM1LjI2IDExLjA2NTZdL0Zvcm1UeXBlIDEvTGVuZ3RoIDIwL01hdHJpeFsx LjAgMC4wIDAuMCAxLjAgMC4wIDAuMF0vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9B SVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+L1Byb2NTZXRbL1BERl0v WE9iamVjdDw8L01XRk9Gb3JtIDE2NCAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmpl Y3Q+PnN0cmVhbQ0KL1IwIGdzCi9NV0ZPRm9ybSBEbwoNCmVuZHN0cmVhbQ1lbmRvYmoNMTY0 IDAgb2JqDTw8L0JCb3hbMC4wIDAuMCAzNS4yNiAxMS4wNjU2XS9Gb3JtVHlwZSAxL0dyb3Vw PDwvUy9UcmFuc3BhcmVuY3k+Pi9MZW5ndGggOS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAu MCAwLjBdL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERl0vWE9iamVjdDw8L0Zvcm0gMTY1IDAg Uj4+Pj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQovRm9ybSBEbwoNCmVu ZHN0cmVhbQ1lbmRvYmoNMTY1IDAgb2JqDTw8L0JCb3hbMzk0LjkxNSAzNDIuNjQ3IDQzMC4x NzUgMzUzLjcxM10vRmlsdGVyL0ZsYXRlRGVjb2RlL0Zvcm1UeXBlIDEvTGVuZ3RoIDEwMC9N YXRyaXhbMS4wIDAuMCAwLjAgMS4wIC0zOTQuOTE1IC0zNDIuNjQ3XS9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiUTO Ow6AQAhF0Z5VvBUQhs8g6zHRRhsbt+80hvaE+8LAgOA5SXiGFF6ySp4VA+bKlZq4lwWriy0L dk1HSwiX6UR3YWxbGnZap2zl2XYtK968vMuWf727/4edDvoEGAB3kCHSDQplbmRzdHJlYW0N ZW5kb2JqDTE2NiAwIG9iag08PC9CQm94Wzg1LjcxNDEgMzQyLjMyMiAxMDMuODA1IDM1NC4w MzhdL0ZpbHRlci9GbGF0ZURlY29kZS9Gb3JtVHlwZSAxL0xlbmd0aCA1OC9NYXRyaXhbMS4w IDAuMCAwLjAgMS4wIC04NS43MTQxIC0zNDIuMzIyXS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REZdPj4vU3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiTJUMADCIHcuAz0z UwNLhXIuCws9C0NLcwVjE3M9E2MzQ4VcLkMDoKylpRlCLIcrmAsgwABV6wt6DQplbmRzdHJl YW0NZW5kb2JqDTE4OCAwIG9iag08PC9EQSgvSGVsdiAwIFRmIDAgZyApL0RSPDwvRW5jb2Rp bmc8PC9QREZEb2NFbmNvZGluZyAyMTAgMCBSPj4vRm9udDw8L0hlbHYgMTg2IDAgUi9aYURi IDE4NyAwIFI+Pj4+L0ZpZWxkc1tdPj4NZW5kb2JqDTE4OSAwIG9iag08PC9BUCAyMDkgMCBS Pj4NZW5kb2JqDTE5MyAwIG9iag08PC9CQm94WzAuMCAwLjAgMTguMCAxOC4wXS9GaWx0ZXIv RmxhdGVEZWNvZGUvTGVuZ3RoIDI5NC9SZXNvdXJjZXM8PC9FeHRHU3RhdGU8PC9HUzA8PC9B SVMgZmFsc2UvQk0vTm9ybWFsL0NBIDAuNi9UeXBlL0V4dEdTdGF0ZS9jYSAwLjY+Pj4+Pj4v U3VidHlwZS9Gb3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIieSSTU7EMAyFr/IuUGOn+T3B SEgsEEvEhiAG0MwCWHB9XtIWGgEnQJFqf67zEr/2FdbX2xGKZyYf8LhifCFf4vZO8YCLw43i +M6qchkKgmjRjHpGkuRhTqJFnDHt8YQpi/tmUtLUyLL/IpPoC+rG0yx5tmVvZy9zDJsSKZW8 HrNCxZ5OGDoHkeGEiuECJwy3Gy6+H6riCY+4pg+Hbpxu1qlE/dW9fdthbQ3lr9afDrcKnVUx 75gycZkSyrfMvXWw0Czk3UvBZFIiQ5AQQis6bqQFsQUTPmtDdb4J5OiaJYWz8QizDsETSh+X MjFkGO2kWJSUHGZxzm3gaWf/gAsmCVqaCD0rEvnUNVbsivvmUWchjhLTskH7qv/wV7vHpwAD ACFstbwNCmVuZHN0cmVhbQ1lbmRvYmoNMjA5IDAgb2JqDTw8L05hbWVzWyj+/wB+AGkAYwBv AG4AKwBDAG8AbQBtAGUAbgB0ACsAMgA1ADUAOgAyADUANQA6ADAALQBEAEUAVQAtADApMTkz IDAgUl0+Pg1lbmRvYmoNMjEwIDAgb2JqDTw8L0RpZmZlcmVuY2VzWzI0L2JyZXZlL2Nhcm9u L2NpcmN1bWZsZXgvZG90YWNjZW50L2h1bmdhcnVtbGF1dC9vZ29uZWsvcmluZy90aWxkZSAz OS9xdW90ZXNpbmdsZSA5Ni9ncmF2ZSAxMjgvYnVsbGV0L2RhZ2dlci9kYWdnZXJkYmwvZWxs aXBzaXMvZW1kYXNoL2VuZGFzaC9mbG9yaW4vZnJhY3Rpb24vZ3VpbHNpbmdsbGVmdC9ndWls c2luZ2xyaWdodC9taW51cy9wZXJ0aG91c2FuZC9xdW90ZWRibGJhc2UvcXVvdGVkYmxsZWZ0 L3F1b3RlZGJscmlnaHQvcXVvdGVsZWZ0L3F1b3RlcmlnaHQvcXVvdGVzaW5nbGJhc2UvdHJh ZGVtYXJrL2ZpL2ZsL0xzbGFzaC9PRS9TY2Fyb24vWWRpZXJlc2lzL1pjYXJvbi9kb3RsZXNz aS9sc2xhc2gvb2Uvc2Nhcm9uL3pjYXJvbiAxNjAvRXVybyAxNjQvY3VycmVuY3kgMTY2L2Jy b2tlbmJhciAxNjgvZGllcmVzaXMvY29weXJpZ2h0L29yZGZlbWluaW5lIDE3Mi9sb2dpY2Fs bm90Ly5ub3RkZWYvcmVnaXN0ZXJlZC9tYWNyb24vZGVncmVlL3BsdXNtaW51cy90d29zdXBl cmlvci90aHJlZXN1cGVyaW9yL2FjdXRlL211IDE4My9wZXJpb2RjZW50ZXJlZC9jZWRpbGxh L29uZXN1cGVyaW9yL29yZG1hc2N1bGluZSAxODgvb25lcXVhcnRlci9vbmVoYWxmL3RocmVl cXVhcnRlcnMgMTkyL0FncmF2ZS9BYWN1dGUvQWNpcmN1bWZsZXgvQXRpbGRlL0FkaWVyZXNp cy9BcmluZy9BRS9DY2VkaWxsYS9FZ3JhdmUvRWFjdXRlL0VjaXJjdW1mbGV4L0VkaWVyZXNp cy9JZ3JhdmUvSWFjdXRlL0ljaXJjdW1mbGV4L0lkaWVyZXNpcy9FdGgvTnRpbGRlL09ncmF2 ZS9PYWN1dGUvT2NpcmN1bWZsZXgvT3RpbGRlL09kaWVyZXNpcy9tdWx0aXBseS9Pc2xhc2gv VWdyYXZlL1VhY3V0ZS9VY2lyY3VtZmxleC9VZGllcmVzaXMvWWFjdXRlL1Rob3JuL2dlcm1h bmRibHMvYWdyYXZlL2FhY3V0ZS9hY2lyY3VtZmxleC9hdGlsZGUvYWRpZXJlc2lzL2FyaW5n L2FlL2NjZWRpbGxhL2VncmF2ZS9lYWN1dGUvZWNpcmN1bWZsZXgvZWRpZXJlc2lzL2lncmF2 ZS9pYWN1dGUvaWNpcmN1bWZsZXgvaWRpZXJlc2lzL2V0aC9udGlsZGUvb2dyYXZlL29hY3V0 ZS9vY2lyY3VtZmxleC9vdGlsZGUvb2RpZXJlc2lzL2RpdmlkZS9vc2xhc2gvdWdyYXZlL3Vh Y3V0ZS91Y2lyY3VtZmxleC91ZGllcmVzaXMveWFjdXRlL3Rob3JuL3lkaWVyZXNpc10vVHlw ZS9FbmNvZGluZz4+DWVuZG9iag0yMjggMCBvYmoNPDwvQkJveFs0MjQuMjg5IDM4OS44NDIg NDM2LjQ0IDQwMS41NThdL0Zvcm1UeXBlIDEvTGVuZ3RoIDYwL01hdHJpeFsxLjAgMC4wIDAu MCAxLjAgLTQyNC4yODkgLTM4OS44NDJdL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERl0+Pi9T dWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCjEgMCAwIFJHCjAuNjUwOSB3CjQy Ny4zOTQ3IDM5MS45ODA1IG0KNDMzLjMzNDYgMzkxLjk4MDUgbApTCg0KZW5kc3RyZWFtDWVu ZG9iag0yNDUgMCBvYmoNPDwvQkJveFstMC41ODkzNTUgLTAuNTg5MzU1IDguMDkwMDkgNi40 ODI3OV0vRmlsdGVyL0ZsYXRlRGVjb2RlL0Zvcm1UeXBlIDEvTGVuZ3RoIDgyL01hdHJpeFsx LjAgMC4wIDAuMCAxLjAgMC41ODkzNTUgMC41ODkzNTVdL1Jlc291cmNlczw8L1Byb2NTZXRb L1BERl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJMlAwUDBUCHLn MtAztbA0VijnMgCLFKWDGblcxnrmpgYmQCaUYaRnaWJmDuOZ6gE1mSgkc2GVNVAw1zM1MDAH MpK5MrjSuIK5AAIMALWvFVYNCmVuZHN0cmVhbQ1lbmRvYmoNMjYwIDAgb2JqDTw8L0JCb3hb MC4wIDAuMCAxMjQuMzU5IDExLjA2NTZdL0Zvcm1UeXBlIDEvTGVuZ3RoIDIwL01hdHJpeFsx LjAgMC4wIDAuMCAxLjAgMC4wIDAuMF0vUmVzb3VyY2VzPDwvRXh0R1N0YXRlPDwvUjA8PC9B SVMgZmFsc2UvQk0vTXVsdGlwbHkvVHlwZS9FeHRHU3RhdGU+Pj4+L1Byb2NTZXRbL1BERl0v WE9iamVjdDw8L01XRk9Gb3JtIDI2MSAwIFI+Pj4+L1N1YnR5cGUvRm9ybS9UeXBlL1hPYmpl Y3Q+PnN0cmVhbQ0KL1IwIGdzCi9NV0ZPRm9ybSBEbwoNCmVuZHN0cmVhbQ1lbmRvYmoNMjYx IDAgb2JqDTw8L0JCb3hbMC4wIDAuMCAxMjQuMzU5IDExLjA2NTZdL0Zvcm1UeXBlIDEvR3Jv dXA8PC9TL1RyYW5zcGFyZW5jeT4+L0xlbmd0aCA5L01hdHJpeFsxLjAgMC4wIDAuMCAxLjAg MC4wIDAuMF0vUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGXS9YT2JqZWN0PDwvRm9ybSAyNjIg MCBSPj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9Gb3JtIERvCg0K ZW5kc3RyZWFtDWVuZG9iag0yNjIgMCBvYmoNPDwvQkJveFsyMTAuNzc4IDMzMC43NjcgMzM1 LjEzNiAzNDEuODMzXS9GaWx0ZXIvRmxhdGVEZWNvZGUvRm9ybVR5cGUgMS9MZW5ndGggMTAx L01hdHJpeFsxLjAgMC4wIDAuMCAxLjAgLTIxMC43NzggLTMzMC43NjddL1Jlc291cmNlczw8 L1Byb2NTZXRbL1BERl0+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJ TM47DoBACEXRnlWwAsKDYT7rMdFGGxu3L4Vmpj1wCWCw8n2QSg0d/JDBJaINdofosMpXGgTq SMthac6LDNGw4NkVSGjubORu4lEx7Uwr0qF9lot812f3/7DRTq8AAwBJsCFCDQplbmRzdHJl YW0NZW5kb2JqDTI2NyAwIG9iag08PC9CQm94WzAuMCAwLjAgNDEuMTk5OSAxMS4wNjU2XS9G b3JtVHlwZSAxL0xlbmd0aCAyMC9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jl c291cmNlczw8L0V4dEdTdGF0ZTw8L1IwPDwvQUlTIGZhbHNlL0JNL011bHRpcGx5L1R5cGUv RXh0R1N0YXRlPj4+Pi9Qcm9jU2V0Wy9QREZdL1hPYmplY3Q8PC9NV0ZPRm9ybSAyNjggMCBS Pj4+Pi9TdWJ0eXBlL0Zvcm0vVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCi9SMCBncwovTVdGT0Zv cm0gRG8KDQplbmRzdHJlYW0NZW5kb2JqDTI2OCAwIG9iag08PC9CQm94WzAuMCAwLjAgNDEu MTk5OSAxMS4wNjU2XS9Gb3JtVHlwZSAxL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3k+Pi9MZW5n dGggOS9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIDAuMCAwLjBdL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERl0vWE9iamVjdDw8L0Zvcm0gMjY5IDAgUj4+Pj4vU3VidHlwZS9Gb3JtL1R5cGUv WE9iamVjdD4+c3RyZWFtDQovRm9ybSBEbwoNCmVuZHN0cmVhbQ1lbmRvYmoNMjY5IDAgb2Jq DTw8L0JCb3hbMjk5Ljg3NiAxODguMjA2IDM0MS4wNzYgMTk5LjI3MV0vRmlsdGVyL0ZsYXRl RGVjb2RlL0Zvcm1UeXBlIDEvTGVuZ3RoIDEwMy9NYXRyaXhbMS4wIDAuMCAwLjAgMS4wIC0y OTkuODc2IC0xODguMjA2XS9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREZdPj4vU3VidHlwZS9G b3JtL1R5cGUvWE9iamVjdD4+c3RyZWFtDQpIiUzOOw7DUAhE0Z5VzArQ8HhgWI8lu3GaNNl+ 3PjToSPdEQYD8d2FmsHGT5zjPNNhVRpujs9p1EFLWFO70vCS1Nk28HRd2jOxinvp6KibDvFJ XYLx6h65tu/s+mCVTf4CDAAacCEuDQplbmRzdHJlYW0NZW5kb2JqDTI3NyAwIG9iag08PC9E ZWNvZGVQYXJtczw8L0NvbHVtbnMgNC9QcmVkaWN0b3IgMTI+Pi9GaWx0ZXIvRmxhdGVEZWNv ZGUvSURbPDcwRjU3RTRFQzc1MDM5OTIzMjQwNTc1MzVCNzkyMUU0PjxBMUYxRTZGNTNGQkMy QTQ2OTkyMTIyRkJDREI2NjIzNj5dL0luZm8gMiAwIFIvTGVuZ3RoIDQ3NS9Sb290IDEgMCBS L1NpemUgMjc4L1R5cGUvWFJlZi9XWzEgMiAxXT4+c3RyZWFtDQpo3syUSyiEURTH7z0zGI+i sDEhO1E2lBhhoSk2rKZMKI88S9mxtEDZKAl5Rk2zsyB5LVgYC4+FNxvkWZqlxDBznDNz51Ee DbMxi3/nf+85v3vON/f7QNAPpF4rQIgWiu5nJEVCAur7XIC3bbSW9kBylcEpLhYJnpSvBNPE K0UpVHF5pSFb6AS8WBUAMkr3fdm/E0w3n6g5znoF2VGS03ae4z0zeEqWaU9RDvq1ZIfeAffH mHKUExQgp8umALtNYWSX3gB3ehiwVRDagAbHMkWpRLbdhZPNdwBuxjJ5pfSHsqLjeRCSyzai IgCLE18B141cZi0PrSFjkkU1tGrTkTW/AK7EMHmi6peoMsO4B6WkjP68xQWOYt0XOFBAdgpV VjmHNFsyWWmnNiyljZ/I1U8jtKvnlEeWAiJPr/Gu9RNZCBOC+wX7kzB0mfszuy0C1pZw1E1H Tl3zbpg6SNbl0e6UToRwWqDIBjvPVk8HjXfwQfFfzOaXdN+U55ys4Z5zwdOzC7fRu5btnaP5 jsgjwbULMiHai7I/+9YiPWt+wZYbusDDkcFC1SMmKPrW1HcN2+KcAfcABw/9ZVqV0m56C0gR A5MkMMuWJXqQbSvbXRJNBUmNUXwIMACqw5xSDQplbmRzdHJlYW0NZW5kb2JqDXN0YXJ0eHJl Zg0KMjkzNjINCiUlRU9GDQo= --------------030507040703080605020605-- From nobody Thu Jan 7 15:45:54 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D051A879E for ; Thu, 7 Jan 2016 15:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93KmChYOLnmR for ; Thu, 7 Jan 2016 15:45:49 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::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 D600C1A8792 for ; Thu, 7 Jan 2016 15:45:47 -0800 (PST) Received: by mail-ig0-x233.google.com with SMTP id mw1so64346035igb.1 for ; Thu, 07 Jan 2016 15:45:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SPm+vQU4+I0zMbyw7/iAQ4lY319adkKhL/X4qSYvhTw=; b=EL6XFzHPZdsNwDemcSMaNznzAy+/R43fTRrXgskQZR7AVSqIsZ20/AsHm1t+XqBXYn CBI++fG4I/y+KZirPOSKuk12EmxgMgyhUXlYvNaFVF3/ftaxlJEbBp581TWvuE9QI1xg ruOqQ4/gCakNvzvoicdEBge/CIEoXWz85shJI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SPm+vQU4+I0zMbyw7/iAQ4lY319adkKhL/X4qSYvhTw=; b=CF4hheG0KxNjxqI+ufwSeWfDiAhvKQIzqH4LiZBoBdyNgLjbEBIGEzeaPX7OGxvEjg z9VHjNenzcUy8ZpeHqmWPDAV438l0Ow1cjUAS4NMblciLvqcq5gqihvFjIDp8Azk2yHu 3vLRSeDuTKAFGmAtnraKRgDvIeovNZGjt8ZmSPtDB9a5yJ+pGxova6ZC3nVmf7edmFO9 YjL675BbZlKiMW9fVEn0L6QZu5hgPQdYIG0bLvUWoRqN/pNrOLuAmh5v/3pJuEOAmyhI 4AgIR2t9UvFaXmz8kcegzk3lf/qHNuP6HQzFlv8jKTUWp2L8BsLbItIEyimUP5qoGZnx pWzQ== X-Gm-Message-State: ALoCoQkEgCk/UAB02LAwOgHhvQ+uvJbqdfM/lCh5ACWYGzLnTn8BBqtsmbdCPcEJ5AGlBMjNDrQ1TjmN+SZNkVT8Nc+Y+bYcmEf/RhX6HxgmhbVsdXRXCFQ= X-Received: by 10.50.115.106 with SMTP id jn10mr2890749igb.77.1452210347267; Thu, 07 Jan 2016 15:45:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.23.133 with HTTP; Thu, 7 Jan 2016 15:45:17 -0800 (PST) In-Reply-To: <568CEA28.6070204@connect2id.com> References: <568CEA28.6070204@connect2id.com> From: Brian Campbell Date: Thu, 7 Jan 2016 16:45:17 -0700 Message-ID: To: Vladimir Dzhuvinov Content-Type: multipart/alternative; boundary=089e01160584e37c300528c7117e Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us -03 announcement redux X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2016 23:45:52 -0000 --089e01160584e37c300528c7117e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the review Vladimir, responses inline below... On Wed, Jan 6, 2016 at 3:19 AM, Vladimir Dzhuvinov wrote: > Hi Brian, > > 1. The introduction is excellent! Previous versions were lacking in this > regard and readers were left guessing or unaware about key aspects of the > spec and how to make use of it. Good work! > Thank you! > > 2.1. Are clients allowed to mix or include both "resource" and "audience" > request parameters at the same time? > I'm inclined to say yes although I know it's not clearly stated one way or the other in the current draft. Conceptually it started with only a single parameter indicating the location of the resource. In some discussions that started to seem overly limiting and so the concepts of specifying either a logical name or a resource location were introduced as well as allowing for multiples. Given that all that is already allowed and that these parameters are simply a way for the client to signal expected usage preferences, I think it makes sense to allow the use of "resource" and "audience" request parameters at the same time. I'm certainly open to discussing on it though. I had hoped that whatever parameter(s) were used here to indicate where the token is anticipated to be used could be extracted and used at the token and authz endpoints for PoP key distribution and even vanilla OAuth. But what's in token exchange may have gotten too flexible for those cases. I'm not sure... > > A.1. Wouldn't the impersonation example be more straightforward if the > returned token is an access token? I see that a "N_A" token is also > demonstrated there, but that could confuse readers if the main point is t= o > show an impersonation example. > I wavered on that very question when doing a round of updates. I think one of the other editors had gone with the "N_A" so, being kind of on the fence myself, I just left it that way. But I'd be just fine with changing that if you and/or others think it'd be more straightforward. > > A.1 + A.2. It is stated that the client is anonymous. But is that really > so if the supplied JWTs are apparently signed by the client and the AS wi= ll > have to verify them? > Shoot, you're right. Good catch. I had a different issuer in there at one point but went back though and changed some of the identifiers in the examples to try and make them more meaningful. But I didn't notice that making issuer say 'client' like that undermines or confuses the statement about the client being anonymous. I'll change the iss or remove the text about being anonymous in those examples. > > > Overall I'm very pleased with this new version! > That's great to hear! Thanks again for your review. > Cheers, > > Vladimir > > > > > On 05/01/16 23:40, Brian Campbell wrote: > > On the off chance that it was missed in the final throes of 2015, I'd lik= e > to re-announce the publication of a new revision of the OAuth 2.0 Token > Exchange draft. > http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03 > > Due to the substantial changes in this draft, I'd encourage (a.k.a. beg) = WG > participants to review the document. As Mike said, this draft reconciles > the differences in approaches taken in the previous working group draft a= nd > draft-campbell-oauth-sts while incorporating working group input and roug= h > consensuses from the in-person discussions in Prague and mailing list > discussions. > > Changes from -02 are summarized in Appendix Dhttp://tools.ietf.org/html/d= raft-ietf-oauth-token-exchange-03#appendix-D > and the more meaningful are copied here: > > o Updated the format of the request to use application/x-www-form- > urlencoded request parameters and the response to use the existing > token endpoint JSON parameters defined in OAuth 2.0. > o Changed the grant type identifier to urn:ietf:params:oauth:grant- > type:token-exchange. > o Removed the Implementation Considerations and the requirement to > support JWTs. > o Changed "on_behalf_of" to "subject_token", > "on_behalf_of_token_type" to "subject_token_type", "act_as" to > "actor_token", and "act_as_token_type" to "actor_token_type". > o Added a "want_composite" request parameter used to indicate the > desire for a composite token rather than trying to infer it from > the presence/absence of token(s) in the request. > o Added an "audience" request parameter used to indicate the logical > names of the target services at which the client intends to use > the requested security token. > o Added a "resource" request parameter used to indicate the URLs of > resources at which the client intends to use the requested > security token. > o Specified that multiple "audience" and "resource" request > parameter values may be used. > o Defined the JWT claim "act" (actor) to express the current actor > or delegation principal. > o Defined the JWT claim "may_act" to express that one party is > authorized to act on behalf of another party. > o Defined the JWT claim "scp" (scopes) to express OAuth 2.0 scope- > token values. > o Added the "N_A" (not applicable) OAuth Access Token Type > definition for use in contexts in which the token exchange syntax > requires a "token_type" value, but in which the token being issued > is not an access token. > o Added examples. > > > And the (known) outstanding issues are listed in Appendix Chttp://tools.i= etf.org/html/draft-ietf-oauth-token-exchange-03#appendix-C > but also copied here: > > o Should there be a way to use short names for some common token > type identifiers? URIs are necessary in the general case for > extensibility and vendor/deployment specific types. But short > names like "access_token" and "jwt" are aesthetically appealing > and slightly more efficient in terms of bytes on the wire and url- > encoding. There seemed to be rough consensus in Prague ('No > objection to use the proposed mechanism for a default prefix' from > https://www.ietf.org/proceedings/93/minutes/minutes-93-oauth) for > supporting a shorthand for commonly used types - i.e. when the > value does not contain a ":" character, the value would be treated > as though "urn:ietf:params:oauth:token-type:" were prepended to > it. So, for example, the value "jwt" for "requested_token_type" > would be semantically equivalent to "urn:ietf:params:oauth:token- > type:jwt" and the value "access_token" would be equivalent to > "urn:ietf:params:oauth:token-type:access_token". However, it was > a fairly brief discussion in Prague and it has since been > suggested that making participants handle both syntaxes will > unnecessarily complicate the supporting code. > > o Provide a way to include supplementary claims or information in > the request that would/could potentially be included in the issued > token. There are real use cases for this but we would need to > work through what it would look like. > > o Understand and define exactly how the presentation of PoP/non- > bearer tokens works. Of course, the specifications defining these > kinds of tokens need to do so first before there is much we can do > in this specification in this regard. > > o It seems there may be cases in which it would be desirable for the > authenticated client to be somehow represented in the issued > token, sometimes in addition to the actor, which can already be > represented using the "act" claim. Perhaps with a "client_id" > claim? > > > > > ---------- Forwarded message ---------- > From: Mike Jones > Date: Mon, Dec 14, 2015 at 1:05 AM > Subject: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us > To: "oauth@ietf.org" > > > I=E2=80=99m happy to report that a substantially revised OAuth 2.0 Token = Exchange > draft has been published that enables a broad range of use cases, while > still remaining as simple as possible. This draft unifies the approaches > taken in the previous working group draft and draft-campbell-oauth-sts, > incorporating working group input from the in-person discussions in Pragu= e > and mailing list discussions. Thanks to all for your interest in and > contributions to OAuth Token Exchange! Brian Campbell deserves special > recognition for doing much of the editing heavy lifting for this draft. > > > > The core functionality remains token type independent. That said, new > claims are also defined to enable representation of delegation actors in > JSON Web Tokens (JWTs). Equivalent claims could be defined for other tok= en > types by other specifications. > > > > See the Document History section for a summary of the changes made. Plea= se > check it out! > > > > The specification is available at: > > =C2=B7 http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-0= 3 > > > > An HTML-formatted version is also available at: > > =C2=B7 http://self-issued.info/docs/draft-ietf-oauth-token-exchange= -03.html > > > > -- Mike > > > > P.S. This note was also posted at http://self-issued.info/?p=3D1509 > and as > @selfissued . > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau= th > > > -- > Vladimir Dzhuvinov :: vladimir@connect2id.com > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e01160584e37c300528c7117e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the review V= ladimir, responses inline below...


On Wed, Jan 6, 2016 at 3:19 AM, Vladimir D= zhuvinov <vladimir@connect2id.com> wrote:
=20 =20 =20
Hi Brian,

1. The introduction is excellent! Previous versions were lacking in this regard and readers were left guessing or unaware about key aspects of the spec and how to make use of it. Good work!

Thank you!<= /span>
=C2=A0

2.1. Are clients allowed to mix or include both "resource" an= d "audience" request parameters at the same time?

I'm inclined to say yes although I know = it's not clearly stated one way or the other in the current draft. Conc= eptually it started with only a single parameter indicating the location of= the resource. In some discussions that started to seem overly limiting and= so the concepts of specifying either a logical name or a resource location= were introduced as well as allowing for multiples. Given that all that is = already allowed and that these parameters are simply a way for the client t= o signal expected usage preferences, I think it makes sense to allow the us= e of "resource" and "audience" request parameters at the same time.

I'm certainly open to di= scussing on it though.

I had hoped that whatever parameter(s) were used here to indicate = where the token is anticipated to be used could be extracted and used at th= e token and authz endpoints for PoP key distribution and even vanilla OAuth= . But what's in token exchange may have gotten too flexible for those c= ases. I'm not sure...

=C2=A0

A.1. Wouldn't the impersonation example be more straightforward if the returned token is an access token? I see that a "N_A" tok= en is also demonstrated there, but that could confuse readers if the main point is to show an impersonation example.
<= span style=3D"color:rgb(0,0,255)">
I wavered on that very question when doing a round of updates. I= think one of the other editors had gone with the "N_A" so, being= kind of on the fence myself, I just left it that way. But I'd be just = fine with changing that if you and/or others think it'd be more straigh= tforward.
=C2=A0

A.1 + A.2. It is stated that the client is anonymous. But is that really so if the supplied JWTs are apparently signed by the client and the AS will have to verify them?

Shoot, you're right. Good ca= tch. I had a different issuer in there at one point but went back though an= d changed some of the identifiers in the examples to try and make them more= meaningful. But I didn't notice that making issuer say 'client'= ; like that undermines or confuses the statement about the client being ano= nymous. I'll change the iss or remove the text about being anonymous in= those examples.=C2=A0
=C2=A0
=C2=A0

Overall I'm very pleased with this new version!

That's great = to hear! Thanks again for your review.
=C2=A0

=

Cheers,

Vladimir




On 05/01/16 23:40, Brian Campbell wrote:
On the off chance that it was missed in the final thro=
es of 2015, I'd like
to re-announce the publication of a new revision of the OAuth 2.0 Token
Exchange draft.

http://tools.ietf.org/html/draft-ietf-oauth-token-exchange=
-03

Due to the substantial changes in this draft, I'd encourage (a.k.a. beg=
) WG
participants to review the document. As Mike said, this draft reconciles
the differences in approaches taken in the previous working group draft and
draft-campbell-oauth-sts while incorporating working group input and rough
consensuses from the in-person discussions in Prague and mailing list
discussions.

Changes from -02 are summarized in Appendix D
http://tools.ietf.org/html/draft-ietf-oauth-tok=
en-exchange-03#appendix-D
and the more meaningful are copied here:

   o  Updated the format of the request to use application/x-www-form-
      urlencoded request parameters and the response to use the existing
      token endpoint JSON parameters defined in OAuth 2.0.
   o  Changed the grant type identifier to urn:ietf:params:oauth:grant-
      type:token-exchange.
   o  Removed the Implementation Considerations and the requirement to
      support JWTs.
   o  Changed "on_behalf_of" to "subject_token",
      "on_behalf_of_token_type" to "subject_token_type"=
, "act_as" to
      "actor_token", and "act_as_token_type" to "a=
ctor_token_type".
   o  Added a "want_composite" request parameter used to indicate=
 the
      desire for a composite token rather than trying to infer it from
      the presence/absence of token(s) in the request.
   o  Added an "audience" request parameter used to indicate the =
logical
      names of the target services at which the client intends to use
      the requested security token.
   o  Added a "resource" request parameter used to indicate the U=
RLs of
      resources at which the client intends to use the requested
      security token.
   o  Specified that multiple "audience" and "resource"=
 request
      parameter values may be used.
   o  Defined the JWT claim "act" (actor) to express the current =
actor
      or delegation principal.
   o  Defined the JWT claim "may_act" to express that one party i=
s
      authorized to act on behalf of another party.
   o  Defined the JWT claim "scp" (scopes) to express OAuth 2.0 s=
cope-
      token values.
   o  Added the "N_A" (not applicable) OAuth Access Token Type
      definition for use in contexts in which the token exchange syntax
      requires a "token_type" value, but in which the token being=
 issued
      is not an access token.
   o  Added examples.


And the (known) outstanding issues are listed in Appendix C
http://tools.ietf.org/html/draft-ietf-oauth-tok=
en-exchange-03#appendix-C
but also copied here:

   o  Should there be a way to use short names for some common token
      type identifiers?  URIs are necessary in the general case for
      extensibility and vendor/deployment specific types.  But short
      names like "access_token" and "jwt" are aesthetic=
ally appealing
      and slightly more efficient in terms of bytes on the wire and url-
      encoding.  There seemed to be rough consensus in Prague ('No
      objection to use the proposed mechanism for a default prefix' fro=
m
      https://www.ietf.org/proceedings/93/minutes/minutes-9=
3-oauth) for
      supporting a shorthand for commonly used types - i.e. when the
      value does not contain a ":" character, the value would be =
treated
      as though "urn:ietf:params:oauth:token-type:" were prepende=
d to
      it.  So, for example, the value "jwt" for "requested_t=
oken_type"
      would be semantically equivalent to "urn:ietf:params:oauth:token=
-
      type:jwt" and the value "access_token" would be equiva=
lent to
      "urn:ietf:params:oauth:token-type:access_token".  However, =
it was
      a fairly brief discussion in Prague and it has since been
      suggested that making participants handle both syntaxes will
      unnecessarily complicate the supporting code.

   o  Provide a way to include supplementary claims or information in
      the request that would/could potentially be included in the issued
      token.  There are real use cases for this but we would need to
      work through what it would look like.

   o  Understand and define exactly how the presentation of PoP/non-
      bearer tokens works.  Of course, the specifications defining these
      kinds of tokens need to do so first before there is much we can do
      in this specification in this regard.

   o  It seems there may be cases in which it would be desirable for the
      authenticated client to be somehow represented in the issued
      token, sometimes in addition to the actor, which can already be
      represented using the "act" claim.  Perhaps with a "cl=
ient_id"
      claim?




---------- Forwarded message ----------
From: Mike Jones <Michael.Jones@microsoft.com>
Date: Mon, Dec 14, 2015 at 1:05 AM
Subject: [OAUTH-WG] OAuth 2.0 Token Exchange: An STS for the REST of Us
To: "oauth@ietf.or=
g" <oauth@i=
etf.org>


I=E2=80=99m happy to report that a substantially revised OAuth 2.0 Token Ex=
change
draft has been published that enables a broad range of use cases, while
still remaining as simple as possible.  This draft unifies the approaches
taken in the previous working group draft and draft-campbell-oauth-sts,
incorporating working group input from the in-person discussions in Prague
and mailing list discussions.  Thanks to all for your interest in and
contributions to OAuth Token Exchange!  Brian Campbell deserves special
recognition for doing much of the editing heavy lifting for this draft.



The core functionality remains token type independent.  That said, new
claims are also defined to enable representation of delegation actors in
JSON Web Tokens (JWTs).  Equivalent claims could be defined for other token
types by other specifications.



See the Document History section for a summary of the changes made.  Please
check it out!



The specification is available at:

=C2=B7       http://tools.ietf.org/html/draft-ietf-oauth-t=
oken-exchange-03



An HTML-formatted version is also available at:

=C2=B7       http://self-issued.info/docs/draft-iet=
f-oauth-token-exchange-03.html



                                                          -- Mike



P.S.  This note was also posted at http://self-issued.info/?p=3D1509
 a=
nd as
@selfissued &l=
t;https://twitter.com/selfissued>.

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




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


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

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


--089e01160584e37c300528c7117e-- From nobody Sun Jan 10 10:59:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF9D1ACEAC for ; Sun, 10 Jan 2016 10:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvTGo1Xkm9aO for ; Sun, 10 Jan 2016 10:59:38 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294141ACEA8 for ; Sun, 10 Jan 2016 10:59:37 -0800 (PST) Received: from [192.168.10.141] ([80.92.121.67]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MMkDH-1aGyhE3bdn-008Zt1 for ; Sun, 10 Jan 2016 19:59:36 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <5692AA1A.5000909@gmx.net> Date: Sun, 10 Jan 2016 19:59:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DOr4Pqkebcd12QSCcGuXeFrRE6mllEnqL" X-Provags-ID: V03:K0:umjhvnIQKlSaun6ULGkhmZC3bcR2d/YSrp/r/8td0jNhObKFNc9 437NIznmZIK5MkUUgNpFsocI9bFpXEpsk2LZ+ro76WLkAn60Jfvm3WY+8rsao/EPFxAXUR4 DYUVG75iq/4b4kry513XC4S0eOr7O3feR6zM/0QIN0vUdup8SqRPWgEapX/a84m8aGPL3k6 dRVPcil8SzioeuQJjCwlw== X-UI-Out-Filterresults: notjunk:1;V01:K0:OxGDaDL65z4=:J4g7AAdj7n4PPXWR/tvBSm zQlBZueTO8aWtgBVGgosG4HDQIad61nakLugQWZ9WybDfnWt7y1rgN4qW/957zv+yavQeDZPS NYnioMPh3frJ12MD3z7VdcTbW9p3yK6p8m0FL8Uyk/K4W5c5ZtrxlwQSeQQrgm5lDOWeiGPuS LhmEFsRkoXCftfxnH4qmeLr0T1YJWuWMe5k7TuwdkAMRF7bV+CBxCj79fWaX34qzhjH2OE1nT 85woPrrisAXRQLlkzgaJ9ztztc1pI0lPCiXmfoIl7ENN6rk2zJ1X6J1/+rnug7/biuaOXJE7p dP9f72Wi3vp7hJv6dTHVaSb9PKSwIhDt96ftEMOnHHAytPx+XI1WOdYnrEood0FPm0aMnFceE Ax7uVTdXkMwkEXn5MsYIsQ3D0Zj2eZ0Sm4ghFLVS4ci8GDkvC3IJg+InmpX+5r0e1+luWaF9V Wphbhr7aePwVidejlEVXOXhPGs2HOaHf55FoMBOnS4lgHfSVNY8+jK83W3NbYcGYtUOk+X5nK SqwWc3dqXSOXGrmMzfRDl6Z7tB1u3S8oXsLApHM4uytaTJt5gXV67kmh6X9iYwtcfo0Vhl4MN OhokUf2VZjHSZ66vu5MMwRSiYKCggIVyWk5NCUR1cUdEVbw5YZrEvBlgnAf+mJ3SkSTeTBagC 56g65ZoFOF57npC8IrnYTeOQWsbRrnAHsQYuNUP636Tn1fZqbp5kiTwA+el5owKiRK9Kr7k6l dHIiI1xZ+zuL9gpxexCx/Cx0xCPXThHvVtbJDXCIjztIebKF3t9JFY33M/k= Archived-At: Subject: [OAUTH-WG] OAuth Security Advisory: Authorization Server Mix-Up X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2016 18:59:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DOr4Pqkebcd12QSCcGuXeFrRE6mllEnqL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In November 2015 the OAuth WG chairs had been informed about new attacks against OAuth clients using multiple authorization servers. Such a setup may exist in OAuth as well as in OpenID Connect. To discuss the details of the (not yet published) attacks a small group met at Deutsche Telekom in Darmstadt/Germany in December and brainstormed about mitigation techniques. On a high-level the attack can be described as an OAuth / OpenID Connect client that gets confused about which authorization server (AS) issued tokens, which leads to a failure in authentication and authorization. Details about the attack can be found at http://arxiv.org/abs/1601.01229 and http://arxiv.org/pdf/1508.04324.pdf. As a quick and immediate self-mitigation, which requires manual configuration, a client that has client ids issued by more than one AS MUST register a "redirect_uri" value with each AS containing a distinct AS specific component. Client implementations must verify that the AS specific component received in the authorization response correlates with state information stored internally at the client for that request. If the authorization response does not contain the anticipated AS-specific component then it MUST be rejected. A strawman proposal for a protocol-based mitigation technique that relies on a new issuer parameter within the authorization response will be submitted to the OAuth working group in the next few days. We encourage the OAuth WG members to carefully study the attack and the proposed mitigation mechanism. We believe that the working group should standardize a solution with high priority and therefore ask for feedback by January 31st 2016. The solution technique will be developed within the IETF OAuth working group using our regular working group process. The chairs would like to thank Guido Schmitz (University of Trier), Daniel Fett (University of Trier), Christian Mainka (Ruhr-University Bochum) and Vladislav Mladenov (Ruhr-University Bochum) for contacting us and for providing us a possibility to investigate the attack and to develop mitigation techniques. We would also like to thank Torsten Lodderstedt (from Deutsche Telekom) for hosting our meeting. Receiving security review from the research community helps to improve the quality of our protocols. We anticipate a much closer working relationship with these research groups to tackle potential security issues before the publication of our specifications as finished RFCs. To make it easier to contact our working group for security related issues we have created a dedicated mailing list . For implementation specific bugs we will attempt to forward the appropriate developers. Ciao Hannes & Derek --DOr4Pqkebcd12QSCcGuXeFrRE6mllEnqL 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 iQEcBAEBCgAGBQJWkqoaAAoJEGhJURNOOiAtfgcH/0Da16SZWgF+w69mHKHyFHGO CoVsolXN9pN+DgIMPbvXyFIpG5uy5gERr8GrihFIpz3r4aiGiMP5dFRKcHIwpwry axctfE+OyKKdqZuvpbTshZHhzn5wslZ746tED/AnolPDX4vVWfcYnLgc6rS63BW6 kUvUZ4qTbLcPgqWpulqqk8uCfodrQMu+NBAfg2k1nnfDwrwrG9uZkn8qjKFohixY BX9bCFIq/wuxlJ28dK1qINCfHgrrMqK0hyNt+EboH3aVYBCnnxdvHEzDHy2AQiCm nBUaBzmsZtRP0DcEdkR5ONUKy8LF4w5/U0lXspnBoTlmCp+/eFHeuDsJNK8Q4Ww= =HZyi -----END PGP SIGNATURE----- --DOr4Pqkebcd12QSCcGuXeFrRE6mllEnqL-- From nobody Mon Jan 11 01:27:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720591A8863 for ; Mon, 11 Jan 2016 01:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOWAwxMTJD65 for ; Mon, 11 Jan 2016 01:27:37 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B35B1A8862 for ; Mon, 11 Jan 2016 01:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1NILvSMZdf6r6oyd8IJ4tOliOklRP8eWzgGLGI/hcZQ=; b=WfJ2TH3ZVERN5De1FgWsZVSb/ClfvMPQT8DR52+HmLTzv7wknaNN3Ea8/dkeRs3H58M4Zpy6+Wb++s+aw/hmkf635OzTvu/No56fzuiKbJD7LSRVVgyPvQAybjZH7dym1nVdvd0tXB6jIE2H/5ZDZpwIl1lvRWoLIPWf7QmNzKU= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 11 Jan 2016 09:27:23 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0361.006; Mon, 11 Jan 2016 09:27:23 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Mix-Up Mitigation Thread-Index: AdFMSEdeh3slUb5fSSeAYII0TkfznQ== Date: Mon, 11 Jan 2016 09:27:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:Vb4FOsNyf4FS3go4vBdGvqKmshvkG+aELxsqNGw6o+ceINgYgugrH1xeyyHPbcteosymPmF7187U/8Zxhxg6pC7RXa4Q3bx1OMZM1THkovjAPTcVqPAvMB3IUvc37Sh6KGmIT02z+P7PUdbpnkvWHg==; 24:f1GX6oaNSk5co0RTF4gfXLAkRCzIBWKMZHrhDrwsoLDW1FW9T9ZdwQCjR+ITNlWoNkbulfYOZwIavkbVz0dGVRWAp3gJTf1+P9oTa+D9EfY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-ms-office365-filtering-correlation-id: ecac968a-9547-4af8-ecaf-08d31a696966 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(199003)(189998001)(19617315012)(5005710100001)(107886002)(106356001)(110136002)(87936001)(76576001)(1730700002)(102836003)(790700001)(6116002)(2351001)(19300405004)(10290500002)(19625215002)(1220700001)(11100500001)(3846002)(92566002)(5001960100002)(77096005)(229853001)(2501003)(74316001)(81156007)(50986999)(86362001)(105586002)(86612001)(54356999)(8990500004)(97736004)(33656002)(1096002)(586003)(40100003)(16236675004)(450100001)(10400500002)(66066001)(122556002)(5008740100001)(2900100001)(2906002)(10090500001)(5004730100002)(5002640100001)(101416001)(19580395003)(15975445007)(99286002)(5003600100002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442D5C13C5157A506DAC9B0F5C90BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2016 09:27:21.8800 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 09:27:40 -0000 --_000_BY2PR03MB442D5C13C5157A506DAC9B0F5C90BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authori= zation Server Mix-Up. This note announces the publication of the strawman OA= uth 2.0 Mix-Up Mitigation draft he mentioned that mitigates the attacks cov= ered in the advisory. The abstract of the specification is: This specification defines an extension to The OAuth 2.0 Authorization Fram= ework that enables an authorization server to provide a client using it wit= h a consistent set of metadata about itself. This information is returned i= n the authorization response. It can be used by the client to prevent class= es of attacks in which the client might otherwise be tricked into using inc= onsistent sets of metadata from multiple authorization servers, including p= otentially using a token endpoint that does not belong to the same authoriz= ation server as the authorization endpoint used. Recent research publicatio= ns refer to these as "IdP Mix-Up" and "Malicious Endpoint" attacks. The gist of the mitigation is having the authorization server return the cl= ient ID and its issuer identifier (a value defined in the OAuth Discovery s= pecification) so that the client can ver= ify that it is using a consistent set of authorization server configuration= information, that the client ID is for that authorization server, and in p= articular, that the client is not being confused into sending information i= ntended for one authorization server to a different one. Note that these a= ttacks can only be made against clients that are configured to use more tha= n one authorization server. Please give the draft a quick read and provide feedback to the OAuth workin= g group. This draft is very much a starting point intended to describe bot= h the mitigations and the decisions and analysis remaining before we can be= confident in standardizing a solution. Please definitely read the Securit= y Considerations and Open Issues sections, as they contain important inform= ation about the choices made and the decisions remaining. Special thanks go to Daniel Fett (University of Trier), Christian Mainka (R= uhr-University Bochum), Vladislav Mladenov (Ruhr-University Bochum), and Gu= ido Schmitz (University of Trier) for notifying us of the attacks and worki= ng with us both on understanding the attacks and on developing mitigations.= Thanks too to Hannes Tschofenig for organizing a meeting on this topic la= st month and to Torsten Lodderstedt and Deutsche Telekom for hosting the me= eting. The specification is available at: * http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00= .html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1524 and as= @selfissued. --_000_BY2PR03MB442D5C13C5157A506DAC9B0F5C90BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authorization Server Mix-Up.  This note= announces the publication of the strawman OAuth 2.0 Mix-Up Mitigation draf= t he mentioned that mitigates the attacks covered in the advisory.  Th= e abstract of the specification is:

 

This specification define= s an extension to The OAuth 2.0 Authorization Framework that enables an aut= horization server to provide a client using it with a consistent set of met= adata about itself. This information is returned in the authorization response. It can be used by the client to= prevent classes of attacks in which the client might otherwise be tricked = into using inconsistent sets of metadata from multiple authorization server= s, including potentially using a token endpoint that does not belong to the same authorization server as th= e authorization endpoint used. Recent research publications refer to these = as "IdP Mix-Up" and "Malicious Endpoint" attacks.<= /o:p>

 

The gist of the mitigation is having the authorizati= on server return the client ID and its issuer identifier (a value defined i= n the OAuth Discovery specification= ) so that the client can verify that it is using a consistent set of au= thorization server configuration information, that the client ID is for tha= t authorization server, and in particular, that the client is not being confused into sending information intended fo= r one authorization server to a different one.  Note that these attack= s can only be made against clients that are configured to use more than one= authorization server.

 

Please give the draft a quick read and provide feedb= ack to the OAuth working group.  This draft is very much a starting po= int intended to describe both the mitigations and the decisions and analysi= s remaining before we can be confident in standardizing a solution.  Please definitely read the Security Con= siderations and Open Issues sections, as they contain important information= about the choices made and the decisions remaining.

 

Special thanks go to Daniel Fett (University of Trie= r), Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-Uni= versity Bochum), and Guido Schmitz (University of Trier) for notifying us o= f the attacks and working with us both on understanding the attacks and on developing mitigations.  Tha= nks too to Hannes Tschofenig for organizing a meeting on this topic last mo= nth and to Torsten Lodderstedt and Deutsche Telekom for hosting the meeting= .

 

The specification is available at:

·       http://tools.ietf.org/html/draft-jones-oa= uth-mix-up-mitigation-00

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/draft= -jones-oauth-mix-up-mitigation-00.html

 

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

 

P.S.  This note was also posted at http://self-issued.info/?p=3D= 1524 and as @selfissued<= span style=3D"font-size:10.0pt;font-family:"Segoe UI",sans-serif;= color:black">.

--_000_BY2PR03MB442D5C13C5157A506DAC9B0F5C90BY2PR03MB442namprd_-- From nobody Mon Jan 11 05:31:15 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77A51A8A60 for ; Mon, 11 Jan 2016 05:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BjJLb2icrE5D for ; Mon, 11 Jan 2016 05:31:10 -0800 (PST) Received: from mail-qg0-x264.google.com (mail-qg0-x264.google.com [IPv6:2607:f8b0:400d:c04::264]) (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 A0C4C1A8A57 for ; Mon, 11 Jan 2016 05:31:07 -0800 (PST) Received: by mail-qg0-x264.google.com with SMTP id o11so44796538qge.3 for ; Mon, 11 Jan 2016 05:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :accept-language:content-language:content-type :content-transfer-encoding:mime-version; bh=kMrODY3/iVH85jQ8Rnj2M+yoGAkuNZUdnnqPrj9r8aw=; b=K2DYAHTuRyydfTBLmmz4O2wziJgqkRCYBRjN+VUeUuxN82uqwVLdXsF7glG8fq4AIs FLnpJEKIwto+DYMfZeq3NtIkrb1T5EjXJx//Vzg8DyRnEj+WU7gEYFPJ4zANPXmVxwkX YaA1PnK2H28TGQQCIjidohcxXBbHyaqxzwG9ijKmaYRz+NGMdnUDrMRYQgGyMLJrKHd9 vY+1p0dMXPqj5wXXUgIxEkzcJmSbRz4FEtc0eh7sjMLcouqNspLBdR56b1Kt0sY6uLYE MnIskuGcrSmu361BPQ0JshdyVyDBesrrHReH31icS6RfIxhozXAC5uCUgFfJgCWQ8aQd rAqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:accept-language:content-language:content-type :content-transfer-encoding:mime-version; bh=kMrODY3/iVH85jQ8Rnj2M+yoGAkuNZUdnnqPrj9r8aw=; b=GPkmtcJfJ3zDvztlAOy7YK4dY3hNyVo2KkoSHCCcNRlhNNKjJP+prQgwV1OsIk8nAs x7TKBLJOp+KIs3jIoOrRSlvGmzCrghKNPymgdf1SUxVdpZEMETWhwCMfbi39+u99h9xd QD5InEoWPbNF7TYF1Q/kn/rI2L1/PeUP4UQR+GnAgv9nN0dvq7zofNK7KXTDvHyBKnVH D0zkRSMw64GVCaDqwPgMMVLwSs56TEMXlTNfwwqk915S0nLEUr+s4jykvge+SUfR1qiV 9BEy1Obx4H38bKXGQqF3kyaOadPdKIDcNImLxO1vzn5Bn86RRZWNNuoPCjj+SAN5kbsW XBEw== X-Gm-Message-State: ALoCoQk93G/0pBahxddR6bHBtKEbLODmVmu0XgSmsi1ht6naJrHknut3OY3R7hPRdRZjlZ2csie9fBecE9ExEZoXTPwmuQCqLAiUVPy6nEkvs+ctLiNj3IU= X-Received: by 10.55.40.160 with SMTP id o32mr9579112qko.93.1452519066635; Mon, 11 Jan 2016 05:31:06 -0800 (PST) Received: from brn1lxmailout01.verisign.com (brn1lxmailout01.verisign.com. [72.13.63.41]) by smtp-relay.gmail.com with ESMTPS id y16sm2656273qka.6.2016.01.11.05.31.06 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 11 Jan 2016 05:31:06 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id u0BDV6f6022192 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Jan 2016 08:31:06 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Mon, 11 Jan 2016 08:31:04 -0500 From: "Hollenbeck, Scott" To: "OAuth@ietf.org" Thread-Topic: Cross-Area Review Request for RDAP Authentication Thread-Index: AdFMdFIjlomRE03AR0yFxWcnxij5bw== Date: Mon, 11 Jan 2016 13:31:05 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A129732@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [OAUTH-WG] Cross-Area Review Request for RDAP Authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 13:31:13 -0000 I'd like to ask folks who are more familiar with OAuth than I am to please = review an I-D I've written that describes an approach to using OpenID Conne= ct with the Registration Data Access Protocol (RDAP, a product of the WEIRD= S WG). Those of you who are familiar with WHOIS will understand the motivat= ion behind the development of RDAP and the benefits of being able to authen= ticate clients. The I-D can be found here: https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/ Note that RDAP does not depend on clients using web browsers. I have some t= ext in the document that describes how to use OpenID Connect with non-brows= er clients and I'd like to ensure that it all makes sense. Thank you, Scott From nobody Mon Jan 11 08:16:25 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22B21A7002 for ; Mon, 11 Jan 2016 08:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4opGPyY_xJrp for ; Mon, 11 Jan 2016 08:16:21 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D501A6F62 for ; Mon, 11 Jan 2016 08:16:21 -0800 (PST) Received: from [192.168.10.141] ([146.108.200.221]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lx8ZJ-1a7Cu33AvR-016j6s for ; Mon, 11 Jan 2016 17:16:18 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5693D556.8090607@gmx.net> Date: Mon, 11 Jan 2016 17:16:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wTH8FlGUXcBMHoFDvh1SPPskwDSwu9fk9" X-Provags-ID: V03:K0:wobCltpcvDDTq92jdrdEP6SO5MAdTY6tQzMaF1sCOVG8I99WH/n PWqeaS4Y2H0C5zq7X6FqAA8rfjGWdOIvrPMNjWH5Z0ORMlnyG53izx/4yuUFvBGISqRP914 nHQ3ojKEGFrO6vxulCFoiKPEE+jnDBwtXXDmJyH/x1UPADD3SN4C+VipaE+5VgafsCZTcVe t4YDXjJqyD5r02mRU+YVg== X-UI-Out-Filterresults: notjunk:1;V01:K0:KmtCK1sX8xg=:MAUt9YlxUhtJAtVthU0oXd 88BAby0XKEE+YqS7j/55WBc9cF7EEJ2AXvSf5hknW4C8xgiAz1ZLU52A30aQs+SyQ5sCM3/Pq ltuscg4ip2mVIuetQEuz9fC0/n8vBqlOeA7h/FP8bvRlwRx/o4iSbarleFg2yR1yC1eNGiwE+ iVRNieahaKEelvgp3tcwIv4qkQTmPueg4Yyk3VvxFD3iU92g95E/h4zm82snqP2LkGfdSGZFr pouzrkUyqSFSaMDbr2RfxHpWNsR3aR67hF0b2A/H+ZNTfUSJaadizdwYPDDl2Bbf5pAlM1PuA UqEjkcysXA2s10zx0KmB59eGo2dnxczN7wa4ikrBfNGwodB9Cd3dr59gAYDAmHnA7I6hpWlMr 5sdiWy28DJUDrrMj9b1vaiFwc6bM3XXb+VnRgHhOC/u25JwG00XNAjBMqdSrMtsEjYR93a/ux CwePO0IMAQWI41heN+HfMA5L3MD4GFAbxPpTa7/AN4nKNn+XWT4+nXxHfEMVR9OXI2sq/pXt5 T6mVPggEWEt78P1mF62JrlDO5kqfISd05gfJaJL7Rxh88QymgCtojMEf1nKzixZrq4wBf3iz3 QqmzigV/0VLJk2JzWPbY5FsxFr5yaP0ZsXtC9a+k8ihbdfeCJL0CtCg7cKcTqdwMgFV07dg4q mcHsT3JuIfD5Zu1EtgutBThB4t9Z88tNaV5Ak56VsJ0HW26psTxyieY4dwd19kjiLZXhItZHZ KO1qcHWMJYk3cp81QaGFC0Jy0zMFCZakc+pnsJsIdEAynsnVrzBG8BcqAOw= Archived-At: Subject: [OAUTH-WG] OAuth Security Workshop -- July 14th and 15th 2016 in Trier/Germany X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 16:16:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wTH8FlGUXcBMHoFDvh1SPPskwDSwu9fk9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable In context of the recent findings from researchers related to OAuth and OpenID Connect, see announcement at http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html, we are convinced that the wider Internet security community can help to improve the security of Internet protocols. In an attempt to reach out to security experts from research, industry, and standardization we are announcing a workshop on OAuth security to be held during the week before the summer IETF meeting, namely July 14th and 15th 2016 in Trier/Germany. Our host will be the Chair for Information Security and Cryptography at the University of Trier. More details about the workshop, including registration information and logistics, will be provided in the next few weeks. As such, this is merely early planning information for those attending the summer IETF meeting and for researchers looking into OAuth and related technologies. In terms of the scope for the workshop we are seeking papers and talks related to OAuth, OpenID Connect, and other technologies using OAuth under the hood. Contributions of technologies that are used in OAuth, such as JOSE, or impact the security of OAuth, such as Web technology, are also welcome. The workshop will be structured as a series of sessions punctuated by invited speakers who will present their security findings, and relevant background information that help participants reach a deeper understanding of OAuth security. The organizing committee invites security experts from research, industry, and standardization to submit position papers to present their ideas and experiences at the workshop (details to follow). Participants will have to register for the workshop and we will have to charge a small amount for food and drinks (unless we manage to find a sponsor in time). We also plan to organize a social event in the evening of July 14th. This may include a guided sightseeing tour to some of the eight world heritage sites in Germany=E2=80=99s oldest city Trier.= All presentations and papers will be put online but there will be no formal proceedings. Therefore, abstracts submitted to the OAuth Security Workshop may report on (unpublished) work in progress, be submitted to other places, and they may even already have appeared or been accepted elsewhere. While the standardization process ensures extensive reviews, both security and non-security related reviews, further analysis by security experts from academia and industry is essential to ensure high quality specifications. Your contribution can help to improve the security of the Web and the Internet. For further questions please contact the OAuth working group chairs at oauth-chairs@ietf.org. --wTH8FlGUXcBMHoFDvh1SPPskwDSwu9fk9 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 iQEcBAEBCgAGBQJWk9VXAAoJEGhJURNOOiAtmvwH+weubcqcC6o3jHkZMAB2qVhf qoax2lg7DJsbOsSYrNZ2BPHBzp6fR0a/zB88nTnApTwpFCaRI/kQEeK9NGc3fMVS hoiOQrD0PMMTM53M+99q36Fkw53+rCLwVAmD8Mztit+Kp5qCbLiv5SsMGFr+JFNZ +dRKkoNsbnIAkZ2SKGrnRTq/UTLDhZTkXNGFboFW3hXJSDwa7LGk3Xy29OmadbKB 0dDcuSvf7lCFm58zjvvryAPZOdfDueTjrCXxUhhVWDFmWhR9pP7+OuqvS6WuZ2W0 xdQG/PqBfjuQPvWzQVMjR7rAPaNSTCxAYhxo29P0CfZTO2cDq+2e3jjf/7ig8LA= =e6vM -----END PGP SIGNATURE----- --wTH8FlGUXcBMHoFDvh1SPPskwDSwu9fk9-- From nobody Mon Jan 11 10:19:55 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8971A8F4D for ; Mon, 11 Jan 2016 10:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AOjs9vhxLEy for ; Mon, 11 Jan 2016 10:19:52 -0800 (PST) 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 52CE81A8F48 for ; Mon, 11 Jan 2016 10:19:52 -0800 (PST) Received: from mtaout-aaj01.mx.aol.com (mtaout-aaj01.mx.aol.com [172.27.3.205]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 154D83800119; Mon, 11 Jan 2016 13:19:51 -0500 (EST) Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aaj01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B082C38000092; Mon, 11 Jan 2016 13:19:50 -0500 (EST) To: Mike Jones , "oauth@ietf.org" References: From: George Fletcher Organization: AOL LLC Message-ID: <5693F276.8020501@aol.com> Date: Mon, 11 Jan 2016 13:20:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030307010605080804060601" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1452536391; bh=9H+eYrpqCjb6buFB6J28sLv87RkddxvgG/GEyJ4nz48=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=6yFPSeKGNtzH2RFyr1AHfm762X0bpJd0/z2N5wusrq6R9nvp1NFjCk3L5hf+x4R29 TfXzAus9XH7R4nXXuUx20YM3XaxLML2tJF88Wj8CZeZd9ZayJ2X16+lJCoIXRgKXui fM+tyygpa4fMdCJnPNlDs5imbvn0CsgePldMaX2g= x-aol-sid: 3039ac1b03cd5693f2462638 X-AOL-IP: 10.172.102.124 Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 18:19:54 -0000 This is a multi-part message in MIME format. --------------030307010605080804060601 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Thanks Mike. One question after reading about the different attack vectors and this spec... How are the 'iss' and 'aud' values returned with the 'code' and 'state' parameters. It seems the client needs to verify the endpoints before making the request to exchange the code for a token. If the client is using the default OAuth2 client_id and client_secret these values will be sent to the malicious endpoint if the client can't verify the endpoints before hand. Also, it would be nice to add some non-normative examples to the spec. Thanks, George On 1/11/16 4:27 AM, Mike Jones wrote: > > Yesterday Hannes Tschofenig announced an OAuth Security Advisory on > Authorization Server Mix-Up > . > This note announces the publication of the strawman OAuth 2.0 Mix-Up > Mitigation draft he mentioned that mitigates the attacks covered in > the advisory. The abstract of the specification is: > > This specification defines an extension to The OAuth 2.0 Authorization > Framework that enables an authorization server to provide a client > using it with a consistent set of metadata about itself. This > information is returned in the authorization response. It can be used > by the client to prevent classes of attacks in which the client might > otherwise be tricked into using inconsistent sets of metadata from > multiple authorization servers, including potentially using a token > endpoint that does not belong to the same authorization server as the > authorization endpoint used. Recent research publications refer to > these as "IdP Mix-Up" and "Malicious Endpoint" attacks. > > The gist of the mitigation is having the authorization server return > the client ID and its issuer identifier (a value defined in the OAuth > Discovery specification ) so that the > client can verify that it is using a consistent set of authorization > server configuration information, that the client ID is for that > authorization server, and in particular, that the client is not being > confused into sending information intended for one authorization > server to a different one. Note that these attacks can only be made > against clients that are configured to use more than one authorization > server. > > Please give the draft a quick read and provide feedback to the OAuth > working group. This draft is very much a starting point intended to > describe both the mitigations and the decisions and analysis remaining > before we can be confident in standardizing a solution. Please > definitely read the Security Considerations and Open Issues sections, > as they contain important information about the choices made and the > decisions remaining. > > Special thanks go to Daniel Fett (University of Trier), Christian > Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-University > Bochum), and Guido Schmitz (University of Trier) for notifying us of > the attacks and working with us both on understanding the attacks and > on developing mitigations. Thanks too to Hannes Tschofenig for > organizing a meeting on this topic last month and to Torsten > Lodderstedt and Deutsche Telekom for hosting the meeting. > > The specification is available at: > > ·http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 > > An HTML-formatted version is also available at: > > ·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html > > -- Mike > > P.S. This note was also posted at http://self-issued.info/?p=1524 and > as @selfissued . > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography --------------030307010605080804060601 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Thanks Mike. One question after reading about the different attack vectors and this spec...

How are the 'iss' and 'aud' values returned with the 'code' and 'state' parameters. It seems the client needs to verify the endpoints before making the request to exchange the code for a token. If the client is using the default OAuth2 client_id and client_secret these values will be sent to the malicious endpoint if the client can't verify the endpoints before hand.

Also, it would be nice to add some non-normative examples to the spec.

Thanks,
George

On 1/11/16 4:27 AM, Mike Jones wrote:

Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authorization Server Mix-Up.  This note announces the publication of the strawman OAuth 2.0 Mix-Up Mitigation draft he mentioned that mitigates the attacks covered in the advisory.  The abstract of the specification is:

 

This specification defines an extension to The OAuth 2.0 Authorization Framework that enables an authorization server to provide a client using it with a consistent set of metadata about itself. This information is returned in the authorization response. It can be used by the client to prevent classes of attacks in which the client might otherwise be tricked into using inconsistent sets of metadata from multiple authorization servers, including potentially using a token endpoint that does not belong to the same authorization server as the authorization endpoint used. Recent research publications refer to these as "IdP Mix-Up" and "Malicious Endpoint" attacks.

 

The gist of the mitigation is having the authorization server return the client ID and its issuer identifier (a value defined in the OAuth Discovery specification) so that the client can verify that it is using a consistent set of authorization server configuration information, that the client ID is for that authorization server, and in particular, that the client is not being confused into sending information intended for one authorization server to a different one.  Note that these attacks can only be made against clients that are configured to use more than one authorization server.

 

Please give the draft a quick read and provide feedback to the OAuth working group.  This draft is very much a starting point intended to describe both the mitigations and the decisions and analysis remaining before we can be confident in standardizing a solution.  Please definitely read the Security Considerations and Open Issues sections, as they contain important information about the choices made and the decisions remaining.

 

Special thanks go to Daniel Fett (University of Trier), Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-University Bochum), and Guido Schmitz (University of Trier) for notifying us of the attacks and working with us both on understanding the attacks and on developing mitigations.  Thanks too to Hannes Tschofenig for organizing a meeting on this topic last month and to Torsten Lodderstedt and Deutsche Telekom for hosting the meeting.

 

The specification is available at:

·       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00

 

An HTML-formatted version is also available at:

·       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html

 

                                                          -- Mike

 

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



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


-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography
--------------030307010605080804060601-- From nobody Mon Jan 11 11:59:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E231A90BA for ; Mon, 11 Jan 2016 11:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnDOI_8x1mP8 for ; Mon, 11 Jan 2016 11:59:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562F71A90B7 for ; Mon, 11 Jan 2016 11:59:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y8p8CGs2JVSdVOD8mZjYkE7Rd9T4sK4tA4RjaluAq5Y=; b=ZEAhiHAH6LONdYBJiu1/QL3zX65+k/iiYkpbdxeI2ZAzehy6G6lAvGFZOObaDRSz+OYY5SSA3mElpXqarwYNxddnUVyY8gcOMz1UJFlV8OMUExeCpC2fck199m7HQWUXqIqTZAtXs3bnwVJ1btcVCgcw7om2gjo0m7d5JtTQZ08= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 11 Jan 2016 19:59:22 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0361.006; Mon, 11 Jan 2016 19:59:21 +0000 From: Mike Jones To: George Fletcher , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation Thread-Index: AdFMSEdeh3slUb5fSSeAYII0TkfznQAVH34AAALUM/A= Date: Mon, 11 Jan 2016 19:59:21 +0000 Message-ID: References: <5693F276.8020501@aol.com> In-Reply-To: <5693F276.8020501@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [12.130.116.69] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:NJuQnwr+Aez8Y3rptzm43GWBiLZTGNhOpAoe+q38bloVe7U5rNo5IOkoYwVtSwe/pN60AH36zhmVmR6ATwYvi7lxooYiCPH7/3kdRJJrFnH2/VQA88GGegm78eI8rBPJLTmmvQNGUEOjR7R3q0qaPg==; 24:TqicmwXXfKI6f0/zz0YxgymQelFl5aUdyctqBa42OBwiuufnwhZ9EHAT4Lx9WIIf+RA/fPRb+qvSb1H8zxB1IjGPX4FbV93GLcHNQtLP7B8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-ms-office365-filtering-correlation-id: 72e3a277-305a-45a1-a0e8-08d31ac1b2ac x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(149059832740258); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(24454002)(189002)(199003)(377454003)(479174004)(164054003)(5004730100002)(81156007)(5003600100002)(5001960100002)(101416001)(790700001)(6116002)(15395725005)(5005710100001)(189998001)(122556002)(10400500002)(2950100001)(107886002)(50986999)(33656002)(19580395003)(86612001)(97736004)(10290500002)(1220700001)(586003)(1096002)(2906002)(15975445007)(5001770100001)(66066001)(19300405004)(3846002)(92566002)(8990500004)(5002640100001)(77096005)(74316001)(76576001)(76176999)(54356999)(2900100001)(40100003)(1600100001)(19617315012)(19625215002)(86362001)(2501003)(99286002)(105586002)(87936001)(106356001)(10090500001)(16236675004)(5008740100001)(19580405001)(102836003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442C71F1A51D05DD7390ABAF5C90BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2016 19:59:21.6477 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 19:59:52 -0000 --_000_BY2PR03MB442C71F1A51D05DD7390ABAF5C90BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The alternatives for the code flow are to return them either in a new JWT a= dded to the reply containing them in the "iss" and "aud" claims or to retur= n them in new individual "client_id" and "iss" authorization response param= eters. Both alternatives are described in the draft. I'm sure that we'll = now be having a good engineering discussion on the tradeoffs between the al= ternatives., In a separate draft, John Bradley will shortly also be describing the possi= bility of securing the "state" value using a "state_hash" value that works = in a way that's similar to how "at_hash" and "c_hash" secure the "access_to= ken" and "code" values in Connect. This would be an alternative means of b= inding the authorization request and response to the session - accomplishin= g the same thing that the Connect "nonce" does. While I fully get that some OAuth implementations want to avoid having to h= ave crypto, it seems like at least support for cryptographic hashing (SHA-2= 56, etc.) may be necessary to mitigate some of these attacks (at least for = clients that use more than one authorization server). The other important engineering discussion I know we're going to have is wh= ether, when an OAuth profile already returns the information needed for the= mitigation, whether we want to specify that the client obtain it from the = existing location, or whether to also return it in a duplicate location. I= 'll note that OpenID Connect already returns the client ID and issuer for t= he flows that return an ID Token in the authorization response, so this isn= 't a hypothetical question. Finally, I know that we'll need to discuss the impact of cut-and-paste atta= cks when the issuer and client ID are returned as individual authorization = response parameters that are not cryptographically bound to the rest of the= response. The cut-and-paste attack that returning the issuer and client_i= d values as separate parameters enables, even when state_hash or nonce is u= sed, is for the attacker to capture the legitimate response containing "iss= " and "client_id" results and substitute different values for these fields,= then post that altered response to the legitimate client. The state and/o= r nonce values are protected against substitution but "iss" and "client_id"= are not. And yes, I absolutely agree that good examples are essential. That's high = on my list for the -01 version. Thanks a bunch, -- Mike From: George Fletcher [mailto:gffletch@aol.com] Sent: Monday, January 11, 2016 10:21 AM To: Mike Jones ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation Thanks Mike. One question after reading about the different attack vectors = and this spec... How are the 'iss' and 'aud' values returned with the 'code' and 'state' par= ameters. It seems the client needs to verify the endpoints before making th= e request to exchange the code for a token. If the client is using the defa= ult OAuth2 client_id and client_secret these values will be sent to the mal= icious endpoint if the client can't verify the endpoints before hand. Also, it would be nice to add some non-normative examples to the spec. Thanks, George On 1/11/16 4:27 AM, Mike Jones wrote: Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authori= zation Server Mix-Up. This note announces the publication of the strawman OA= uth 2.0 Mix-Up Mitigation draft he mentioned that mitigates the attacks cov= ered in the advisory. The abstract of the specification is: This specification defines an extension to The OAuth 2.0 Authorization Fram= ework that enables an authorization server to provide a client using it wit= h a consistent set of metadata about itself. This information is returned i= n the authorization response. It can be used by the client to prevent class= es of attacks in which the client might otherwise be tricked into using inc= onsistent sets of metadata from multiple authorization servers, including p= otentially using a token endpoint that does not belong to the same authoriz= ation server as the authorization endpoint used. Recent research publicatio= ns refer to these as "IdP Mix-Up" and "Malicious Endpoint" attacks. The gist of the mitigation is having the authorization server return the cl= ient ID and its issuer identifier (a value defined in the OAuth Discovery s= pecification) so that the client can ver= ify that it is using a consistent set of authorization server configuration= information, that the client ID is for that authorization server, and in p= articular, that the client is not being confused into sending information i= ntended for one authorization server to a different one. Note that these a= ttacks can only be made against clients that are configured to use more tha= n one authorization server. Please give the draft a quick read and provide feedback to the OAuth workin= g group. This draft is very much a starting point intended to describe bot= h the mitigations and the decisions and analysis remaining before we can be= confident in standardizing a solution. Please definitely read the Securit= y Considerations and Open Issues sections, as they contain important inform= ation about the choices made and the decisions remaining. Special thanks go to Daniel Fett (University of Trier), Christian Mainka (R= uhr-University Bochum), Vladislav Mladenov (Ruhr-University Bochum), and Gu= ido Schmitz (University of Trier) for notifying us of the attacks and worki= ng with us both on understanding the attacks and on developing mitigations.= Thanks too to Hannes Tschofenig for organizing a meeting on this topic la= st month and to Torsten Lodderstedt and Deutsche Telekom for hosting the me= eting. The specification is available at: * http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00= .html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1524 and as= @selfissued. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography --_000_BY2PR03MB442C71F1A51D05DD7390ABAF5C90BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The alternatives for t= he code flow are to return them either in a new JWT added to the reply cont= aining them in the “iss” and “aud” claims or to ret= urn them in new individual “client_id” and “iss” au= thorization response parameters.  Both alternatives are described in the draft.&n= bsp; I’m sure that we’ll now be having a good engineering discu= ssion on the tradeoffs between the alternatives.,

 

In a separate draft, J= ohn Bradley will shortly also be describing the possibility of securing the= “state” value using a “state_hash” value that work= s in a way that’s similar to how “at_hash” and “c_h= ash” secure the “access_token” and “code” values in Connect.&n= bsp; This would be an alternative means of binding the authorization reques= t and response to the session – accomplishing the same thing that the= Connect “nonce” does.

 

While I fully get that= some OAuth implementations want to avoid having to have crypto, it seems l= ike at least support for cryptographic hashing (SHA-256, etc.) may be neces= sary to mitigate some of these attacks (at least for clients that use more than one authorization server).

 

The other important en= gineering discussion I know we’re going to have is whether, when an O= Auth profile already returns the information needed for the mitigation, whe= ther we want to specify that the client obtain it from the existing location, or whether to also return it in a duplicate= location.  I’ll note that OpenID Connect already returns the cl= ient ID and issuer for the flows that return an ID Token in the authorizati= on response, so this isn’t a hypothetical question.=

 

Finally, I know that w= e’ll need to discuss the impact of cut-and-paste attacks when the iss= uer and client ID are returned as individual authorization response paramet= ers that are not cryptographically bound to the rest of the response.  The c= ut-and-paste attack that returning the issuer and client_id values as separ= ate parameters enables, even when state_hash or nonce is used, is for the a= ttacker to capture the legitimate response containing “iss” and “client_id” results and subst= itute different values for these fields, then post that altered response to= the legitimate client.  The state and/or nonce values are protected a= gainst substitution but “iss” and “client_id” are n= ot.

 

And yes, I absolutely = agree that good examples are essential.  That’s high on my list = for the -01 version.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    Thanks a bunch,

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

 

From:= George Fletcher [mailto:gffletch@aol.com]
Sent: Monday, January 11, 2016 10:21 AM
To: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

 

Thanks Mike. One question after rea= ding about the different attack vectors and this spec...

How are the 'iss' and 'aud' values returned with the 'code' and 'state' par= ameters. It seems the client needs to verify the endpoints before making th= e request to exchange the code for a token. If the client is using the defa= ult OAuth2 client_id and client_secret these values will be sent to the malicious endpoint if the client can't ve= rify the endpoints before hand.

Also, it would be nice to add some non-normative examples to the spec.

Thanks,
George

On 1/11/16 4:27 AM, Mike Jones wrote:

Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authorization Server Mix-Up.  This note= announces the publication of the strawman OAuth 2.0 Mix-Up Mitigation draf= t he mentioned that mitigates the attacks covered in the advisory.  Th= e abstract of the specification is:

 

This specification define= s an extension to The OAuth 2.0 Authorization Framework that enables an aut= horization server to provide a client using it with a consistent set of met= adata about itself. This information is returned in the authorization response. It can be used by the client to= prevent classes of attacks in which the client might otherwise be tricked = into using inconsistent sets of metadata from multiple authorization server= s, including potentially using a token endpoint that does not belong to the same authorization server as th= e authorization endpoint used. Recent research publications refer to these = as "IdP Mix-Up" and "Malicious Endpoint" attacks.<= /o:p>

 

The gist of the mitigation is having the authorizati= on server return the client ID and its issuer identifier (a value defined i= n the OAuth Discovery specification= ) so that the client can verify that it is using a consistent set of au= thorization server configuration information, that the client ID is for tha= t authorization server, and in particular, that the client is not being confused into sending information intended fo= r one authorization server to a different one.  Note that these attack= s can only be made against clients that are configured to use more than one= authorization server.

 

Please give the draft a quick read and provide feedb= ack to the OAuth working group.  This draft is very much a starting po= int intended to describe both the mitigations and the decisions and analysi= s remaining before we can be confident in standardizing a solution.  Please definitely read the Security Con= siderations and Open Issues sections, as they contain important information= about the choices made and the decisions remaining.

 

Special thanks go to Daniel Fett (University of Trie= r), Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-Uni= versity Bochum), and Guido Schmitz (University of Trier) for notifying us o= f the attacks and working with us both on understanding the attacks and on developing mitigations.  Tha= nks too to Hannes Tschofenig for organizing a meeting on this topic last mo= nth and to Torsten Lodderstedt and Deutsche Telekom for hosting the meeting= .

 

The specification is available at:

·       http://tools.ietf.org/html/draft-jones-oa= uth-mix-up-mitigation-00

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/draft= -jones-oauth-mix-up-mitigation-00.html

 

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

 

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




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



-- 
Chief Architect         &=
nbsp;         
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.          &n=
bsp;            =
;   AIM:  gffletch
Mobile: +1-703-462-3494       &=
nbsp;   Twitter: http://t=
witter.com/gffletch
Office: +1-703-265-2544       &=
nbsp;   Photos: htt=
p://georgefletcher.photography
--_000_BY2PR03MB442C71F1A51D05DD7390ABAF5C90BY2PR03MB442namprd_-- From nobody Mon Jan 11 12:12:31 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE111A90DD for ; Mon, 11 Jan 2016 12:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFDiH9cQnxN0 for ; Mon, 11 Jan 2016 12:12:26 -0800 (PST) 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 4F7421A90DF for ; Mon, 11 Jan 2016 12:12:26 -0800 (PST) Received: from mtaout-maa01.mx.aol.com (mtaout-maa01.mx.aol.com [172.26.222.141]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 7416138003A1; Mon, 11 Jan 2016 15:12:25 -0500 (EST) Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-maa01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id CF72F38000090; Mon, 11 Jan 2016 15:12:24 -0500 (EST) To: Mike Jones , "oauth@ietf.org" References: <5693F276.8020501@aol.com> From: George Fletcher Organization: AOL LLC Message-ID: <56940CD8.8000701@aol.com> Date: Mon, 11 Jan 2016 15:13:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040201080308050603010504" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1452543145; bh=Ev5ZoEIwHaEJgR3tFe6F9/W4GeHexdEetMMEx94y8DA=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=mt+ooiNeq+NqWPZAreVm4KTxGvgAAilPIdryntzREbh1pepq5dZiaHx++hfH0QvO9 4zqGUUbbzd3YZO0cvVa1wEHxuI6hCA7Rn4eXYszQ69+z9ynUI9Akhq9j+q90U7ItCT jKotKpMAnFU3c8WHyKYbHqTeSpccYWjpdSTQe//U= x-aol-sid: 3039ac1ade8d56940ca80c1d X-AOL-IP: 10.172.102.124 Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 20:12:29 -0000 This is a multi-part message in MIME format. --------------040201080308050603010504 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit So just to make sure I understand... This specification requires the response from the Authorization Server to an successful /authorize call to pass back code=, state= and jwt= (?) or individually iss= and aud= as URL parameters on the 302 to the redirect_url. This way, before the client issues a call to the /token endpoint (with the code), it can verify that the token endpoint is correct. If the client doesn't validate the endpoints at this step, then it could disclose it's secret to a malicious endpoint. Correct? Thanks, George On 1/11/16 2:59 PM, Mike Jones wrote: > > The alternatives for the code flow are to return them either in a new > JWT added to the reply containing them in the “iss” and “aud” claims > or to return them in new individual “client_id” and “iss” > authorization response parameters. Both alternatives are described in > the draft. I’m sure that we’ll now be having a good engineering > discussion on the tradeoffs between the alternatives., > > In a separate draft, John Bradley will shortly also be describing the > possibility of securing the “state” value using a “state_hash” value > that works in a way that’s similar to how “at_hash” and “c_hash” > secure the “access_token” and “code” values in Connect. This would be > an alternative means of binding the authorization request and response > to the session – accomplishing the same thing that the Connect “nonce” > does. > > While I fully get that some OAuth implementations want to avoid having > to have crypto, it seems like at least support for cryptographic > hashing (SHA-256, etc.) may be necessary to mitigate some of these > attacks (at least for clients that use more than one authorization > server). > > The other important engineering discussion I know we’re going to have > is whether, when an OAuth profile already returns the information > needed for the mitigation, whether we want to specify that the client > obtain it from the existing location, or whether to also return it in > a duplicate location. I’ll note that OpenID Connect already returns > the client ID and issuer for the flows that return an ID Token in the > authorization response, so this isn’t a hypothetical question. > > Finally, I know that we’ll need to discuss the impact of cut-and-paste > attacks when the issuer and client ID are returned as individual > authorization response parameters that are not cryptographically bound > to the rest of the response. The cut-and-paste attack that returning > the issuer and client_id values as separate parameters enables, even > when state_hash or nonce is used, is for the attacker to capture the > legitimate response containing “iss” and “client_id” results and > substitute different values for these fields, then post that altered > response to the legitimate client. The state and/or nonce values are > protected against substitution but “iss” and “client_id” are not. > > And yes, I absolutely agree that good examples are essential. That’s > high on my list for the -01 version. > > Thanks a bunch, > > -- Mike > > *From:*George Fletcher [mailto:gffletch@aol.com] > *Sent:* Monday, January 11, 2016 10:21 AM > *To:* Mike Jones ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation > > Thanks Mike. One question after reading about the different attack > vectors and this spec... > > How are the 'iss' and 'aud' values returned with the 'code' and > 'state' parameters. It seems the client needs to verify the endpoints > before making the request to exchange the code for a token. If the > client is using the default OAuth2 client_id and client_secret these > values will be sent to the malicious endpoint if the client can't > verify the endpoints before hand. > > Also, it would be nice to add some non-normative examples to the spec. > > Thanks, > George > > On 1/11/16 4:27 AM, Mike Jones wrote: > > Yesterday Hannes Tschofenig announced an OAuth Security Advisory > on Authorization Server Mix-Up > . > This note announces the publication of the strawman OAuth 2.0 > Mix-Up Mitigation draft he mentioned that mitigates the attacks > covered in the advisory. The abstract of the specification is: > > This specification defines an extension to The OAuth 2.0 > Authorization Framework that enables an authorization server to > provide a client using it with a consistent set of metadata about > itself. This information is returned in the authorization > response. It can be used by the client to prevent classes of > attacks in which the client might otherwise be tricked into using > inconsistent sets of metadata from multiple authorization servers, > including potentially using a token endpoint that does not belong > to the same authorization server as the authorization endpoint > used. Recent research publications refer to these as "IdP Mix-Up" > and "Malicious Endpoint" attacks. > > The gist of the mitigation is having the authorization server > return the client ID and its issuer identifier (a value defined in > the OAuth Discovery specification > ) so that the client can verify > that it is using a consistent set of authorization server > configuration information, that the client ID is for that > authorization server, and in particular, that the client is not > being confused into sending information intended for one > authorization server to a different one. Note that these attacks > can only be made against clients that are configured to use more > than one authorization server. > > Please give the draft a quick read and provide feedback to the > OAuth working group. This draft is very much a starting point > intended to describe both the mitigations and the decisions and > analysis remaining before we can be confident in standardizing a > solution. Please definitely read the Security Considerations and > Open Issues sections, as they contain important information about > the choices made and the decisions remaining. > > Special thanks go to Daniel Fett (University of Trier), Christian > Mainka (Ruhr-University Bochum), Vladislav Mladenov > (Ruhr-University Bochum), and Guido Schmitz (University of Trier) > for notifying us of the attacks and working with us both on > understanding the attacks and on developing mitigations. Thanks > too to Hannes Tschofenig for organizing a meeting on this topic > last month and to Torsten Lodderstedt and Deutsche Telekom for > hosting the meeting. > > The specification is available at: > > ·http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 > > An HTML-formatted version is also available at: > > ·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html > > -- Mike > > P.S. This note was also posted at http://self-issued.info/?p=1524 > and as @selfissued . > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Chief Architect > Identity Services Engineering Work:george.fletcher@teamaol.com > AOL Inc. AIM: gffletch > Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch > Office: +1-703-265-2544 Photos:http://georgefletcher.photography -- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography --------------040201080308050603010504 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit So just to make sure I understand...

This specification requires the response from the Authorization Server to an successful /authorize call to pass back code=, state= and jwt= (?) or individually iss= and aud= as URL parameters on the 302 to the redirect_url. This way, before the client issues a call to the /token endpoint (with the code), it can verify that the token endpoint is correct.

If the client doesn't validate the endpoints at this step, then it could disclose it's secret to a malicious endpoint. Correct?

Thanks,
George

On 1/11/16 2:59 PM, Mike Jones wrote:

The alternatives for the code flow are to return them either in a new JWT added to the reply containing them in the “iss” and “aud” claims or to return them in new individual “client_id” and “iss” authorization response parameters.  Both alternatives are described in the draft.  I’m sure that we’ll now be having a good engineering discussion on the tradeoffs between the alternatives.,

 

In a separate draft, John Bradley will shortly also be describing the possibility of securing the “state” value using a “state_hash” value that works in a way that’s similar to how “at_hash” and “c_hash” secure the “access_token” and “code” values in Connect.  This would be an alternative means of binding the authorization request and response to the session – accomplishing the same thing that the Connect “nonce” does.

 

While I fully get that some OAuth implementations want to avoid having to have crypto, it seems like at least support for cryptographic hashing (SHA-256, etc.) may be necessary to mitigate some of these attacks (at least for clients that use more than one authorization server).

 

The other important engineering discussion I know we’re going to have is whether, when an OAuth profile already returns the information needed for the mitigation, whether we want to specify that the client obtain it from the existing location, or whether to also return it in a duplicate location.  I’ll note that OpenID Connect already returns the client ID and issuer for the flows that return an ID Token in the authorization response, so this isn’t a hypothetical question.

 

Finally, I know that we’ll need to discuss the impact of cut-and-paste attacks when the issuer and client ID are returned as individual authorization response parameters that are not cryptographically bound to the rest of the response.  The cut-and-paste attack that returning the issuer and client_id values as separate parameters enables, even when state_hash or nonce is used, is for the attacker to capture the legitimate response containing “iss” and “client_id” results and substitute different values for these fields, then post that altered response to the legitimate client.  The state and/or nonce values are protected against substitution but “iss” and “client_id” are not.

 

And yes, I absolutely agree that good examples are essential.  That’s high on my list for the -01 version.

 

                                                          Thanks a bunch,

                                                          -- Mike

 

From: George Fletcher [mailto:gffletch@aol.com]
Sent: Monday, January 11, 2016 10:21 AM
To: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

 

Thanks Mike. One question after reading about the different attack vectors and this spec...

How are the 'iss' and 'aud' values returned with the 'code' and 'state' parameters. It seems the client needs to verify the endpoints before making the request to exchange the code for a token. If the client is using the default OAuth2 client_id and client_secret these values will be sent to the malicious endpoint if the client can't verify the endpoints before hand.

Also, it would be nice to add some non-normative examples to the spec.

Thanks,
George

On 1/11/16 4:27 AM, Mike Jones wrote:

Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authorization Server Mix-Up.  This note announces the publication of the strawman OAuth 2.0 Mix-Up Mitigation draft he mentioned that mitigates the attacks covered in the advisory.  The abstract of the specification is:

 

This specification defines an extension to The OAuth 2.0 Authorization Framework that enables an authorization server to provide a client using it with a consistent set of metadata about itself. This information is returned in the authorization response. It can be used by the client to prevent classes of attacks in which the client might otherwise be tricked into using inconsistent sets of metadata from multiple authorization servers, including potentially using a token endpoint that does not belong to the same authorization server as the authorization endpoint used. Recent research publications refer to these as "IdP Mix-Up" and "Malicious Endpoint" attacks.

 

The gist of the mitigation is having the authorization server return the client ID and its issuer identifier (a value defined in the OAuth Discovery specification) so that the client can verify that it is using a consistent set of authorization server configuration information, that the client ID is for that authorization server, and in particular, that the client is not being confused into sending information intended for one authorization server to a different one.  Note that these attacks can only be made against clients that are configured to use more than one authorization server.

 

Please give the draft a quick read and provide feedback to the OAuth working group.  This draft is very much a starting point intended to describe both the mitigations and the decisions and analysis remaining before we can be confident in standardizing a solution.  Please definitely read the Security Considerations and Open Issues sections, as they contain important information about the choices made and the decisions remaining.

 

Special thanks go to Daniel Fett (University of Trier), Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-University Bochum), and Guido Schmitz (University of Trier) for notifying us of the attacks and working with us both on understanding the attacks and on developing mitigations.  Thanks too to Hannes Tschofenig for organizing a meeting on this topic last month and to Torsten Lodderstedt and Deutsche Telekom for hosting the meeting.

 

The specification is available at:

·       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00

 

An HTML-formatted version is also available at:

·       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html

 

                                                          -- Mike

 

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




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



-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography

-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography
--------------040201080308050603010504-- From nobody Mon Jan 11 12:15:00 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D417A1A8979 for ; Mon, 11 Jan 2016 12:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pWgrM0aAS7V for ; Mon, 11 Jan 2016 12:14:52 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F21561A8967 for ; Mon, 11 Jan 2016 12:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xW+UsZIZrF8eJzHF2hoGly20cR6izyKIVtq6zwpCUjU=; b=KbeUg8MFUD4m6zoYcfdQKW+d1ApGObQPD795tTIhhFbZLSsb1qaPT7quEPxCtLGaaLGFaWbbHlYh/bO2Xw//LpcMJsYXyWHInfC65kprhgD29ooXNAtjRUQjaXSEw5fIuQCKvOFhnb7qLIp672SA+ocGTy4ilya6AiMV4UYj5y8= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 11 Jan 2016 20:14:25 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0361.006; Mon, 11 Jan 2016 20:14:25 +0000 From: Mike Jones To: George Fletcher , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation Thread-Index: AdFMSEdeh3slUb5fSSeAYII0TkfznQAVH34AAALUM/AAARo6AAAACUsA Date: Mon, 11 Jan 2016 20:14:25 +0000 Message-ID: References: <5693F276.8020501@aol.com> <56940CD8.8000701@aol.com> In-Reply-To: <56940CD8.8000701@aol.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [12.130.116.69] x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:LmjerxrTNJbfQV4YOBZ4UVA8JfnbtJ3vOaH3ov2j2ZMkI1ygkj2a2eYJrs9I0cgragUOQ+WWAMWW5lBh/NmQ0XLDiVkBZef+kXI6RPEnkafqZJR3dqaq2jVwmRilhaqJgy22EajfhfsLKbyPbwk18A==; 24:6peRlQtl3+pns3r1Km4ucrXe5xy4sZ1Obs/iC9TWmylgSzwrUFb51L3Q/q+QhNTEp8mO87gTGqW+AxgeCr5YbZqBYhWWBrYDX1ZdXTMPH5A= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442; x-ms-office365-filtering-correlation-id: 1e477707-08b4-4517-8519-08d31ac3cd8e x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(149059832740258); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(24454002)(164054003)(199003)(479174004)(377454003)(189002)(1096002)(5001770100001)(586003)(15395725005)(33656002)(1600100001)(16236675004)(40100003)(105586002)(50986999)(86362001)(81156007)(86612001)(8990500004)(54356999)(97736004)(15975445007)(19580395003)(99286002)(5003600100002)(101416001)(2906002)(122556002)(76576001)(66066001)(10400500002)(2900100001)(5004730100002)(10090500001)(5002640100001)(5008740100001)(189998001)(76176999)(790700001)(2950100001)(102836003)(106356001)(5005710100001)(19617315012)(87936001)(107886002)(19580405001)(93886004)(3846002)(77096005)(92566002)(19625215002)(1220700001)(2501003)(74316001)(10290500002)(6116002)(11100500001)(5001960100002)(19300405004)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44280090C70D477698D3B7BF5C90BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2016 20:14:25.6798 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 20:14:59 -0000 --_000_BY2PR03MB44280090C70D477698D3B7BF5C90BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Correct From: George Fletcher [mailto:gffletch@aol.com] Sent: Monday, January 11, 2016 12:13 PM To: Mike Jones ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation So just to make sure I understand... This specification requires the response from the Authorization Server to a= n successful /authorize call to pass back code=3D, state=3D and jwt=3D (?) = or individually iss=3D and aud=3D as URL parameters on the 302 to the redir= ect_url. This way, before the client issues a call to the /token endpoint (= with the code), it can verify that the token endpoint is correct. If the client doesn't validate the endpoints at this step, then it could di= sclose it's secret to a malicious endpoint. Correct? Thanks, George On 1/11/16 2:59 PM, Mike Jones wrote: The alternatives for the code flow are to return them either in a new JWT a= dded to the reply containing them in the "iss" and "aud" claims or to retur= n them in new individual "client_id" and "iss" authorization response param= eters. Both alternatives are described in the draft. I'm sure that we'll = now be having a good engineering discussion on the tradeoffs between the al= ternatives., In a separate draft, John Bradley will shortly also be describing the possi= bility of securing the "state" value using a "state_hash" value that works = in a way that's similar to how "at_hash" and "c_hash" secure the "access_to= ken" and "code" values in Connect. This would be an alternative means of b= inding the authorization request and response to the session - accomplishin= g the same thing that the Connect "nonce" does. While I fully get that some OAuth implementations want to avoid having to h= ave crypto, it seems like at least support for cryptographic hashing (SHA-2= 56, etc.) may be necessary to mitigate some of these attacks (at least for = clients that use more than one authorization server). The other important engineering discussion I know we're going to have is wh= ether, when an OAuth profile already returns the information needed for the= mitigation, whether we want to specify that the client obtain it from the = existing location, or whether to also return it in a duplicate location. I= 'll note that OpenID Connect already returns the client ID and issuer for t= he flows that return an ID Token in the authorization response, so this isn= 't a hypothetical question. Finally, I know that we'll need to discuss the impact of cut-and-paste atta= cks when the issuer and client ID are returned as individual authorization = response parameters that are not cryptographically bound to the rest of the= response. The cut-and-paste attack that returning the issuer and client_i= d values as separate parameters enables, even when state_hash or nonce is u= sed, is for the attacker to capture the legitimate response containing "iss= " and "client_id" results and substitute different values for these fields,= then post that altered response to the legitimate client. The state and/o= r nonce values are protected against substitution but "iss" and "client_id"= are not. And yes, I absolutely agree that good examples are essential. That's high = on my list for the -01 version. Thanks a bunch, -- Mike From: George Fletcher [mailto:gffletch@aol.com] Sent: Monday, January 11, 2016 10:21 AM To: Mike Jones ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation Thanks Mike. One question after reading about the different attack vectors = and this spec... How are the 'iss' and 'aud' values returned with the 'code' and 'state' par= ameters. It seems the client needs to verify the endpoints before making th= e request to exchange the code for a token. If the client is using the defa= ult OAuth2 client_id and client_secret these values will be sent to the mal= icious endpoint if the client can't verify the endpoints before hand. Also, it would be nice to add some non-normative examples to the spec. Thanks, George On 1/11/16 4:27 AM, Mike Jones wrote: Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authori= zation Server Mix-Up. This note announces the publication of the strawman OA= uth 2.0 Mix-Up Mitigation draft he mentioned that mitigates the attacks cov= ered in the advisory. The abstract of the specification is: This specification defines an extension to The OAuth 2.0 Authorization Fram= ework that enables an authorization server to provide a client using it wit= h a consistent set of metadata about itself. This information is returned i= n the authorization response. It can be used by the client to prevent class= es of attacks in which the client might otherwise be tricked into using inc= onsistent sets of metadata from multiple authorization servers, including p= otentially using a token endpoint that does not belong to the same authoriz= ation server as the authorization endpoint used. Recent research publicatio= ns refer to these as "IdP Mix-Up" and "Malicious Endpoint" attacks. The gist of the mitigation is having the authorization server return the cl= ient ID and its issuer identifier (a value defined in the OAuth Discovery s= pecification) so that the client can ver= ify that it is using a consistent set of authorization server configuration= information, that the client ID is for that authorization server, and in p= articular, that the client is not being confused into sending information i= ntended for one authorization server to a different one. Note that these a= ttacks can only be made against clients that are configured to use more tha= n one authorization server. Please give the draft a quick read and provide feedback to the OAuth workin= g group. This draft is very much a starting point intended to describe bot= h the mitigations and the decisions and analysis remaining before we can be= confident in standardizing a solution. Please definitely read the Securit= y Considerations and Open Issues sections, as they contain important inform= ation about the choices made and the decisions remaining. Special thanks go to Daniel Fett (University of Trier), Christian Mainka (R= uhr-University Bochum), Vladislav Mladenov (Ruhr-University Bochum), and Gu= ido Schmitz (University of Trier) for notifying us of the attacks and worki= ng with us both on understanding the attacks and on developing mitigations.= Thanks too to Hannes Tschofenig for organizing a meeting on this topic la= st month and to Torsten Lodderstedt and Deutsche Telekom for hosting the me= eting. The specification is available at: * http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00= .html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1524 and as= @selfissued. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography -- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography --_000_BY2PR03MB44280090C70D477698D3B7BF5C90BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Correct

 

From:= George Fletcher [mailto:gffletch@aol.com]
Sent: Monday, January 11, 2016 12:13 PM
To: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

 

So just to make sure I understand..= .

This specification requires the response from the Authorization Server to a= n successful /authorize call to pass back code=3D, state=3D and jwt=3D (?) = or individually iss=3D and aud=3D as URL parameters on the 302 to the redir= ect_url. This way, before the client issues a call to the /token endpoint (with the code), it can verify that the toke= n endpoint is correct.

If the client doesn't validate the endpoints at this step, then it could di= sclose it's secret to a malicious endpoint. Correct?

Thanks,
George

On 1/11/16 2:59 PM, Mike Jones wrote:

The alternatives for t= he code flow are to return them either in a new JWT added to the reply cont= aining them in the “iss” and “aud” claims or to ret= urn them in new individual “client_id” and “iss” au= thorization response parameters.  Both alternatives are described in the draft.&n= bsp; I’m sure that we’ll now be having a good engineering discu= ssion on the tradeoffs between the alternatives.,

 

In a separate draft, J= ohn Bradley will shortly also be describing the possibility of securing the= “state” value using a “state_hash” value that work= s in a way that’s similar to how “at_hash” and “c_h= ash” secure the “access_token” and “code” values in Connect.&n= bsp; This would be an alternative means of binding the authorization reques= t and response to the session – accomplishing the same thing that the= Connect “nonce” does.

 

While I fully get that= some OAuth implementations want to avoid having to have crypto, it seems l= ike at least support for cryptographic hashing (SHA-256, etc.) may be neces= sary to mitigate some of these attacks (at least for clients that use more than one authorization server).=

 

The other important en= gineering discussion I know we’re going to have is whether, when an O= Auth profile already returns the information needed for the mitigation, whe= ther we want to specify that the client obtain it from the existing location, or whether to also return it in a duplicate= location.  I’ll note that OpenID Connect already returns the cl= ient ID and issuer for the flows that return an ID Token in the authorizati= on response, so this isn’t a hypothetical question.=

 

Finally, I know that w= e’ll need to discuss the impact of cut-and-paste attacks when the iss= uer and client ID are returned as individual authorization response paramet= ers that are not cryptographically bound to the rest of the response.  The cut-and-paste attack that returning th= e issuer and client_id values as separate parameters enables, even when sta= te_hash or nonce is used, is for the attacker to capture the legitimate res= ponse containing “iss” and “client_id” results and substitute different values for these fields, then post that a= ltered response to the legitimate client.  The state and/or nonce valu= es are protected against substitution but “iss” and “clie= nt_id” are not.

 

And yes, I absolutely = agree that good examples are essential.  That’s high on my list = for the -01 version.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    Thanks a bunch,

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

 

From:= George Fletcher [mailto:gffletch@aol.com]
Sent: Monday, January 11, 2016 10:21 AM
To: Mike Jones <Mi= chael.Jones@microsoft.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

 

Thanks Mike. One question after rea= ding about the different attack vectors and this spec...

How are the 'iss' and 'aud' values returned with the 'code' and 'state' par= ameters. It seems the client needs to verify the endpoints before making th= e request to exchange the code for a token. If the client is using the defa= ult OAuth2 client_id and client_secret these values will be sent to the malicious endpoint if the client can't ve= rify the endpoints before hand.

Also, it would be nice to add some non-normative examples to the spec.

Thanks,
George

On 1/11/16 4:27 AM, Mike Jones wrote:

Yesterday Hannes Tschofenig announced an OAuth Security Advisory on Authorization Server Mix-Up.  This note= announces the publication of the strawman OAuth 2.0 Mix-Up Mitigation draf= t he mentioned that mitigates the attacks covered in the advisory.  Th= e abstract of the specification is:

 

This specification define= s an extension to The OAuth 2.0 Authorization Framework that enables an aut= horization server to provide a client using it with a consistent set of met= adata about itself. This information is returned in the authorization response. It can be used by the client to= prevent classes of attacks in which the client might otherwise be tricked = into using inconsistent sets of metadata from multiple authorization server= s, including potentially using a token endpoint that does not belong to the same authorization server as th= e authorization endpoint used. Recent research publications refer to these = as "IdP Mix-Up" and "Malicious Endpoint" attacks.<= /o:p>

 

The gist of the mitigation is having the authorizati= on server return the client ID and its issuer identifier (a value defined i= n the OAuth Discovery specification= ) so that the client can verify that it is using a consistent set of au= thorization server configuration information, that the client ID is for tha= t authorization server, and in particular, that the client is not being confused into sending information intended fo= r one authorization server to a different one.  Note that these attack= s can only be made against clients that are configured to use more than one= authorization server.

 

Please give the draft a quick read and provide feedb= ack to the OAuth working group.  This draft is very much a starting po= int intended to describe both the mitigations and the decisions and analysi= s remaining before we can be confident in standardizing a solution.  Please definitely read the Security Con= siderations and Open Issues sections, as they contain important information= about the choices made and the decisions remaining.

 

Special thanks go to Daniel Fett (University of Trie= r), Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-Uni= versity Bochum), and Guido Schmitz (University of Trier) for notifying us o= f the attacks and working with us both on understanding the attacks and on developing mitigations.  Tha= nks too to Hannes Tschofenig for organizing a meeting on this topic last mo= nth and to Torsten Lodderstedt and Deutsche Telekom for hosting the meeting= .

 

The specification is available at:

·       http://tools.ietf.org/html/draft-jones-oa= uth-mix-up-mitigation-00

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/draft= -jones-oauth-mix-up-mitigation-00.html

 

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

 

P.S.  This note was also posted at http://self-issued.info/?p=3D= 1524 and as @selfissued<= span style=3D"font-size:10.0pt">.





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




-- 
Chief Architect         &=
nbsp;         
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.          &n=
bsp;            =
;   AIM:  gffletch
Mobile: +1-703-462-3494       &=
nbsp;   Twitter: http://t=
witter.com/gffletch
Office: +1-703-265-2544       &=
nbsp;   Photos: htt=
p://georgefletcher.photography



-- 
Chief Architect         &=
nbsp;         
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.          &n=
bsp;            =
;   AIM:  gffletch
Mobile: +1-703-462-3494       &=
nbsp;   Twitter: http://t=
witter.com/gffletch
Office: +1-703-265-2544       &=
nbsp;   Photos: htt=
p://georgefletcher.photography
--_000_BY2PR03MB44280090C70D477698D3B7BF5C90BY2PR03MB442namprd_-- From nobody Mon Jan 11 12:34:17 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28011A910F for ; Mon, 11 Jan 2016 12:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrbXbwaFAu3H for ; Mon, 11 Jan 2016 12:34:13 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 DAB841A910E for ; Mon, 11 Jan 2016 12:34:12 -0800 (PST) Received: by mail-ob0-x236.google.com with SMTP id ba1so417770353obb.3 for ; Mon, 11 Jan 2016 12:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=4z0BIKLl2QXRasCKN0SeyPw7fr/ccPKFtX5ujRtmvtI=; b=Z/AarIIb1VjbV3T6JclrUK8X9MgtxvQxC2mAL9ZyFRhFEmHHSE1BBH5PK0DEUaEkrb cIQ8BIVEf5U1g9gh4bTqXES3MAOdBqRlvmWG2v5li60D6PvHt9vv/C4zZokGjUG89SVJ tCsK8nBVzvias/9+WYsYpxU5gkeJqfTIvoHOk= 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-type :content-transfer-encoding; bh=4z0BIKLl2QXRasCKN0SeyPw7fr/ccPKFtX5ujRtmvtI=; b=GYEeWRHXT6QMs3ysfx/MLdv8reRxluCoST5ewGIaENAEUPr2rs+x+qvTTKjigpZi61 182Y/G7V0VwFYsM/g9hPRz4xAOZjHSVFVKy3ZErhMC+kRNk9E8z7eVHMQoz71Zlt2gzP roeNZ5f7n2Hkq7aTvY4XkEI3WHUe0/U3lxmAE7UPj9DJ12PM5udRFlwFvy0uNkg1T46/ Q9RzQWhz+YUFcirePezRTkkbJ6bRlp/GG80sSOopUIKif4FyTdX6Zyb3FphJpd71dYHY A5YcrYSrRpAVXxeSK5JfD8zGPRCE5uzrx3e9bvnhITWdW3OFZj9SnS9LoFdGBx2mKFOy /9og== X-Gm-Message-State: ALoCoQlXNsAAWrBz8bz589PS1D5MrW/vEnRT3jKv44mxx2EFfxzx/Q1JtY5e+0swaKKzRLoZSfQdKwxc9qoj+SYoQPRjdn52TQ== X-Received: by 10.60.65.10 with SMTP id t10mr15956795oes.10.1452544451432; Mon, 11 Jan 2016 12:34:11 -0800 (PST) Received: from [10.1.2.108] ([205.169.68.218]) by smtp.gmail.com with ESMTPSA id mm4sm52306143obb.1.2016.01.11.12.34.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jan 2016 12:34:10 -0800 (PST) To: Mike Jones , George Fletcher , "oauth@ietf.org" References: <5693F276.8020501@aol.com> <56940CD8.8000701@aol.com> From: Hans Zandbelt Message-ID: <569411BF.5090500@pingidentity.com> Date: Mon, 11 Jan 2016 13:34:07 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 20:34:15 -0000 I disagree that validating endpoints "at this step" (which refers to right before making the token request) should be the default way of handling this. The vast majority of OAuth client deployments connecting to more than one AS will have a static configuration of the ASes issuer/endpoint information anyhow and they just need to confirm that the issuer value received in the authorization response is the same issuer as that the request was sent to. Hans. On 1/11/16 1:14 PM, Mike Jones wrote: > Correct > > *From:*George Fletcher [mailto:gffletch@aol.com] > *Sent:* Monday, January 11, 2016 12:13 PM > *To:* Mike Jones ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation > > So just to make sure I understand... > > This specification requires the response from the Authorization Server > to an successful /authorize call to pass back code=, state= and jwt= (?) > or individually iss= and aud= as URL parameters on the 302 to the > redirect_url. This way, before the client issues a call to the /token > endpoint (with the code), it can verify that the token endpoint is correct. > > If the client doesn't validate the endpoints at this step, then it could > disclose it's secret to a malicious endpoint. Correct? > > Thanks, > George > > On 1/11/16 2:59 PM, Mike Jones wrote: > > The alternatives for the code flow are to return them either in a > new JWT added to the reply containing them in the “iss” and “aud” > claims or to return them in new individual “client_id” and “iss” > authorization response parameters. Both alternatives are described > in the draft. I’m sure that we’ll now be having a good engineering > discussion on the tradeoffs between the alternatives., > > In a separate draft, John Bradley will shortly also be describing > the possibility of securing the “state” value using a “state_hash” > value that works in a way that’s similar to how “at_hash” and > “c_hash” secure the “access_token” and “code” values in Connect. > This would be an alternative means of binding the authorization > request and response to the session – accomplishing the same thing > that the Connect “nonce” does. > > While I fully get that some OAuth implementations want to avoid > having to have crypto, it seems like at least support for > cryptographic hashing (SHA-256, etc.) may be necessary to mitigate > some of these attacks (at least for clients that use more than one > authorization server). > > The other important engineering discussion I know we’re going to > have is whether, when an OAuth profile already returns the > information needed for the mitigation, whether we want to specify > that the client obtain it from the existing location, or whether to > also return it in a duplicate location. I’ll note that OpenID > Connect already returns the client ID and issuer for the flows that > return an ID Token in the authorization response, so this isn’t a > hypothetical question. > > Finally, I know that we’ll need to discuss the impact of > cut-and-paste attacks when the issuer and client ID are returned as > individual authorization response parameters that are not > cryptographically bound to the rest of the response. The > cut-and-paste attack that returning the issuer and client_id values > as separate parameters enables, even when state_hash or nonce is > used, is for the attacker to capture the legitimate response > containing “iss” and “client_id” results and substitute different > values for these fields, then post that altered response to the > legitimate client. The state and/or nonce values are protected > against substitution but “iss” and “client_id” are not. > > And yes, I absolutely agree that good examples are essential. > That’s high on my list for the -01 version. > > Thanks a > bunch, > > -- Mike > > *From:*George Fletcher [mailto:gffletch@aol.com] > *Sent:* Monday, January 11, 2016 10:21 AM > *To:* Mike Jones > ; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation > > Thanks Mike. One question after reading about the different attack > vectors and this spec... > > How are the 'iss' and 'aud' values returned with the 'code' and > 'state' parameters. It seems the client needs to verify the > endpoints before making the request to exchange the code for a > token. If the client is using the default OAuth2 client_id and > client_secret these values will be sent to the malicious endpoint if > the client can't verify the endpoints before hand. > > Also, it would be nice to add some non-normative examples to the spec. > > Thanks, > George > > On 1/11/16 4:27 AM, Mike Jones wrote: > > Yesterday Hannes Tschofenig announced an OAuth Security Advisory > on Authorization Server Mix-Up > . > This note announces the publication of the strawman OAuth 2.0 > Mix-Up Mitigation draft he mentioned that mitigates the attacks > covered in the advisory. The abstract of the specification is: > > This specification defines an extension to The OAuth 2.0 > Authorization Framework that enables an authorization server to > provide a client using it with a consistent set of metadata > about itself. This information is returned in the authorization > response. It can be used by the client to prevent classes of > attacks in which the client might otherwise be tricked into > using inconsistent sets of metadata from multiple authorization > servers, including potentially using a token endpoint that does > not belong to the same authorization server as the authorization > endpoint used. Recent research publications refer to these as > "IdP Mix-Up" and "Malicious Endpoint" attacks. > > The gist of the mitigation is having the authorization server > return the client ID and its issuer identifier (a value defined > in the OAuth Discovery specification > ) so that the client can verify > that it is using a consistent set of authorization server > configuration information, that the client ID is for that > authorization server, and in particular, that the client is not > being confused into sending information intended for one > authorization server to a different one. Note that these > attacks can only be made against clients that are configured to > use more than one authorization server. > > Please give the draft a quick read and provide feedback to the > OAuth working group. This draft is very much a starting point > intended to describe both the mitigations and the decisions and > analysis remaining before we can be confident in standardizing a > solution. Please definitely read the Security Considerations > and Open Issues sections, as they contain important information > about the choices made and the decisions remaining. > > Special thanks go to Daniel Fett (University of Trier), > Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov > (Ruhr-University Bochum), and Guido Schmitz (University of > Trier) for notifying us of the attacks and working with us both > on understanding the attacks and on developing mitigations. > Thanks too to Hannes Tschofenig for organizing a meeting on this > topic last month and to Torsten Lodderstedt and Deutsche Telekom > for hosting the meeting. > > The specification is available at: > > ·http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 > > An HTML-formatted version is also available at: > > ·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html > > -- Mike > > P.S. This note was also posted at > http://self-issued.info/?p=1524 and as @selfissued > . > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > Chief Architect > > Identity Services Engineering Work:george.fletcher@teamaol.com > > AOL Inc. AIM: gffletch > > Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch > > Office: +1-703-265-2544 Photos:http://georgefletcher.photography > > > > -- > > Chief Architect > > Identity Services Engineering Work:george.fletcher@teamaol.com > > AOL Inc. AIM: gffletch > > Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch > > Office: +1-703-265-2544 Photos:http://georgefletcher.photography > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Mon Jan 11 12:41:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205D81A9116 for ; Mon, 11 Jan 2016 12:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZu7QU7HEh_2 for ; Mon, 11 Jan 2016 12:41:15 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC831A9105 for ; Mon, 11 Jan 2016 12:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PpPGaUfX0FISi+Sv4D2BT0CDFamNujMfOPImgR6uHIc=; b=DO2ZSM4xwJeFg7lRS9aOuxyRPMGleCi23aBbnLG2GBbWBGkOw6FZzZac/+lmLebUlajfhJpprCI4d6tVhCTLw5/lact1eXibL5cKmoUw2rKzVzo3DV5wcLJgUdx/AUect80PBFRXNnYQ+GRMm7Z/ZQmciCvyuvmtCa8gIQseTSY= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 11 Jan 2016 20:40:53 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0361.006; Mon, 11 Jan 2016 20:40:53 +0000 From: Mike Jones To: Hans Zandbelt , George Fletcher , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation Thread-Index: AdFMSEdeh3slUb5fSSeAYII0TkfznQAVH34AAALUM/AAARo6AAAACUsAAACxt4AAABX4UA== Date: Mon, 11 Jan 2016 20:40:53 +0000 Message-ID: References: <5693F276.8020501@aol.com> <56940CD8.8000701@aol.com> <569411BF.5090500@pingidentity.com> In-Reply-To: <569411BF.5090500@pingidentity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [12.130.116.69] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:PWyNBKqjByzdcYzkn+VfT56GkOqkQLZVumKKEMBUCHzZFuq6sCQiLNUyfDXSYMBwlmZYvWMDwIoWzoJXni55CQ6+tsh9jKE42Snl++u2KukuhHSCRdR8Y+GCxP4L360jfZxzspq8eRDAamGG7+/vRQ==; 24:UsgK8bg7AzhtQuw5Q/4+Vn0XAah9wywZPIOzht6n2vNiLzOxzmZhcX4WXK7KT5WcYZXt2Kr8Ucc33Qe3CKLq+qs1kXcvLa1m304DZfkdzzk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-ms-office365-filtering-correlation-id: 5319a927-6c3c-4748-5d3a-08d31ac77ff2 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(149059832740258); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 0818724663 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(209900001)(24454002)(189002)(13464003)(199003)(377454003)(479174004)(164054003)(5004730100002)(1720100001)(5001960100002)(5003600100002)(81156007)(101416001)(11100500001)(15395725005)(6116002)(189998001)(122556002)(10400500002)(2950100001)(107886002)(50986999)(33656002)(19580395003)(86612001)(5005710100001)(97736004)(10290500002)(1220700001)(586003)(1096002)(2906002)(15975445007)(66066001)(5001770100001)(92566002)(3846002)(8990500004)(5002640100001)(77096005)(74316001)(76576001)(76176999)(54356999)(2900100001)(40100003)(93886004)(1600100001)(86362001)(2501003)(99286002)(105586002)(87936001)(106356001)(10090500001)(5008740100001)(19580405001)(102836003)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.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:23 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: 11 Jan 2016 20:40:53.3182 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2016 20:41:18 -0000 The specification describes this validation method (comparison of the issue= r received to the issuer recorded at registration time) in step 2 of Sectio= n 4 (Validating the Response). In fact, I added this in response to your f= eedback on an earlier draft, Hans. -----Original Message----- From: Hans Zandbelt [mailto:hzandbelt@pingidentity.com]=20 Sent: Monday, January 11, 2016 12:34 PM To: Mike Jones ; George Fletcher ; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation I disagree that validating endpoints "at this step" (which refers to right = before making the token request) should be the default way of handling this= . The vast majority of OAuth client deployments connecting to more than one= AS will have a static configuration of the ASes issuer/endpoint informatio= n anyhow and they just need to confirm that the issuer value received in th= e authorization response is the same issuer as that the request was sent to= . Hans. On 1/11/16 1:14 PM, Mike Jones wrote: > Correct > > *From:*George Fletcher [mailto:gffletch@aol.com] > *Sent:* Monday, January 11, 2016 12:13 PM > *To:* Mike Jones ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation > > So just to make sure I understand... > > This specification requires the response from the Authorization Server > to an successful /authorize call to pass back code=3D, state=3D and jwt= =3D (?) > or individually iss=3D and aud=3D as URL parameters on the 302 to the > redirect_url. This way, before the client issues a call to the /token > endpoint (with the code), it can verify that the token endpoint is correc= t. > > If the client doesn't validate the endpoints at this step, then it could > disclose it's secret to a malicious endpoint. Correct? > > Thanks, > George > > On 1/11/16 2:59 PM, Mike Jones wrote: > > The alternatives for the code flow are to return them either in a > new JWT added to the reply containing them in the "iss" and "aud" > claims or to return them in new individual "client_id" and "iss" > authorization response parameters. Both alternatives are described > in the draft. I'm sure that we'll now be having a good engineering > discussion on the tradeoffs between the alternatives., > > In a separate draft, John Bradley will shortly also be describing > the possibility of securing the "state" value using a "state_hash" > value that works in a way that's similar to how "at_hash" and > "c_hash" secure the "access_token" and "code" values in Connect. > This would be an alternative means of binding the authorization > request and response to the session - accomplishing the same thing > that the Connect "nonce" does. > > While I fully get that some OAuth implementations want to avoid > having to have crypto, it seems like at least support for > cryptographic hashing (SHA-256, etc.) may be necessary to mitigate > some of these attacks (at least for clients that use more than one > authorization server). > > The other important engineering discussion I know we're going to > have is whether, when an OAuth profile already returns the > information needed for the mitigation, whether we want to specify > that the client obtain it from the existing location, or whether to > also return it in a duplicate location. I'll note that OpenID > Connect already returns the client ID and issuer for the flows that > return an ID Token in the authorization response, so this isn't a > hypothetical question. > > Finally, I know that we'll need to discuss the impact of > cut-and-paste attacks when the issuer and client ID are returned as > individual authorization response parameters that are not > cryptographically bound to the rest of the response. The > cut-and-paste attack that returning the issuer and client_id values > as separate parameters enables, even when state_hash or nonce is > used, is for the attacker to capture the legitimate response > containing "iss" and "client_id" results and substitute different > values for these fields, then post that altered response to the > legitimate client. The state and/or nonce values are protected > against substitution but "iss" and "client_id" are not. > > And yes, I absolutely agree that good examples are essential. > That's high on my list for the -01 version. > > Thanks a > bunch, > > -- Mike > > *From:*George Fletcher [mailto:gffletch@aol.com] > *Sent:* Monday, January 11, 2016 10:21 AM > *To:* Mike Jones > ; oauth@ietf.org > > *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation > > Thanks Mike. One question after reading about the different attack > vectors and this spec... > > How are the 'iss' and 'aud' values returned with the 'code' and > 'state' parameters. It seems the client needs to verify the > endpoints before making the request to exchange the code for a > token. If the client is using the default OAuth2 client_id and > client_secret these values will be sent to the malicious endpoint if > the client can't verify the endpoints before hand. > > Also, it would be nice to add some non-normative examples to the spec= . > > Thanks, > George > > On 1/11/16 4:27 AM, Mike Jones wrote: > > Yesterday Hannes Tschofenig announced an OAuth Security Advisory > on Authorization Server Mix-Up > . > This note announces the publication of the strawman OAuth 2.0 > Mix-Up Mitigation draft he mentioned that mitigates the attacks > covered in the advisory. The abstract of the specification is: > > This specification defines an extension to The OAuth 2.0 > Authorization Framework that enables an authorization server to > provide a client using it with a consistent set of metadata > about itself. This information is returned in the authorization > response. It can be used by the client to prevent classes of > attacks in which the client might otherwise be tricked into > using inconsistent sets of metadata from multiple authorization > servers, including potentially using a token endpoint that does > not belong to the same authorization server as the authorization > endpoint used. Recent research publications refer to these as > "IdP Mix-Up" and "Malicious Endpoint" attacks. > > The gist of the mitigation is having the authorization server > return the client ID and its issuer identifier (a value defined > in the OAuth Discovery specification > ) so that the client can verif= y > that it is using a consistent set of authorization server > configuration information, that the client ID is for that > authorization server, and in particular, that the client is not > being confused into sending information intended for one > authorization server to a different one. Note that these > attacks can only be made against clients that are configured to > use more than one authorization server. > > Please give the draft a quick read and provide feedback to the > OAuth working group. This draft is very much a starting point > intended to describe both the mitigations and the decisions and > analysis remaining before we can be confident in standardizing a > solution. Please definitely read the Security Considerations > and Open Issues sections, as they contain important information > about the choices made and the decisions remaining. > > Special thanks go to Daniel Fett (University of Trier), > Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov > (Ruhr-University Bochum), and Guido Schmitz (University of > Trier) for notifying us of the attacks and working with us both > on understanding the attacks and on developing mitigations. > Thanks too to Hannes Tschofenig for organizing a meeting on this > topic last month and to Torsten Lodderstedt and Deutsche Telekom > for hosting the meeting. > > The specification is available at: > > *http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-0= 0 > > An HTML-formatted version is also available at: > > *http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation= -00.html > > -- Mik= e > > P.S. This note was also posted at > http://self-issued.info/?p=3D1524 and as @selfissued > . > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > > Chief Architect > > Identity Services Engineering Work:george.fletcher@teamaol.com > > AOL Inc. AIM: gffletch > > Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch > > Office: +1-703-265-2544 Photos:http://georgefletcher.photog= raphy > > > > -- > > Chief Architect > > Identity Services Engineering Work:george.fletcher@teamaol.com > > AOL Inc. AIM: gffletch > > Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch > > Office: +1-703-265-2544 Photos:http://georgefletcher.photograph= y > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Hans Zandbelt | Sr. Technical Architect hzandbelt@pingidentity.com | Ping Identity From nobody Mon Jan 11 22:45:01 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F451A002C for ; Mon, 11 Jan 2016 22:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIqqFeyrSIgb for ; Mon, 11 Jan 2016 22:44:55 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::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 028721A0025 for ; Mon, 11 Jan 2016 22:44:55 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id 65so57837949pff.2 for ; Mon, 11 Jan 2016 22:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=u6E1+r2KcEVdwr5kFM9yQBBYU3+FLJqT8pfhRGFo39k=; b=LkqK9hM2jILnSlg6AG+gSEdvgsaChBfvidUuE2l3gO7ThdqZCOygQ/1ViIyvceQdbR BHJCrX+/wQlN0bX7QuOO9irQs587EEgR7K/jO1nH99jiZkNc5y+NwUscMUfyosAuZkhd oR8g3iLE0NnsXA5Bq0CFKi6G6lxB5gMUrTHlAWcc4IxKWeAc/TJtfUOh63lb8QkhBGxX 1QicsSX1PbrfqFEWjXK6iXZSB+C0ekkzL65CCnxPx7YAtznEag6PWsYyKCoDdjV7Dosv dl1nxGSy3SN/38/AMm+cqILhJ5764Yb81+aphqW0SvSzYGPgfPWusLBJzauX37pkhXx9 79aA== X-Received: by 10.98.10.66 with SMTP id s63mr32435458pfi.119.1452581094660; Mon, 11 Jan 2016 22:44:54 -0800 (PST) Received: from tovan.intra.gree-office.net ([27.110.57.140]) by smtp.gmail.com with ESMTPSA id ty5sm13942008pac.48.2016.01.11.22.44.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jan 2016 22:44:53 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D30A8517-7AC9-43ED-BF78-966CCD7B5F8C" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: nov matake In-Reply-To: Date: Tue, 12 Jan 2016 15:44:50 +0900 Message-Id: <716CAB07-0512-4A58-9002-18BB05C7129B@gmail.com> References: <5693F276.8020501@aol.com> <56940CD8.8000701@aol.com> <569411BF.5090500@pingidentity.com> To: Mike Jones X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 06:44:59 -0000 --Apple-Mail=_D30A8517-7AC9-43ED-BF78-966CCD7B5F8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mike, Isn=E2=80=99t Nat=E2=80=99s "OAuth Response Metadata=E2=80=9D spec = enough to solve those issues? https://tools.ietf.org/id/draft-sakimura-oauth-meta-05.txt = > On Jan 12, 2016, at 05:40, Mike Jones = wrote: >=20 > The specification describes this validation method (comparison of the = issuer received to the issuer recorded at registration time) in step 2 = of Section 4 (Validating the Response). In fact, I added this in = response to your feedback on an earlier draft, Hans. >=20 > -----Original Message----- > From: Hans Zandbelt [mailto:hzandbelt@pingidentity.com = ]=20 > Sent: Monday, January 11, 2016 12:34 PM > To: Mike Jones >; George Fletcher >; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation >=20 > I disagree that validating endpoints "at this step" (which refers to = right before making the token request) should be the default way of = handling this. The vast majority of OAuth client deployments connecting = to more than one AS will have a static configuration of the ASes = issuer/endpoint information anyhow and they just need to confirm that = the issuer value received in the authorization response is the same = issuer as that the request was sent to. >=20 > Hans. >=20 > On 1/11/16 1:14 PM, Mike Jones wrote: >> Correct >>=20 >> *From:*George Fletcher [mailto:gffletch@aol.com] >> *Sent:* Monday, January 11, 2016 12:13 PM >> *To:* Mike Jones ; oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation >>=20 >> So just to make sure I understand... >>=20 >> This specification requires the response from the Authorization = Server >> to an successful /authorize call to pass back code=3D, state=3D and = jwt=3D (?) >> or individually iss=3D and aud=3D as URL parameters on the 302 to the >> redirect_url. This way, before the client issues a call to the /token >> endpoint (with the code), it can verify that the token endpoint is = correct. >>=20 >> If the client doesn't validate the endpoints at this step, then it = could >> disclose it's secret to a malicious endpoint. Correct? >>=20 >> Thanks, >> George >>=20 >> On 1/11/16 2:59 PM, Mike Jones wrote: >>=20 >> The alternatives for the code flow are to return them either in a >> new JWT added to the reply containing them in the "iss" and "aud" >> claims or to return them in new individual "client_id" and "iss" >> authorization response parameters. Both alternatives are = described >> in the draft. I'm sure that we'll now be having a good = engineering >> discussion on the tradeoffs between the alternatives., >>=20 >> In a separate draft, John Bradley will shortly also be describing >> the possibility of securing the "state" value using a "state_hash" >> value that works in a way that's similar to how "at_hash" and >> "c_hash" secure the "access_token" and "code" values in Connect. >> This would be an alternative means of binding the authorization >> request and response to the session - accomplishing the same thing >> that the Connect "nonce" does. >>=20 >> While I fully get that some OAuth implementations want to avoid >> having to have crypto, it seems like at least support for >> cryptographic hashing (SHA-256, etc.) may be necessary to mitigate >> some of these attacks (at least for clients that use more than one >> authorization server). >>=20 >> The other important engineering discussion I know we're going to >> have is whether, when an OAuth profile already returns the >> information needed for the mitigation, whether we want to specify >> that the client obtain it from the existing location, or whether = to >> also return it in a duplicate location. I'll note that OpenID >> Connect already returns the client ID and issuer for the flows = that >> return an ID Token in the authorization response, so this isn't a >> hypothetical question. >>=20 >> Finally, I know that we'll need to discuss the impact of >> cut-and-paste attacks when the issuer and client ID are returned = as >> individual authorization response parameters that are not >> cryptographically bound to the rest of the response. The >> cut-and-paste attack that returning the issuer and client_id = values >> as separate parameters enables, even when state_hash or nonce is >> used, is for the attacker to capture the legitimate response >> containing "iss" and "client_id" results and substitute different >> values for these fields, then post that altered response to the >> legitimate client. The state and/or nonce values are protected >> against substitution but "iss" and "client_id" are not. >>=20 >> And yes, I absolutely agree that good examples are essential. >> That's high on my list for the -01 version. >>=20 >> Thanks = a >> bunch, >>=20 >> -- Mike >>=20 >> *From:*George Fletcher [mailto:gffletch@aol.com] >> *Sent:* Monday, January 11, 2016 10:21 AM >> *To:* Mike Jones >> >; oauth@ietf.org = >> > >> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation >>=20 >> Thanks Mike. One question after reading about the different attack >> vectors and this spec... >>=20 >> How are the 'iss' and 'aud' values returned with the 'code' and >> 'state' parameters. It seems the client needs to verify the >> endpoints before making the request to exchange the code for a >> token. If the client is using the default OAuth2 client_id and >> client_secret these values will be sent to the malicious endpoint = if >> the client can't verify the endpoints before hand. >>=20 >> Also, it would be nice to add some non-normative examples to the = spec. >>=20 >> Thanks, >> George >>=20 >> On 1/11/16 4:27 AM, Mike Jones wrote: >>=20 >> Yesterday Hannes Tschofenig announced an OAuth Security = Advisory >> on Authorization Server Mix-Up >> = >= . >> This note announces the publication of the strawman OAuth 2.0 >> Mix-Up Mitigation draft he mentioned that mitigates the = attacks >> covered in the advisory. The abstract of the specification = is: >>=20 >> This specification defines an extension to The OAuth 2.0 >> Authorization Framework that enables an authorization server = to >> provide a client using it with a consistent set of metadata >> about itself. This information is returned in the = authorization >> response. It can be used by the client to prevent classes of >> attacks in which the client might otherwise be tricked into >> using inconsistent sets of metadata from multiple = authorization >> servers, including potentially using a token endpoint that = does >> not belong to the same authorization server as the = authorization >> endpoint used. Recent research publications refer to these as >> "IdP Mix-Up" and "Malicious Endpoint" attacks. >>=20 >> The gist of the mitigation is having the authorization server >> return the client ID and its issuer identifier (a value = defined >> in the OAuth Discovery specification >> >) so that the client can verify >> that it is using a consistent set of authorization server >> configuration information, that the client ID is for that >> authorization server, and in particular, that the client is = not >> being confused into sending information intended for one >> authorization server to a different one. Note that these >> attacks can only be made against clients that are configured = to >> use more than one authorization server. >>=20 >> Please give the draft a quick read and provide feedback to the >> OAuth working group. This draft is very much a starting point >> intended to describe both the mitigations and the decisions = and >> analysis remaining before we can be confident in standardizing = a >> solution. Please definitely read the Security Considerations >> and Open Issues sections, as they contain important = information >> about the choices made and the decisions remaining. >>=20 >> Special thanks go to Daniel Fett (University of Trier), >> Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov >> (Ruhr-University Bochum), and Guido Schmitz (University of >> Trier) for notifying us of the attacks and working with us = both >> on understanding the attacks and on developing mitigations. >> Thanks too to Hannes Tschofenig for organizing a meeting on = this >> topic last month and to Torsten Lodderstedt and Deutsche = Telekom >> for hosting the meeting. >>=20 >> The specification is available at: >>=20 >> = *http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 = >>=20 >> An HTML-formatted version is also available at: >>=20 >> = *http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html = = >>=20 >> -- = Mike >>=20 >> P.S. This note was also posted at >> http://self-issued.info/?p=3D1524 = and as @selfissued >> >. >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> OAuth mailing list >>=20 >> OAuth@ietf.org > >>=20 >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >>=20 >>=20 >> -- >>=20 >> Chief Architect >>=20 >> Identity Services Engineering Work:george.fletcher@teamaol.com = > >>=20 >> AOL Inc. AIM: gffletch >>=20 >> Mobile: +1-703-462-3494 = Twitter:http://twitter.com/gffletch >>=20 >> Office: +1-703-265-2544 = Photos:http://georgefletcher.photography = >>=20 >>=20 >>=20 >> -- >>=20 >> Chief Architect >>=20 >> Identity Services Engineering Work:george.fletcher@teamaol.com = > >>=20 >> AOL Inc. AIM: gffletch >>=20 >> Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch = >>=20 >> Office: +1-703-265-2544 = Photos:http://georgefletcher.photography = >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >=20 > --=20 > Hans Zandbelt | Sr. Technical Architect > hzandbelt@pingidentity.com | Ping = Identity >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_D30A8517-7AC9-43ED-BF78-966CCD7B5F8C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Mike,

Isn=E2=80=99t Nat=E2=80=99s "OAuth = Response Metadata=E2=80=9D spec enough to solve those issues?
https://tools.ietf.org/id/draft-sakimura-oauth-meta-05.txt<= div class=3D"">
On Jan 12, 2016, at 05:40, Mike Jones <Michael.Jones@microsoft.com> wrote:

The specification describes this validation = method (comparison of the issuer received to the issuer recorded at = registration time) in step 2 of Section 4 (Validating the Response). =  In fact, I added this in response to your feedback on an earlier = draft, Hans.

-----Original = Message-----
From: Hans Zandbelt [mailto:hzandbelt@pingidentity.com] 
Sent: Monday, January 11, = 2016 12:34 PM
To: Mike Jones <Michael.Jones@microsoft.com>; George Fletcher = <gffletch@aol.com>; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up = Mitigation

I disagree that validating = endpoints "at this step" (which refers to right before making the token = request) should be the default way of handling this. The vast majority = of OAuth client deployments connecting to more than one AS will have a = static configuration of the ASes issuer/endpoint information anyhow and = they just need to confirm that the issuer value received in the = authorization response is the same issuer as that the request was sent = to.

Hans.

On 1/11/16 1:14 PM, Mike Jones = wrote:
Correct

*From:*George Fletcher [mailto:gffletch@aol.com]
*Sent:* Monday, = January 11, 2016 12:13 PM
*To:* Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

So just to make sure I understand...

This specification requires the response from = the Authorization Server
to an successful /authorize call = to pass back code=3D, state=3D and jwt=3D (?)
or = individually iss=3D and aud=3D as URL parameters on the 302 to the
redirect_url. This way, before the client issues a call to = the /token
endpoint (with the code), it can verify that = the token endpoint is correct.

If the = client doesn't validate the endpoints at this step, then it could
disclose it's secret to a malicious endpoint. Correct?

Thanks,
George

On 1/11/16 2:59 PM, Mike Jones wrote:

   The alternatives for the code flow are to = return them either in a
   new JWT added to = the reply containing them in the "iss" and "aud"
   claims or to return them in new individual = "client_id" and "iss"
   authorization = response parameters.  Both alternatives are described
   in the draft.  I'm sure that we'll now = be having a good engineering
   discussion = on the tradeoffs between the alternatives.,

   In a separate draft, John Bradley will = shortly also be describing
   the = possibility of securing the "state" value using a "state_hash"
   value that works in a way that's similar to = how "at_hash" and
   "c_hash" secure the = "access_token" and "code" values in Connect.
   This would be an alternative means of = binding the authorization
   request and = response to the session - accomplishing the same thing
   that the Connect "nonce" does.

   While I fully get that some = OAuth implementations want to avoid
   having= to have crypto, it seems like at least support for
   cryptographic hashing (SHA-256, etc.) may = be necessary to mitigate
   some of these = attacks (at least for clients that use more than one
   authorization server).

   The other important engineering discussion = I know we're going to
   have is whether, = when an OAuth profile already returns the
   information needed for the mitigation, = whether we want to specify
   that the = client obtain it from the existing location, or whether to
   also return it in a duplicate location. =  I'll note that OpenID
   Connect = already returns the client ID and issuer for the flows that
   return an ID Token in the authorization = response, so this isn't a
   hypothetical = question.

   Finally, I know = that we'll need to discuss the impact of
   cut-and-paste attacks when the issuer and = client ID are returned as
   individual = authorization response parameters that are not
   cryptographically bound to the rest of the = response.  The
   cut-and-paste attack = that returning the issuer and client_id values
   as separate parameters enables, even when = state_hash or nonce is
   used, is for the = attacker to capture the legitimate response
   containing "iss" and "client_id" results = and substitute different
   values for = these fields, then post that altered response to the
   legitimate client.  The state and/or = nonce values are protected
   against = substitution but "iss" and "client_id" are not.

   And yes, I absolutely agree that good = examples are essential.
   That's high on = my list for the -01 version.

          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;  Thanks a
   bunch,

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

   *From:*George Fletcher [mailto:gffletch@aol.com]
   *Sent:* Monday, January 11, 2016 10:21 = AM
   *To:* Mike Jones <Michael.Jones@microsoft.com>
   <mailto:Michael.Jones@microsoft.com>; oauth@ietf.org
   <mailto:oauth@ietf.org>
   *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up = Mitigation

   Thanks Mike. = One question after reading about the different attack
   vectors and this spec...

   How are the 'iss' and 'aud' values returned = with the 'code' and
   'state' parameters. = It seems the client needs to verify the
   endpoints before making the request to = exchange the code for a
   token. If the = client is using the default OAuth2 client_id and
   client_secret these values will be sent to = the malicious endpoint if
   the client = can't verify the endpoints before hand.

   Also, it would be nice to add some = non-normative examples to the spec.

   Thanks,
   George

   On 1/11/16 4:27 AM, Mike Jones wrote:

       Yesterday Hannes = Tschofenig announced an OAuth Security Advisory
       on Authorization = Server Mix-Up
       <https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJh= PUm3Fr-w>.
       This note announces = the publication of the strawman OAuth 2.0
       Mix-Up Mitigation = draft he mentioned that mitigates the attacks
       covered in the = advisory.  The abstract of the specification is:

       This specification = defines an extension to The OAuth 2.0
       Authorization = Framework that enables an authorization server to
       provide a client = using it with a consistent set of metadata
       about itself. This = information is returned in the authorization
       response. It can be = used by the client to prevent classes of
       attacks in which = the client might otherwise be tricked into
       using inconsistent = sets of metadata from multiple authorization
       servers, including = potentially using a token endpoint that does
       not belong to the = same authorization server as the authorization
       endpoint used. = Recent research publications refer to these as
       "IdP Mix-Up" and = "Malicious Endpoint" attacks.

       The gist of the = mitigation is having the authorization server
       return the client = ID and its issuer identifier (a value defined
       in the OAuth = Discovery specification
       <http://self-issued.info/?p=3D1496>) so that the client = can verify
       that = it is using a consistent set of authorization server
       configuration = information, that the client ID is for that
       authorization = server, and in particular, that the client is not
       being confused into = sending information intended for one
       authorization = server to a different one.  Note that these
       attacks can only be = made against clients that are configured to
       use more than one = authorization server.

       Please give the = draft a quick read and provide feedback to the
       OAuth working = group.  This draft is very much a starting point
       intended to = describe both the mitigations and the decisions and
       analysis remaining = before we can be confident in standardizing a
       solution. =  Please definitely read the Security Considerations
       and Open Issues = sections, as they contain important information
       about the choices = made and the decisions remaining.

       Special thanks go = to Daniel Fett (University of Trier),
       Christian Mainka = (Ruhr-University Bochum), Vladislav Mladenov
       (Ruhr-University = Bochum), and Guido Schmitz (University of
       Trier) for = notifying us of the attacks and working with us both
       on understanding = the attacks and on developing mitigations.
       Thanks too to = Hannes Tschofenig for organizing a meeting on this
       topic last month = and to Torsten Lodderstedt and Deutsche Telekom
       for hosting the = meeting.

       The specification = is available at:

       *http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-= 00

       An HTML-formatted = version is also available at:

       *http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigatio= n-00.html

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

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





       _____________________= __________________________

       OAuth mailing = list

       OAuth@ietf.org <mailto:OAuth@ietf.org>
       https://www.ietf.org/mailman/listinfo/oauth




   --

   Chief Architect

   Identity Services Engineering =     Work:george.fletcher@teamaol.com <mailto:george.fletcher@teamaol.com>

   AOL Inc. =             &n= bsp;           &nbs= p;AIM:  gffletch

   Mobile: +1-703-462-3494 =           Twitter:http://twitter.com/gffletch

   Office: +1-703-265-2544 =           Photos:http://georgefletcher.photography



--

Chief Architect

Identity = Services Engineering     Work:george.fletcher@teamaol.com <mailto:george.fletcher@teamaol.com>

AOL Inc. =             &n= bsp;           &nbs= p;AIM:  gffletch

Mobile: = +1-703-462-3494 =           Twitter:http://twitter.com/gffletch

Office: +1-703-265-2544 =           Photos:http://georgefletcher.photography



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


-- 
Hans Zandbelt =             &n= bsp;| Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity

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

= --Apple-Mail=_D30A8517-7AC9-43ED-BF78-966CCD7B5F8C-- From nobody Tue Jan 12 07:53:12 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2171B2AD5 for ; Tue, 12 Jan 2016 07:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5LfwprVb0ZJ for ; Tue, 12 Jan 2016 07:53:09 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B18B61B2ACB for ; Tue, 12 Jan 2016 07:52:53 -0800 (PST) Received: from [192.168.10.141] ([83.65.147.98]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LzKyn-1a5jWs2sXh-014WK0 for ; Tue, 12 Jan 2016 16:52:51 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56952158.8020509@gmx.net> Date: Tue, 12 Jan 2016 16:52:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PJ6HfqFdS28J8x0iG5kCa5j9whJAkRGFB" X-Provags-ID: V03:K0:/0dRG8Pa9SisL88waA3LU89NsxmqIGLCnewK6s+eZUaAOzq8ejp 9GqxeXSB5JPVqq44Rz3+VprizMKZOVq1X+h52eJIbBJhJEIzrDVy7m0Pc+cu9R232oL9q48 VD5WFDMmDjfVC1nf+1/Bwvyzomb00EGGv4gHXmAXqhHPZIqvM7BbKpUy8Tv/WVCewlH7q9W SAWV5KN7IVLoNjpOcVDZw== X-UI-Out-Filterresults: notjunk:1;V01:K0:R0Pr8c+2Us4=:0UoRKKRF3dBqRN26bMzuNA rVw8E9ElkvO+WiNC47QqMa8/EBYx6a/A0stxaj0lKRaanZLWC31Hjx+V+a9oohSGLAp6TBlem +EFV2x3BApikPvP4OXe5wH1dlrWKp8Ar+HEcp8V/7pXSmkbBT6/Xd5dy8P0XBUihO/lv6cAsy RBduonrEOKoFmJQKBtgtSX1Z+/FmcqgyIIPp/DDfJN27GgDDKdtbtHd9MUowlfOZVRmSfy01B C/7LtfC8YTEAzFibv6Fg0+W8zbz5D7S+EILqNObumSu4ov9OTiyqThsAWG1cPKbl6WKLofHTu 5E5v9jkeq3JLxYqZeAY9zZloKno0EK8paemzwoGuufPsMaKqgihnVSmGwdsAAFspro+pGlSVh oMbQ0hfOmg/g8vPpe8AbNwVv6rASfRjcAL9hkDRdl+iFrgEuBhFlsybCFcKIqAVTFbpeihEuB Xj/pdIaPPU6E5W1wjeZ8IUHPrLNzKchs8/cpDdp1g6uvin54ULOFpLjWyb9RaL31xux3rdVsK fV4zWWefLK8AjPxKnbzeXLfNCYgXdxmyAavoWx3i/dCCuiXa3DAcNrD7qnmhGqulMGNxR/ukg aQI8X23M0nPo186Xp2lpCVIDD5frDNtbxKsDUIhmWL6aX8PoyOWjRv9dwPf1yOcqycgtbV4TK gsse1K0ofpH6uXIMMg9KDbKppithZLBhD+vI2NhYO3h9HP6DgL7PQKGDMJIa0yvKN+F8zbbxU ffte1dZd3I41Ml30mSVLILTTIfCy5fgEJkM2WqyJx7rYHSodbS4PWSgId3U= Archived-At: Subject: [OAUTH-WG] Mailing List for submitting OAuth Security and Vulnerability Reports X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 15:53:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PJ6HfqFdS28J8x0iG5kCa5j9whJAkRGFB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, you may have seen (from the announcement sent by the secretary) that we have requested the creation of a new mailing list, namely . We want to use this list as an "entry point" for others to submit vulnerability reports and other security problems related to OAuth. Because of the nature of such reports this list it is not public. You cannot subscribe to the list yourself. Instead, the OAuth working group chairs will invite experts to join this list and the number of persons on that list will be very small. We will put the information about the mailing list to the OAuth WG page and advertise it as widely as possible to reach out to security researchers and other security experts. Ciao Hannes & Derek --PJ6HfqFdS28J8x0iG5kCa5j9whJAkRGFB 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 iQEcBAEBCgAGBQJWlSFZAAoJEGhJURNOOiAtY6IH/0t3rl6sz7d0j6PS76vsz0Bw 1aHMJIKMTuF7MpzhtglLliP5ShT/nkzKGXDDdk83fSV9vNQHDJMFWKQFu3S7cKVK /8GM6KWhLbZwIbkMwFZBOIJwX+CI0ThjFX8GMw2SL6tKUAj7STsRwlCFt8JdkreF 8Uh+8+KUWqzGHCuAzWtJtCIHa/+oDMaJnIZ2kbyKCDBivPgS4dVe0bKQQCEqXXdW 2ttX8T4CIHGWNxdaW6Zy2FEBifRhphTh5rCH4ivLmBqI7wOgVsrGYRbkgEmfqTGQ RXIQGF4bXBhuFq8T9+H23MGybv6LskqymBMHljEp2OF6vERAz6vxZ7Oa6kDprqc= =9eP2 -----END PGP SIGNATURE----- --PJ6HfqFdS28J8x0iG5kCa5j9whJAkRGFB-- From nobody Tue Jan 12 08:08:31 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8BE1B2AF2 for ; Tue, 12 Jan 2016 08:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dcsja12bJcR7 for ; Tue, 12 Jan 2016 08:08:26 -0800 (PST) Received: from omr-a009e.mx.aol.com (omr-a009e.mx.aol.com [204.29.186.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46191B2ACE for ; Tue, 12 Jan 2016 08:08:25 -0800 (PST) Received: from mtaout-aah01.mx.aol.com (mtaout-aah01.mx.aol.com [172.27.1.141]) by omr-a009e.mx.aol.com (Outbound Mail Relay) with ESMTP id AC17D380029A; Tue, 12 Jan 2016 11:08:24 -0500 (EST) Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aah01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id EB62938000084; Tue, 12 Jan 2016 11:08:23 -0500 (EST) To: Hans Zandbelt , Mike Jones , "oauth@ietf.org" References: <5693F276.8020501@aol.com> <56940CD8.8000701@aol.com> <569411BF.5090500@pingidentity.com> From: George Fletcher Organization: AOL LLC Message-ID: <5695252B.109@aol.com> Date: Tue, 12 Jan 2016 11:09:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569411BF.5090500@pingidentity.com> Content-Type: multipart/alternative; boundary="------------070008020309050103020103" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1452614904; bh=Th0sdyIw0h5l1uMGHnZ8MwiZ27ieFMXXU3edBZwO/Hs=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=2T9RzgPkSFopE+S+53ykZm2pOzxmeNcW01A8OvULkXzsYrUuOBNvTKhTvxvRa78V8 sydPNFA05WhitK0j3j76rLVPyxE9PIVjOygMypUTZBwrBYk5oN1MdC6zQ99oLB7Ie4 p7wKaAIAoSyGEDM/PO7ET/qYx3/hJxEA21DY6Qs0= x-aol-sid: 3039ac1b018d569524f73e5e X-AOL-IP: 10.172.102.124 Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 16:08:30 -0000 This is a multi-part message in MIME format. --------------070008020309050103020103 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit If the endpoints are statically configured, does that in and of itself protect against most of the malicious endpoint attacks? There are other ways a client could protect against this malicious endpoint injection. However, I thought the point of the spec was to protect a client that truly supports any OP that is selected by a user of the app. In this case, the client doesn't have any pre-configured static endpoint values. I suppose that if the client knows which issuer (i.e. AS) it's using to try and authenticate the client, then an issuer compare is sufficient to protect the client and the user. So to avoid having to do an endpoint check at this point, the client must maintain which "issuer" (from discovery) it's using for the authentication. What was unclear to me from the spec is that the AS is required to add additional response parameters in the 302 response from the /authorize call. That will get clearer when the non-normative examples are added. I am curious as to how many Authorization Servers out there have endpoints that don't match the issuer domain. Checking this at discovery time seems simpler if possible. Thanks, George On 1/11/16 3:34 PM, Hans Zandbelt wrote: > I disagree that validating endpoints "at this step" (which refers to > right before making the token request) should be the default way of > handling this. The vast majority of OAuth client deployments > connecting to more than one AS will have a static configuration of the > ASes issuer/endpoint information anyhow and they just need to confirm > that the issuer value received in the authorization response is the > same issuer as that the request was sent to. > > Hans. > > On 1/11/16 1:14 PM, Mike Jones wrote: >> Correct >> >> *From:*George Fletcher [mailto:gffletch@aol.com] >> *Sent:* Monday, January 11, 2016 12:13 PM >> *To:* Mike Jones ; oauth@ietf.org >> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation >> >> So just to make sure I understand... >> >> This specification requires the response from the Authorization Server >> to an successful /authorize call to pass back code=, state= and jwt= (?) >> or individually iss= and aud= as URL parameters on the 302 to the >> redirect_url. This way, before the client issues a call to the /token >> endpoint (with the code), it can verify that the token endpoint is >> correct. >> >> If the client doesn't validate the endpoints at this step, then it could >> disclose it's secret to a malicious endpoint. Correct? >> >> Thanks, >> George >> >> On 1/11/16 2:59 PM, Mike Jones wrote: >> >> The alternatives for the code flow are to return them either in a >> new JWT added to the reply containing them in the “iss†and “aud†>> claims or to return them in new individual “client_id†and “iss†>> authorization response parameters. Both alternatives are described >> in the draft. I’m sure that we’ll now be having a good engineering >> discussion on the tradeoffs between the alternatives., >> >> In a separate draft, John Bradley will shortly also be describing >> the possibility of securing the “state†value using a “state_hash†>> value that works in a way that’s similar to how “at_hash†and >> “c_hash†secure the “access_token†and “code†values in Connect. >> This would be an alternative means of binding the authorization >> request and response to the session – accomplishing the same thing >> that the Connect “nonce†does. >> >> While I fully get that some OAuth implementations want to avoid >> having to have crypto, it seems like at least support for >> cryptographic hashing (SHA-256, etc.) may be necessary to mitigate >> some of these attacks (at least for clients that use more than one >> authorization server). >> >> The other important engineering discussion I know we’re going to >> have is whether, when an OAuth profile already returns the >> information needed for the mitigation, whether we want to specify >> that the client obtain it from the existing location, or whether to >> also return it in a duplicate location. I’ll note that OpenID >> Connect already returns the client ID and issuer for the flows that >> return an ID Token in the authorization response, so this isn’t a >> hypothetical question. >> >> Finally, I know that we’ll need to discuss the impact of >> cut-and-paste attacks when the issuer and client ID are returned as >> individual authorization response parameters that are not >> cryptographically bound to the rest of the response. The >> cut-and-paste attack that returning the issuer and client_id values >> as separate parameters enables, even when state_hash or nonce is >> used, is for the attacker to capture the legitimate response >> containing “iss†and “client_id†results and substitute different >> values for these fields, then post that altered response to the >> legitimate client. The state and/or nonce values are protected >> against substitution but “iss†and “client_id†are not. >> >> And yes, I absolutely agree that good examples are essential. >> That’s high on my list for the -01 version. >> >> Thanks a >> bunch, >> >> -- Mike >> >> *From:*George Fletcher [mailto:gffletch@aol.com] >> *Sent:* Monday, January 11, 2016 10:21 AM >> *To:* Mike Jones >> ; oauth@ietf.org >> >> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation >> >> Thanks Mike. One question after reading about the different attack >> vectors and this spec... >> >> How are the 'iss' and 'aud' values returned with the 'code' and >> 'state' parameters. It seems the client needs to verify the >> endpoints before making the request to exchange the code for a >> token. If the client is using the default OAuth2 client_id and >> client_secret these values will be sent to the malicious endpoint if >> the client can't verify the endpoints before hand. >> >> Also, it would be nice to add some non-normative examples to the >> spec. >> >> Thanks, >> George >> >> On 1/11/16 4:27 AM, Mike Jones wrote: >> >> Yesterday Hannes Tschofenig announced an OAuth Security Advisory >> on Authorization Server Mix-Up >> . >> This note announces the publication of the strawman OAuth 2.0 >> Mix-Up Mitigation draft he mentioned that mitigates the attacks >> covered in the advisory. The abstract of the specification is: >> >> This specification defines an extension to The OAuth 2.0 >> Authorization Framework that enables an authorization server to >> provide a client using it with a consistent set of metadata >> about itself. This information is returned in the authorization >> response. It can be used by the client to prevent classes of >> attacks in which the client might otherwise be tricked into >> using inconsistent sets of metadata from multiple authorization >> servers, including potentially using a token endpoint that does >> not belong to the same authorization server as the authorization >> endpoint used. Recent research publications refer to these as >> "IdP Mix-Up" and "Malicious Endpoint" attacks. >> >> The gist of the mitigation is having the authorization server >> return the client ID and its issuer identifier (a value defined >> in the OAuth Discovery specification >> ) so that the client can verify >> that it is using a consistent set of authorization server >> configuration information, that the client ID is for that >> authorization server, and in particular, that the client is not >> being confused into sending information intended for one >> authorization server to a different one. Note that these >> attacks can only be made against clients that are configured to >> use more than one authorization server. >> >> Please give the draft a quick read and provide feedback to the >> OAuth working group. This draft is very much a starting point >> intended to describe both the mitigations and the decisions and >> analysis remaining before we can be confident in standardizing a >> solution. Please definitely read the Security Considerations >> and Open Issues sections, as they contain important information >> about the choices made and the decisions remaining. >> >> Special thanks go to Daniel Fett (University of Trier), >> Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov >> (Ruhr-University Bochum), and Guido Schmitz (University of >> Trier) for notifying us of the attacks and working with us both >> on understanding the attacks and on developing mitigations. >> Thanks too to Hannes Tschofenig for organizing a meeting on this >> topic last month and to Torsten Lodderstedt and Deutsche Telekom >> for hosting the meeting. >> >> The specification is available at: >> >> ·http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 >> >> An HTML-formatted version is also available at: >> >> ·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html >> >> -- Mike >> >> P.S. This note was also posted at >> http://self-issued.info/?p=1524 and as @selfissued >> . >> >> >> >> >> >> _______________________________________________ >> >> OAuth mailing list >> >> OAuth@ietf.org >> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> -- >> >> Chief Architect >> >> Identity Services Engineering Work:george.fletcher@teamaol.com >> >> >> AOL Inc. AIM: gffletch >> >> Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch >> >> Office: +1-703-265-2544 Photos:http://georgefletcher.photography >> >> >> >> -- >> >> Chief Architect >> >> Identity Services Engineering Work:george.fletcher@teamaol.com >> >> >> AOL Inc. AIM: gffletch >> >> Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch >> >> Office: +1-703-265-2544 Photos:http://georgefletcher.photography >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > -- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography --------------070008020309050103020103 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit If the endpoints are statically configured, does that in and of itself protect against most of the malicious endpoint attacks? There are other ways a client could protect against this malicious endpoint injection. However, I thought the point of the spec was to protect a client that truly supports any OP that is selected by a user of the app. In this case, the client doesn't have any pre-configured static endpoint values.

I suppose that if the client knows which issuer (i.e. AS) it's using to try and authenticate the client, then an issuer compare is sufficient to protect the client and the user. So to avoid having to do an endpoint check at this point, the client must maintain which "issuer" (from discovery) it's using for the authentication.

What was unclear to me from the spec is that the AS is required to add additional response parameters in the 302 response from the /authorize call. That will get clearer when the non-normative examples are added.

I am curious as to how many Authorization Servers out there have endpoints that don't match the issuer domain. Checking this at discovery time seems simpler if possible.

Thanks,
George

On 1/11/16 3:34 PM, Hans Zandbelt wrote:
I disagree that validating endpoints "at this step" (which refers to right before making the token request) should be the default way of handling this. The vast majority of OAuth client deployments connecting to more than one AS will have a static configuration of the ASes issuer/endpoint information anyhow and they just need to confirm that the issuer value received in the authorization response is the same issuer as that the request was sent to.

Hans.

On 1/11/16 1:14 PM, Mike Jones wrote:
Correct

*From:*George Fletcher [mailto:gffletch@aol.com]
*Sent:* Monday, January 11, 2016 12:13 PM
*To:* Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

So just to make sure I understand...

This specification requires the response from the Authorization Server
to an successful /authorize call to pass back code=, state= and jwt= (?)
or individually iss= and aud= as URL parameters on the 302 to the
redirect_url. This way, before the client issues a call to the /token
endpoint (with the code), it can verify that the token endpoint is correct.

If the client doesn't validate the endpoints at this step, then it could
disclose it's secret to a malicious endpoint. Correct?

Thanks,
George

On 1/11/16 2:59 PM, Mike Jones wrote:

    The alternatives for the code flow are to return them either in a
    new JWT added to the reply containing them in the “iss†and “audâ€
    claims or to return them in new individual “client_id†and “issâ€
    authorization response parameters.  Both alternatives are described
    in the draft.  I’m sure that we’ll now be having a good engineering
    discussion on the tradeoffs between the alternatives.,

    In a separate draft, John Bradley will shortly also be describing
    the possibility of securing the “state†value using a “state_hashâ€
    value that works in a way that’s similar to how “at_hash†and
    “c_hash†secure the “access_token†and “code†values in Connect.
    This would be an alternative means of binding the authorization
    request and response to the session – accomplishing the same thing
    that the Connect “nonce†does.

    While I fully get that some OAuth implementations want to avoid
    having to have crypto, it seems like at least support for
    cryptographic hashing (SHA-256, etc.) may be necessary to mitigate
    some of these attacks (at least for clients that use more than one
    authorization server).

    The other important engineering discussion I know we’re going to
    have is whether, when an OAuth profile already returns the
    information needed for the mitigation, whether we want to specify
    that the client obtain it from the existing location, or whether to
    also return it in a duplicate location.  I’ll note that OpenID
    Connect already returns the client ID and issuer for the flows that
    return an ID Token in the authorization response, so this isn’t a
    hypothetical question.

    Finally, I know that we’ll need to discuss the impact of
    cut-and-paste attacks when the issuer and client ID are returned as
    individual authorization response parameters that are not
    cryptographically bound to the rest of the response.  The
    cut-and-paste attack that returning the issuer and client_id values
    as separate parameters enables, even when state_hash or nonce is
    used, is for the attacker to capture the legitimate response
    containing “iss†and “client_id†results and substitute different
    values for these fields, then post that altered response to the
    legitimate client.  The state and/or nonce values are protected
    against substitution but “iss†and “client_id†are not.

    And yes, I absolutely agree that good examples are essential.
    That’s high on my list for the -01 version.

                                                               Thanks a
    bunch,

                                                               -- Mike

    *From:*George Fletcher [mailto:gffletch@aol.com]
    *Sent:* Monday, January 11, 2016 10:21 AM
    *To:* Mike Jones <Michael.Jones@microsoft.com>
    <mailto:Michael.Jones@microsoft.com>; oauth@ietf.org
    <mailto:oauth@ietf.org>
    *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation

    Thanks Mike. One question after reading about the different attack
    vectors and this spec...

    How are the 'iss' and 'aud' values returned with the 'code' and
    'state' parameters. It seems the client needs to verify the
    endpoints before making the request to exchange the code for a
    token. If the client is using the default OAuth2 client_id and
    client_secret these values will be sent to the malicious endpoint if
    the client can't verify the endpoints before hand.

    Also, it would be nice to add some non-normative examples to the spec.

    Thanks,
    George

    On 1/11/16 4:27 AM, Mike Jones wrote:

        Yesterday Hannes Tschofenig announced an OAuth Security Advisory
        on Authorization Server Mix-Up
        <https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w>.
        This note announces the publication of the strawman OAuth 2.0
        Mix-Up Mitigation draft he mentioned that mitigates the attacks
        covered in the advisory.  The abstract of the specification is:

        This specification defines an extension to The OAuth 2.0
        Authorization Framework that enables an authorization server to
        provide a client using it with a consistent set of metadata
        about itself. This information is returned in the authorization
        response. It can be used by the client to prevent classes of
        attacks in which the client might otherwise be tricked into
        using inconsistent sets of metadata from multiple authorization
        servers, including potentially using a token endpoint that does
        not belong to the same authorization server as the authorization
        endpoint used. Recent research publications refer to these as
        "IdP Mix-Up" and "Malicious Endpoint" attacks.

        The gist of the mitigation is having the authorization server
        return the client ID and its issuer identifier (a value defined
        in the OAuth Discovery specification
        <http://self-issued.info/?p=1496>) so that the client can verify
        that it is using a consistent set of authorization server
        configuration information, that the client ID is for that
        authorization server, and in particular, that the client is not
        being confused into sending information intended for one
        authorization server to a different one.  Note that these
        attacks can only be made against clients that are configured to
        use more than one authorization server.

        Please give the draft a quick read and provide feedback to the
        OAuth working group.  This draft is very much a starting point
        intended to describe both the mitigations and the decisions and
        analysis remaining before we can be confident in standardizing a
        solution.  Please definitely read the Security Considerations
        and Open Issues sections, as they contain important information
        about the choices made and the decisions remaining.

        Special thanks go to Daniel Fett (University of Trier),
        Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov
        (Ruhr-University Bochum), and Guido Schmitz (University of
        Trier) for notifying us of the attacks and working with us both
        on understanding the attacks and on developing mitigations.
        Thanks too to Hannes Tschofenig for organizing a meeting on this
        topic last month and to Torsten Lodderstedt and Deutsche Telekom
        for hosting the meeting.

        The specification is available at:

        ·http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00

        An HTML-formatted version is also available at:

        ·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html

                                                                   -- Mike

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





        _______________________________________________

        OAuth mailing list

        OAuth@ietf.org <mailto:OAuth@ietf.org>

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




    --

    Chief Architect

    Identity Services Engineering     Work:george.fletcher@teamaol.com <mailto:george.fletcher@teamaol.com>

    AOL Inc.                          AIM:  gffletch

    Mobile: +1-703-462-3494           Twitter:http://twitter.com/gffletch

    Office: +1-703-265-2544           Photos:http://georgefletcher.photography



--

Chief Architect

Identity Services Engineering     Work:george.fletcher@teamaol.com <mailto:george.fletcher@teamaol.com>

AOL Inc.                          AIM:  gffletch

Mobile: +1-703-462-3494           Twitter:http://twitter.com/gffletch

Office: +1-703-265-2544           Photos:http://georgefletcher.photography



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



-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography
--------------070008020309050103020103-- From nobody Tue Jan 12 08:44:07 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7408A1B2B1C for ; Tue, 12 Jan 2016 08:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CQvlWEI0nr9 for ; Tue, 12 Jan 2016 08:44:04 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 91AAE1B2B1B for ; Tue, 12 Jan 2016 08:44:04 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id 65so65412605pff.2 for ; Tue, 12 Jan 2016 08:44:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yXRvyb0A1fbFFl6k4N/tnycIyP34ljrDj4MUg67q0lE=; b=bJZesN/ns0GMFIuZwNFYa1J4qCMKBBAzKLD8uvlCKQErqTzCvKqDf5aCX9MR73/y7v 5hoHaKvGa6qHw/03V83reHa0UPFhf+XTTxU+rnMXx4GDSEXYpmdnC2s6f1nZ+rJNZvjb TZuv0GJIfTmMFTDCW1jtg8cIpIalN+mjb+b8P4lzhQ6HxXla7z/jQJ23nnHgHdLOyTWX xuiausnhUxZrPu6haDruPrXuxA6ZwBDf7GDmRP3E1Miiair4GiczRm3rZVoE+/NcFwyc eLyMNuesPX+yg+6blGpH7x1i7kSF4is/IamPrpoRjTdb771Rf8aJNWkA39exTcixKZ4D ccfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yXRvyb0A1fbFFl6k4N/tnycIyP34ljrDj4MUg67q0lE=; b=EUQ58ewSj0Iwoif3Wn9L1/u2Y3MQzHs/XGClNYj1noKc+mIBxLwm1QeNvMjfhRZK+W 12UqlAEg+0AEerLI/48qe5CiOFvaBsaIaGpI8B/U26psMPP6pD2UakZLoySClIdlx1Ep t9xVJ7NXBm3fVXVSX7zPoMs5Cl9bJSKxLTzGhSGTnBVLleyEMdrQDsP/a4QXkjzrL9eE OGGWWqdtTZ3uvPLA+JphzwiNBB/ZbB8VPbnIOQjDqkAPI/z6Bh9N13GUfLYTUoqinVKw C9lAWgWbMyDsFRPQb2EkNfUzPPzYYwxnIH/uLZYvRLCr4BT2RIl+CBN0YcV8PH48cVTy 5kRA== X-Gm-Message-State: ALoCoQliAqyxJ/N1/rgVWPcDItjL5HbWpLBdakOgEEt3fUO8NrvIPexrmjxGJK8APD3XvHgKwgGzwseo892t8dPPlMuhD74j6g== X-Received: by 10.98.12.213 with SMTP id 82mr35113059pfm.116.1452617044176; Tue, 12 Jan 2016 08:44:04 -0800 (PST) Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com. [209.85.192.171]) by smtp.gmail.com with ESMTPSA id dg1sm194076176pad.18.2016.01.12.08.44.03 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jan 2016 08:44:03 -0800 (PST) Received: by mail-pf0-f171.google.com with SMTP id e65so65615667pfe.0 for ; Tue, 12 Jan 2016 08:44:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.98.0.212 with SMTP id 203mr11043021pfa.143.1452617043374; Tue, 12 Jan 2016 08:44:03 -0800 (PST) Received: by 10.66.50.69 with HTTP; Tue, 12 Jan 2016 08:44:03 -0800 (PST) In-Reply-To: <56952158.8020509@gmx.net> References: <56952158.8020509@gmx.net> Date: Tue, 12 Jan 2016 08:44:03 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Aaron Parecki To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11438c5cdd8135052925c259 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Mailing List for submitting OAuth Security and Vulnerability Reports X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 16:44:06 -0000 --001a11438c5cdd8135052925c259 Content-Type: text/plain; charset=UTF-8 If you send me a short sentence I can add a note on the oauth.net site with this information as well. ---- Aaron Parecki aaronparecki.com @aaronpk On Tue, Jan 12, 2016 at 7:52 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > you may have seen (from the announcement sent by the secretary) that we > have requested the creation of a new mailing list, namely > . We want to use this list as an > "entry point" for others to submit vulnerability reports and other > security problems related to OAuth. > > Because of the nature of such reports this list it is not public. > > You cannot subscribe to the list yourself. Instead, the OAuth working > group chairs will invite experts to join this list and the number of > persons on that list will be very small. > > We will put the information about the mailing list to the OAuth WG page > and advertise it as widely as possible to reach out to security > researchers and other security experts. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11438c5cdd8135052925c259 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you send me a short sentence I can add a note on the oauth.net site with this information as well= .

----
Aaron Parecki

On Tue, Jan 12, 2016 at 7:52 AM, Hannes Tsch= ofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

you may have seen (from the announcement sent by the secretary) that we
have requested the creation of a new mailing list, namely
<oauth-security-reports AT ietf.org>. We want to use this list as an
"entry point" for others to submit vulnerability reports and othe= r
security problems related to OAuth.

Because of the nature of such reports this list it is not public.

You cannot subscribe to the list yourself. Instead, the OAuth working
group chairs will invite experts to join this list and the number of
persons on that list will be very small.

We will put the information about the mailing list to the OAuth WG page
and advertise it as widely as possible to reach out to security
researchers and other security experts.

Ciao
Hannes & Derek


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


--001a11438c5cdd8135052925c259-- From nobody Tue Jan 12 14:24:38 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226941A8AC9 for ; Tue, 12 Jan 2016 14:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTg41psYrJkS for ; Tue, 12 Jan 2016 14:24:35 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001: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 4E49B1A066C for ; Tue, 12 Jan 2016 14:24:35 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id z14so154826073igp.0 for ; Tue, 12 Jan 2016 14:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to:content-type; bh=GNxUiaIcZ/k9YnLJ9VF0L9T+8hytsYVw9P4gW9nywUY=; b=kxhvJIbkfsXC1CdKtKNwyXfBSzCyGY5K+46fRe0F4DWKzbVa0OYY/YUJlKpQlrg2uZ qIG8H/JFJsuZ+fNFetLTwCGzcYPsifBgHsBjFmtJSkStqTTPQvTUW4WWN6YWLX/8+nDu LjslIHd1sp1J8Gzb9x4bgvztynpBXflUOxOyI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=GNxUiaIcZ/k9YnLJ9VF0L9T+8hytsYVw9P4gW9nywUY=; b=Qa7H4zcIiPQKj+OFYkkw1UQTibFA19fobO2i4kF0uIC1Dvdp3M03CoSQHP7CCFLWxA AIMSp3acE3dEDEwSUush2i6480DVVYojfXi7Xu6AsB5VuUV+YLccb8hpiYQL1oUwfd5H +9q8Sc1HIAwd20OGaCDEhq2Kcv6rXgyAjuRksm33QY99rUNpEA3JeSPLoPh+NtztN5WM AvQ1ifLxVSAZMDgqCjCJq4SlGcfb26dmA0j365JhyQxB2kE1quFVQbkN5+ya+GBhkJhl EfLkZcRqbjGDf3QKRUwONgc4+3siTj4guDftoGrsBkiU3sGK2FkEbbfF4jcYxd9PzpJe RTDw== X-Gm-Message-State: ALoCoQml+QRQtp+rnBr12l3+31Fuhd1pHlK6+B339otPHe7w8Nu2wx7MXk35MdtBBF1PgKzA0hyEl1+dPM4D6gDB9g9W06NFsuVLNuD0pUjJtqRhg6sXmWo= X-Received: by 10.50.142.73 with SMTP id ru9mr20561773igb.49.1452637474361; Tue, 12 Jan 2016 14:24:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.212.69 with HTTP; Tue, 12 Jan 2016 14:24:04 -0800 (PST) From: Brian Campbell Date: Tue, 12 Jan 2016 15:24:04 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a11c3db70a5b69905292a8441 Archived-At: Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 22:24:37 -0000 --001a11c3db70a5b69905292a8441 Content-Type: text/plain; charset=UTF-8 The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations on them) take advantage of the fact that there's nothing in the OAuth authorization response to the client's redirect_uri that identifies the authorization server. As a result, a variety of techniques can be used to trick the client into sending the code (or token in some cases) to the wrong endpoint. To the best of my recollection the general consensus coming out of the meetings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: Authorization Server Mix-Up ) was to put forth an I-D as a simple extension to OAuth, which described how to return an issuer identifier for the authorization server and client identifier as authorization response parameters from the authorization endpoint. Doing so enables the client to know which AS the response came from and thus avoid sending the code to a different AS. Also, it doesn't introduce application/message level cryptography requirements on client implementations. The mitigation draft that was posted yesterday diverges considerably from that with a significantly expanded scope that introduces OpenID Connect ID Tokens (sort of anyway) to regular OAuth and the retrieval of a metadata/discovery document in-between the authorization request and the access token request. It is possible that my recollection from Darmstadt is wrong. But I expect others who were there could corroborate my account of what transpired. Of course, the agreements out of the Darmstadt meeting were never intended to be the final word - the whole WG would have the opportunity to weigh, as is now the case. However, a goal of meeting face-to-face was to come away with a good consensus towards a proposed solution that could (hopefully) be implementable in the very near term and move thought the IETF process in an expedited manner. I believe we'd reached consensus but the content of -00 draft does not reflect it. I've made the plea off-list several times to simplify the draft to reflect the simple solution and now I'm doing the same on-list. Simplify the response validation to just say not to send the code/token back to an AS entity other that the one identified by the 'iss' in the response. And remove the id_token and JWT parts that . If this WG and/or the larger community believes that OAuth needs signed responses, let's develop a proper singed response mechanism. I don't know if it's needed or not but I do know that it's a decent chunk of work that should be conscientiously undertaken independent of what can and should be a simple to understand and implement fix for the idp mix-up problem. --001a11c3db70a5b69905292a8441 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The "IdP Mix-Up" and "Malicious E= ndpoint" attacks (as well as variations on them) take advantage of the= fact that there's nothing in the OAuth authorization response to the c= lient's redirect_uri that identifies the authorization server. As a res= ult, a variety of techniques can be used to trick the client into sending t= he code (or token in some cases) to the wrong endpoint.

T= o the best of my recollection the general consensus coming out of the meeti= ngs in Darmstadt (which Hannes mentioned in OAuth Security Adviso= ry: Authorization Server Mix-Up) was to put forth an I-D as a simple ex= tension to OAuth, which described how to return an issuer identifier for th= e authorization server and client identifier as authorization response para= meters from the authorization endpoint. Doing so enables the client to know= which AS the response came from and thus avoid sending the code to a diffe= rent AS. Also, it doesn't introduce application/message level cryptogra= phy requirements on client implementations.

The miti= gation draft that was posted yesterday diverges considerably from that = with a significantly expanded scope that introduces OpenID Connect ID Token= s (sort of anyway) to regular OAuth and the retrieval of a metadata/discove= ry document in-between the authorization request and the access token reque= st.

It is possible that my recollection from Darmstadt is= wrong. But I expect others who were there could corroborate my account of = what transpired. Of course, the agreements out of the Darmstadt meeting wer= e never intended to be the final word - the whole WG would have the opportu= nity to weigh, as is now the case. However, a goal of meeting face-to-face = was to come away with a good consensus towards a proposed solution that cou= ld (hopefully) be implementable in the very near term and move thought the = IETF process in an expedited manner. I believe we'd reached consensus b= ut the content of -00 draft does not reflect it.

I'v= e made the plea off-list several times to simplify the draft to reflect th= e simple solution and now I'm doing the same on-list. Simplify the resp= onse validation to just say not to send the code/token back to an AS entity= other that the one identified by the 'iss' in the response. And re= move the id_token and JWT parts that .

If this WG and/o= r the larger community believes that OAuth needs signed responses, let'= s develop a proper singed response mechanism. I don't know if it's needed or not but I do know that i= t's a decent chunk of work that should be conscientiously undertaken in= dependent of what can and should be a simple to understand=20 and implement fix for the idp mix-up problem.


--001a11c3db70a5b69905292a8441-- From nobody Tue Jan 12 14:53:48 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A4D1A8F4E for ; Tue, 12 Jan 2016 14:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AcFwDC_CpJh for ; Tue, 12 Jan 2016 14:53:43 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80DF1A8F4A for ; Tue, 12 Jan 2016 14:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+1S/p5fYOfDjQ6kn9BclLjXme1L5Bt+/c6K2K83LsQ4=; b=S+MT4pxZb7yfqz85MJDn72WymIqOCSpwKoahwtrePR/0Olt59pyfR2mDrJ0DW6UDfisPu3ldnfMRAQpVlnCvuE75hHRqkTSyQWcy/vtwqRUjtdmwgalExMTw/ufSme4B+qU0zoa4/eQepnwXWZg9afRJFVdKmS5ZT85VxforBC8= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 12 Jan 2016 22:53:24 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0361.006; Tue, 12 Jan 2016 22:53:24 +0000 From: Mike Jones To: Brian Campbell , oauth Thread-Topic: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation Thread-Index: AQHRTYgN3eg1UDGvE0eMvQSerFGJhJ74fQU/ Date: Tue, 12 Jan 2016 22:53:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [166.170.29.193] x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:kMuP41EycwxJ6f/mUOphauwkS+Auez8kIySH5/P1fx2zmM546dXnDov8Nfeuk84nBNXZao8FTn8MT83hg3ChojnvzmNpLEA+B2X9lt5/pk+8HhOmI1CFLIpK2NVjM/gdYN9lH6jFmkxJOlODzHa0vg==; 24:GWjcUKM7z2XvQeT5ewloiBnhbLanslpyuXDf0dcBdv3EVnmwgoDR1DsllynIN1SQ5bSTP3/YxFbdcRwJOI635gR8yTI+XIPu6SmVbqs6/Nc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441; x-ms-office365-filtering-correlation-id: 92db3428-2ec9-4514-fdd7-08d31ba32d57 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 081904387B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(377454003)(122556002)(105586002)(99286002)(33656002)(92566002)(189998001)(2906002)(2900100001)(16236675004)(74316001)(106116001)(6116002)(3846002)(106356001)(76576001)(102836003)(19617315012)(1220700001)(66066001)(1096002)(5004730100002)(2950100001)(97736004)(15975445007)(77096005)(5008740100001)(81156007)(101416001)(5001770100001)(11100500001)(10400500002)(19580405001)(107886002)(5001960100002)(10290500002)(586003)(50986999)(76176999)(54356999)(5002640100001)(5005710100001)(8990500004)(40100003)(5003600100002)(86612001)(19580395003)(86362001)(10090500001)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4423033D5604E9E36B20C23F5CA0BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2016 22:53:24.2638 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Subject: Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 22:53:47 -0000 --_000_BY2PR03MB4423033D5604E9E36B20C23F5CA0BY2PR03MB442namprd_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable John Bradley and I went over this today and I'm already planning on simplif= ying the draft along the lines described. I would have written this earlier= but I've been busy at a NIST meeting today. John has also stated writing a note about how cut-and-paste does and doesn'= t apply here but hasn't finished it yet because he's been similarly occupie= d. He's also started writing up the state_hash token request parameter, as= he agreed to do. Watch this space for the new draft... Best wishes, -- Mike ________________________________ From: Brian Campbell Sent: =FD1/=FD12/=FD2016 5:24 PM To: oauth Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations on= them) take advantage of the fact that there's nothing in the OAuth authori= zation response to the client's redirect_uri that identifies the authorizat= ion server. As a result, a variety of techniques can be used to trick the c= lient into sending the code (or token in some cases) to the wrong endpoint. To the best of my recollection the general consensus coming out of the meet= ings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: Autho= rization Server Mix-Up) was to put forth an I-D as a simple extension to OAut= h, which described how to return an issuer identifier for the authorization= server and client identifier as authorization response parameters from the= authorization endpoint. Doing so enables the client to know which AS the r= esponse came from and thus avoid sending the code to a different AS. Also, = it doesn't introduce application/message level cryptography requirements on= client implementations. The mitigation draft that was posted yesterday diverges considerably from that with= a significantly expanded scope that introduces OpenID Connect ID Tokens (s= ort of anyway) to regular OAuth and the retrieval of a metadata/discovery d= ocument in-between the authorization request and the access token request. It is possible that my recollection from Darmstadt is wrong. But I expect o= thers who were there could corroborate my account of what transpired. Of co= urse, the agreements out of the Darmstadt meeting were never intended to be= the final word - the whole WG would have the opportunity to weigh, as is n= ow the case. However, a goal of meeting face-to-face was to come away with = a good consensus towards a proposed solution that could (hopefully) be impl= ementable in the very near term and move thought the IETF process in an exp= edited manner. I believe we'd reached consensus but the content of -00 draf= t does not reflect it. I've made the plea off-list several times to simplify the draft to reflect = the simple solution and now I'm doing the same on-list. Simplify the respon= se validation to just say not to send the code/token back to an AS entity o= ther that the one identified by the 'iss' in the response. And remove the i= d_token and JWT parts that . If this WG and/or the larger community believes that OAuth needs signed res= ponses, let's develop a proper singed response mechanism. I don't know if i= t's needed or not but I do know that it's a decent chunk of work that shoul= d be conscientiously undertaken independent of what can and should be a sim= ple to understand and implement fix for the idp mix-up problem. --_000_BY2PR03MB4423033D5604E9E36B20C23F5CA0BY2PR03MB442namprd_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
John Bradley = and I went over this today and I'm already planning on simplifying the draf= t along the lines described. I would have written this earlier but I've bee= n busy at a NIST meeting today.

John has also stated writing a note about how cut-and-paste does and doesn'= t apply here but hasn't finished it yet because he's been similarly occupie= d.  He's also started writing up the state_hash token request paramete= r, as he agreed to do.

Watch this space for the new draft...

Best wishes,
-- Mike
From: Brian Campbell
Sent: =FD1/= =FD12/=FD2016 5:24 PM
To: oauth
Subject: [OAUT= H-WG] Mix-Up About The Mix-Up Mitigation

The "IdP Mix-Up" and "Malicious Endpoint" attacks = (as well as variations on them) take advantage of the fact that there's not= hing in the OAuth authorization response to the client's redirect_uri that = identifies the authorization server. As a result, a variety of techniques can be used to trick the client into sending the cod= e (or token in some cases) to the wrong endpoint.

To the best of my recollection the general consensus coming out of the= meetings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: Authorization Server Mix-Up) was to put forth = an I-D as a simple extension to OAuth, which described how to return an iss= uer identifier for the authorization server and client identifier as author= ization response parameters from the authorization endpoint. Doing so enables the client to know which AS t= he response came from and thus avoid sending the code to a different AS. Al= so, it doesn't introduce application/message level cryptography requirement= s on client implementations.

The mitigation draft that was posted yesterday diverges considerably= from that with a significantly expanded scope that introduces OpenID Conne= ct ID Tokens (sort of anyway) to regular OAuth and the retrieval of a metadata/discovery document in-between the au= thorization request and the access token request.

It is possible that my recollection from Darmstadt is wrong. But I exp= ect others who were there could corroborate my account of what transpired. = Of course, the agreements out of the Darmstadt meeting were never intended = to be the final word - the whole WG would have the opportunity to weigh, as is now the case. However, a goa= l of meeting face-to-face was to come away with a good consensus towards a = proposed solution that could (hopefully) be implementable in the very near = term and move thought the IETF process in an expedited manner. I believe we'd reached consensus but the content o= f -00 draft does not reflect it.

I've made the plea off-list several times to simplify the draft to ref= lect the simple solution and now I'm doing the same on-list. Simplify the r= esponse validation to just say not to send the code/token back to an AS ent= ity other that the one identified by the 'iss' in the response. And remove the id_token and JWT parts that .=

If this WG and/or the larger community believes that OAuth needs signe= d responses, let's develop a proper singed response mechanism. I don't know= if it's needed or not but I do know that it's a decent chunk of work that = should be conscientiously undertaken independent of what can and should be a simple to understand and implement= fix for the idp mix-up problem.



--_000_BY2PR03MB4423033D5604E9E36B20C23F5CA0BY2PR03MB442namprd_-- From nobody Tue Jan 12 20:03:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DB71B2CF3 for ; Tue, 12 Jan 2016 20:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozX-D4W9PsnJ for ; Tue, 12 Jan 2016 20:03:15 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500131B2CF1 for ; Tue, 12 Jan 2016 20:03:13 -0800 (PST) X-AuditID: 12074424-f79216d00000156e-0e-5695cc7f3e82 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id DA.8B.05486.F7CC5965; Tue, 12 Jan 2016 23:03:11 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u0D43A6e011583; Tue, 12 Jan 2016 23:03:11 -0500 Received: from [107.16.90.107] ([107.16.90.107]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u0D438Ae000482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jan 2016 23:03:09 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_2CC89D0D-8685-489C-89B0-1B1B31F83382" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Tue, 12 Jan 2016 23:03:08 -0500 Message-Id: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> References: To: Mike Jones X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixG6nrlt/ZmqYwYmNShar/99ktNg77ROL xcm3r9gcmD2WLPnJ5NG64y+7x92jF1kCmKO4bFJSczLLUov07RK4MtaueMlY8D+u4t3U1awN jJMCuhg5OSQETCQ2Xv7BCmGLSVy4t56ti5GLQ0hgMZPEicXn2CGcjYwSbVP7WCCctUwSXevO MYO0MAskSKx+vZsFxOYV0JN4desy2ChhASuJl3M+gtlsAqoS09e0MIHYnALREr/3PGIDsVmA 4o/OvWWCmBMr8an1DRPEHCuJBbtXg80UEpjPKDHtFC+ILSKgI/H44jc2iFNlJXb/fsQ0gVFg FpIzZiE5AyKuLbFs4WtmCFtTYn/3chZMcQ2Jzm8TWRcwsq1ilE3JrdLNTczMKU5N1i1OTszL Sy3SNdfLzSzRS00p3cQIjgMXlR2MzYeUDjEKcDAq8fB2zJoaJsSaWFZcmXuIUZKDSUmU9886 oBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3sJTQDnelMTKqtSifJiUNAeLkjjvt8opYUIC6Ykl qdmpqQWpRTBZGQ4OJQle7tNAjYJFqempFWmZOSUIaSYOTpDhPEDDH4HU8BYXJOYWZ6ZD5E8x KkqJ88qDJARAEhmleXC9oDSVLRCV/YpRHOgVYV57kCoeYIqD634FNJgJaLBF3GSQwSWJCCmp Bkamuc9Tg9q4C9W3s+ltPv3ypdy70tOR31zWPxY6fqh5A1+0qo/rVTblgj/pvI/YLiZqfRN4 evyuh/mU/e2TPjjkVc/9zH6zmXGi85HUYL8zhbn125/LJrybZKl0VPznZxOxU+b7nj+a8n/2 M+uJtrvmd016lHdiVnLi0QU569veb5JZzHehqiRYiaU4I9FQi7moOBEAsdOx4C4DAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 04:03:18 -0000 --Apple-Mail=_2CC89D0D-8685-489C-89B0-1B1B31F83382 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to Brian=E2=80=99s point, and points to Mike for promising to address = this. I wasn=E2=80=99t able to attend the meeting in Darmstadt, but = I=E2=80=99ve been following the discussion and original papers. Let=E2=80=99= s take this one piece at a time and not overreach with a solution. In particular, the whole =E2=80=9Clate binding discovery=E2=80=9D bit = would cause huge problems on its own. There=E2=80=99s good reason that = OpenID Connect mandates that the =E2=80=9Ciss=E2=80=9D value returned = from the discovery endpoint MUST be the same as the =E2=80=9Ciss=E2=80=9D = value coming back from the ID Token, so let=E2=80=99s not ignore that. =E2=80=94 Justin > On Jan 12, 2016, at 5:53 PM, Mike Jones = wrote: >=20 > John Bradley and I went over this today and I'm already planning on = simplifying the draft along the lines described. I would have written = this earlier but I've been busy at a NIST meeting today.=20 >=20 > John has also stated writing a note about how cut-and-paste does and = doesn't apply here but hasn't finished it yet because he's been = similarly occupied. He's also started writing up the state_hash token = request parameter, as he agreed to do. >=20 > Watch this space for the new draft... >=20 > Best wishes, > -- Mike > From: Brian Campbell > Sent: =E2=80=8E1/=E2=80=8E12/=E2=80=8E2016 5:24 PM > To: oauth > Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation >=20 > The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as = variations on them) take advantage of the fact that there's nothing in = the OAuth authorization response to the client's redirect_uri that = identifies the authorization server. As a result, a variety of = techniques can be used to trick the client into sending the code (or = token in some cases) to the wrong endpoint. >=20 > To the best of my recollection the general consensus coming out of the = meetings in Darmstadt (which Hannes mentioned in OAuth Security = Advisory: Authorization Server Mix-Up = )= was to put forth an I-D as a simple extension to OAuth, which described = how to return an issuer identifier for the authorization server and = client identifier as authorization response parameters from the = authorization endpoint. Doing so enables the client to know which AS the = response came from and thus avoid sending the code to a different AS. = Also, it doesn't introduce application/message level cryptography = requirements on client implementations.=20 >=20 > The mitigation draft that was posted yesterday = = diverges considerably from that with a significantly expanded scope that = introduces OpenID Connect ID Tokens (sort of anyway) to regular OAuth = and the retrieval of a metadata/discovery document in-between the = authorization request and the access token request.=20 >=20 > It is possible that my recollection from Darmstadt is wrong. But I = expect others who were there could corroborate my account of what = transpired. Of course, the agreements out of the Darmstadt meeting were = never intended to be the final word - the whole WG would have the = opportunity to weigh, as is now the case. However, a goal of meeting = face-to-face was to come away with a good consensus towards a proposed = solution that could (hopefully) be implementable in the very near term = and move thought the IETF process in an expedited manner. I believe we'd = reached consensus but the content of -00 draft does not reflect it.=20 >=20 > I've made the plea off-list several times to simplify the draft to = reflect the simple solution and now I'm doing the same on-list. Simplify = the response validation to just say not to send the code/token back to = an AS entity other that the one identified by the 'iss' in the response. = And remove the id_token and JWT parts that .=20 >=20 > If this WG and/or the larger community believes that OAuth needs = signed responses, let's develop a proper singed response mechanism. I = don't know if it's needed or not but I do know that it's a decent chunk = of work that should be conscientiously undertaken independent of what = can and should be a simple to understand and implement fix for the idp = mix-up problem. >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2CC89D0D-8685-489C-89B0-1B1B31F83382 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 to Brian=E2=80=99s point, and points to Mike for promising = to address this. I wasn=E2=80=99t able to attend the meeting in = Darmstadt, but I=E2=80=99ve been following the discussion and original = papers. Let=E2=80=99s take this one piece at a time and not overreach = with a solution.

In = particular, the whole =E2=80=9Clate binding discovery=E2=80=9D bit would = cause huge problems on its own. There=E2=80=99s good reason that OpenID = Connect mandates that the =E2=80=9Ciss=E2=80=9D value returned from the = discovery endpoint MUST be the same as the =E2=80=9Ciss=E2=80=9D value = coming back from the ID Token, so let=E2=80=99s not ignore = that.

 =E2=80=94 Justin

On = Jan 12, 2016, at 5:53 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

John Bradley and I went over this today and I'm already = planning on simplifying the draft along the lines described. I would = have written this earlier but I've been busy at a NIST meeting today.

John has also stated writing a note about how cut-and-paste does and = doesn't apply here but hasn't finished it yet because he's been = similarly occupied.  He's also started writing up the state_hash = token request parameter, as he agreed to do.

Watch this space for the new draft...

Best wishes,
-- Mike
From: Brian = Campbell
Sent: =E2=80=8E1/=E2=80=8E12/=E2=80=8E2016 5:24 PM
To: oauth
Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation

The "IdP Mix-Up" and "Malicious Endpoint" attacks (as = well as variations on them) take advantage of the fact that there's = nothing in the OAuth authorization response to the client's redirect_uri = that identifies the authorization server. As a result, a variety of techniques can be used to trick the client into sending the = code (or token in some cases) to the wrong endpoint.

To the best of my recollection the general consensus = coming out of the meetings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: Authorization Server Mix-Up) was to put = forth an I-D as a simple extension to OAuth, which described how to = return an issuer identifier for the authorization server and client = identifier as authorization response parameters from the authorization endpoint. Doing so enables the client to know which = AS the response came from and thus avoid sending the code to a different = AS. Also, it doesn't introduce application/message level cryptography = requirements on client implementations.

The mitigation draft that was posted yesterday diverges = considerably from that with a significantly expanded scope that = introduces OpenID Connect ID Tokens (sort of anyway) to regular OAuth and the retrieval of a metadata/discovery document in-between the = authorization request and the access token request.

It is possible that my recollection from Darmstadt is = wrong. But I expect others who were there could corroborate my account = of what transpired. Of course, the agreements out of the Darmstadt = meeting were never intended to be the final word - the whole WG would have the opportunity to weigh, as is now the case. However, a = goal of meeting face-to-face was to come away with a good consensus = towards a proposed solution that could (hopefully) be implementable in = the very near term and move thought the IETF process in an expedited manner. I believe we'd reached consensus but the = content of -00 draft does not reflect it.

I've made the plea off-list several times to simplify = the draft to reflect the simple solution and now I'm doing the same = on-list. Simplify the response validation to just say not to send the = code/token back to an AS entity other that the one identified by the 'iss' in the response. And remove the id_token and JWT parts = that .

If this WG and/or the larger community believes that = OAuth needs signed responses, let's develop a proper singed response = mechanism. I don't know if it's needed or not but I do know that it's a = decent chunk of work that should be conscientiously undertaken independent of what can and should be a simple to understand and = implement fix for the idp mix-up problem.



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

= --Apple-Mail=_2CC89D0D-8685-489C-89B0-1B1B31F83382-- From nobody Tue Jan 12 20:32:00 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474311B2D19 for ; Tue, 12 Jan 2016 20:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2xT-YaJj4mg for ; Tue, 12 Jan 2016 20:31:56 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9609C1B2D17 for ; Tue, 12 Jan 2016 20:31:56 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0D4VsZB018851 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2016 04:31:54 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u0D4VsK9023455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jan 2016 04:31:54 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u0D4VsNj021987; Wed, 13 Jan 2016 04:31:54 GMT Received: from [25.88.27.137] (/72.143.226.243) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Jan 2016 20:31:53 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-6490A3C0-9E63-4AA1-B305-CA0655D7C9D5 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13C75) In-Reply-To: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> Date: Tue, 12 Jan 2016 20:31:46 -0800 Content-Transfer-Encoding: 7bit Message-Id: <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> To: Justin Richer X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 04:31:59 -0000 --Apple-Mail-6490A3C0-9E63-4AA1-B305-CA0655D7C9D5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am in agreement with Brian.=20 I understand what Mike is trying to do is safer, but I too am concerned that= the escalation in knowledge/skills for oauth clients is significant.=20 This may not be the same concern as for OIDC where we can expect more sophis= tication.=20 Phil > On Jan 12, 2016, at 20:03, Justin Richer wrote: >=20 > +1 to Brian=E2=80=99s point, and points to Mike for promising to address t= his. I wasn=E2=80=99t able to attend the meeting in Darmstadt, but I=E2=80=99= ve been following the discussion and original papers. Let=E2=80=99s take thi= s one piece at a time and not overreach with a solution. >=20 > In particular, the whole =E2=80=9Clate binding discovery=E2=80=9D bit woul= d cause huge problems on its own. There=E2=80=99s good reason that OpenID Co= nnect mandates that the =E2=80=9Ciss=E2=80=9D value returned from the discov= ery endpoint MUST be the same as the =E2=80=9Ciss=E2=80=9D value coming back= from the ID Token, so let=E2=80=99s not ignore that. >=20 > =E2=80=94 Justin >=20 >> On Jan 12, 2016, at 5:53 PM, Mike Jones wro= te: >>=20 >> John Bradley and I went over this today and I'm already planning on simpl= ifying the draft along the lines described. I would have written this earlie= r but I've been busy at a NIST meeting today.=20 >>=20 >> John has also stated writing a note about how cut-and-paste does and does= n't apply here but hasn't finished it yet because he's been similarly occupi= ed. He's also started writing up the state_hash token request parameter, as= he agreed to do. >>=20 >> Watch this space for the new draft... >>=20 >> Best wishes, >> -- Mike >> From: Brian Campbell >> Sent: =E2=80=8E1/=E2=80=8E12/=E2=80=8E2016 5:24 PM >> To: oauth >> Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation >>=20 >> The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations o= n them) take advantage of the fact that there's nothing in the OAuth authori= zation response to the client's redirect_uri that identifies the authorizati= on server. As a result, a variety of techniques can be used to trick the cli= ent into sending the code (or token in some cases) to the wrong endpoint. >>=20 >> To the best of my recollection the general consensus coming out of the me= etings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: Auth= orization Server Mix-Up) was to put forth an I-D as a simple extension to OA= uth, which described how to return an issuer identifier for the authorizatio= n server and client identifier as authorization response parameters from the= authorization endpoint. Doing so enables the client to know which AS the re= sponse came from and thus avoid sending the code to a different AS. Also, it= doesn't introduce application/message level cryptography requirements on cl= ient implementations.=20 >>=20 >> The mitigation draft that was posted yesterday diverges considerably from= that with a significantly expanded scope that introduces OpenID Connect ID T= okens (sort of anyway) to regular OAuth and the retrieval of a metadata/disc= overy document in-between the authorization request and the access token req= uest.=20 >>=20 >> It is possible that my recollection from Darmstadt is wrong. But I expect= others who were there could corroborate my account of what transpired. Of c= ourse, the agreements out of the Darmstadt meeting were never intended to be= the final word - the whole WG would have the opportunity to weigh, as is no= w the case. However, a goal of meeting face-to-face was to come away with a g= ood consensus towards a proposed solution that could (hopefully) be implemen= table in the very near term and move thought the IETF process in an expedite= d manner. I believe we'd reached consensus but the content of -00 draft does= not reflect it.=20 >>=20 >> I've made the plea off-list several times to simplify the draft to reflec= t the simple solution and now I'm doing the same on-list. Simplify the respo= nse validation to just say not to send the code/token back to an AS entity o= ther that the one identified by the 'iss' in the response. And remove the id= _token and JWT parts that .=20 >>=20 >> If this WG and/or the larger community believes that OAuth needs signed r= esponses, let's develop a proper singed response mechanism. I don't know if i= t's needed or not but I do know that it's a decent chunk of work that should= be conscientiously undertaken independent of what can and should be a simpl= e to understand and implement fix for the idp mix-up problem. >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-6490A3C0-9E63-4AA1-B305-CA0655D7C9D5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I am in agreement with Brian. 

I= understand what Mike is trying to do is safer, but I too am concerned that t= he escalation in knowledge/skills for oauth clients is significant. 

T= his may not be the same concern as for OIDC where we can expect more sophist= ication. 

Phil

On= Jan 12, 2016, at 20:03, Justin Richer <jricher@mit.edu> wrote:

+1 t= o Brian=E2=80=99s point, and points to Mike for promising to address this. I= wasn=E2=80=99t able to attend the meeting in Darmstadt, but I=E2=80=99ve be= en following the discussion and original papers. Let=E2=80=99s take this one= piece at a time and not overreach with a solution.

In particular, the whole =E2=80=9Clate binding d= iscovery=E2=80=9D bit would cause huge problems on its own. There=E2=80=99s g= ood reason that OpenID Connect mandates that the =E2=80=9Ciss=E2=80=9D value= returned from the discovery endpoint MUST be the same as the =E2=80=9Ciss=E2= =80=9D value coming back from the ID Token, so let=E2=80=99s not ignore that= .

=  =E2=80=94 Justin

On Jan 12, 2016, at 5:53 PM, Mike Jo= nes <Michael.Jo= nes@microsoft.com> wrote:

Joh= n Bradley and I went over this today and I'm already planning on simplifying= the draft along the lines described. I would have written this earlier but I= 've been busy at a NIST meeting today.

John has also stated writing a note about how cut-and-paste does and doesn't= apply here but hasn't finished it yet because he's been similarly occupied.=   He's also started writing up the state_hash token request parameter, a= s he agreed to do.

Watch this space for the new draft...

Best wishes,
-- Mike
From: Brian Campbell
Sent: =E2=80=8E1/=E2=80=8E12/=E2=80=8E2016 5:24 PM
To: oauth
Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation

The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well a= s variations on them) take advantage of the fact that there's nothing in the= OAuth authorization response to the client's redirect_uri that identifies t= he authorization server. As a result, a variety of techniques can be used to trick the client into sending the code= (or token in some cases) to the wrong endpoint.

To the best of my recollection the general consensus coming o= ut of the meetings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: Authorization Server Mix-Up) was to put forth a= n I-D as a simple extension to OAuth, which described how to return an issue= r identifier for the authorization server and client identifier as authoriza= tion response parameters from the authorization endpoint. Doing so enables the client to know which AS th= e response came from and thus avoid sending the code to a different AS. Also= , it doesn't introduce application/message level cryptography requirements o= n client implementations.

The mitigation draft that was posted yesterday diverges con= siderably from that with a significantly expanded scope that introduces Open= ID Connect ID Tokens (sort of anyway) to regular OAuth and the retrieval of a metadata/discovery document in-between the aut= horization request and the access token request.

It is possible that my recollection from Darmstadt is wrong.= But I expect others who were there could corroborate my account of what tra= nspired. Of course, the agreements out of the Darmstadt meeting were never i= ntended to be the final word - the whole WG would have the opportunity to weigh, as is now the case. However, a goal= of meeting face-to-face was to come away with a good consensus towards a pr= oposed solution that could (hopefully) be implementable in the very near ter= m and move thought the IETF process in an expedited manner. I believe we'd reached consensus but the content of= -00 draft does not reflect it.

I've made the plea off-list several times to simplify the dr= aft to reflect the simple solution and now I'm doing the same on-list. Simpl= ify the response validation to just say not to send the code/token back to a= n AS entity other that the one identified by the 'iss' in the response. And remove the id_token and JWT parts that . <= br class=3D"">
If this WG and/or the larger community believes that OAuth n= eeds signed responses, let's develop a proper singed response mechanism. I d= on't know if it's needed or not but I do know that it's a decent chunk of wo= rk that should be conscientiously undertaken independent of what can and should be a simple to understand and implement f= ix for the idp mix-up problem.



_______________________________________________
OAuth mailing l= ist
OAuth@ietf.or= g
= https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
= OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
= --Apple-Mail-6490A3C0-9E63-4AA1-B305-CA0655D7C9D5-- From nobody Wed Jan 13 01:52:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11D61A0027 for ; Wed, 13 Jan 2016 01:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgKQ-dTfXL7f for ; Wed, 13 Jan 2016 01:52:41 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.28]) (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 2A0101A0020 for ; Wed, 13 Jan 2016 01:52:41 -0800 (PST) Received: from [80.67.16.121] (helo=webmail.df.eu) by smtprelay03.ispgateway.de with esmtpa (Exim 4.84) (envelope-from ) id 1aJI55-0001LK-Tq; Wed, 13 Jan 2016 10:51:07 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_9612a26c35054013f894bc18c21c286b" Date: Wed, 13 Jan 2016 10:52:38 +0100 From: torsten@lodderstedt.net To: "Phil Hunt (IDM)" In-Reply-To: <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> Message-ID: X-Sender: torsten@lodderstedt.net User-Agent: Roundcube Webmail X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 09:52:47 -0000 --=_9612a26c35054013f894bc18c21c286b Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 I fully agree with Brian. We came up with a rather simple (== w/o crypto) solution to mitigate the mix-up attack. We should first specify them as discussed and then have a discussion in the working group - also about additional attack vectors. As discussed in Darmstadt, we should also come up with a comprehensive description of the threats arising from the more dynamic way OAuth is used meanwhile. I hope the researches will support this effort. kind regards, Torsten. Am 13.01.2016 05:31, schrieb Phil Hunt (IDM): > I am in agreement with Brian. > > I understand what Mike is trying to do is safer, but I too am concerned that the escalation in knowledge/skills for oauth clients is significant. > > This may not be the same concern as for OIDC where we can expect more sophistication. > > Phil > > On Jan 12, 2016, at 20:03, Justin Richer wrote: > > +1 to Brian's point, and points to Mike for promising to address this. I wasn't able to attend the meeting in Darmstadt, but I've been following the discussion and original papers. Let's take this one piece at a time and not overreach with a solution. > > In particular, the whole "late binding discovery" bit would cause huge problems on its own. There's good reason that OpenID Connect mandates that the "iss" value returned from the discovery endpoint MUST be the same as the "iss" value coming back from the ID Token, so let's not ignore that. > > -- Justin > > On Jan 12, 2016, at 5:53 PM, Mike Jones wrote: > > John Bradley and I went over this today and I'm already planning on simplifying the draft along the lines described. I would have written this earlier but I've been busy at a NIST meeting today. > > John has also stated writing a note about how cut-and-paste does and doesn't apply here but hasn't finished it yet because he's been similarly occupied. He's also started writing up the state_hash token request parameter, as he agreed to do. > > Watch this space for the new draft... > > Best wishes, > -- Mike > > ------------------------- > From: Brian Campbell > Sent: ‎1/‎12/‎2016 5:24 PM > To: oauth > Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation > > The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations on them) take advantage of the fact that there's nothing in the OAuth authorization response to the client's redirect_uri that identifies the authorization server. As a result, a variety of techniques can be used to trick the client into sending the code (or token in some cases) to the wrong endpoint. > > To the best of my recollection the general consensus coming out of the meetings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: Authorization Server Mix-Up [1]) was to put forth an I-D as a simple extension to OAuth, which described how to return an issuer identifier for the authorization server and client identifier as authorization response parameters from the authorization endpoint. Doing so enables the client to know which AS the response came from and thus avoid sending the code to a different AS. Also, it doesn't introduce application/message level cryptography requirements on client implementations. The mitigation draft that was posted yesterday [2] diverges considerably from that with a significantly expanded scope that introduces OpenID Connect ID Tokens (sort of anyway) to regular OAuth and the retrieval of a metadata/discovery document in-between the authorization request and the access token request. > > It is possible that my recollection from Darmstadt is wrong. But I expect others who were there could corroborate my account of what transpired. Of course, the agreements out of the Darmstadt meeting were never intended to be the final word - the whole WG would have the opportunity to weigh, as is now the case. However, a goal of meeting face-to-face was to come away with a good consensus towards a proposed solution that could (hopefully) be implementable in the very near term and move thought the IETF process in an expedited manner. I believe we'd reached consensus but the content of -00 draft does not reflect it. > > I've made the plea off-list several times to simplify the draft to reflect the simple solution and now I'm doing the same on-list. Simplify the response validation to just say not to send the code/token back to an AS entity other that the one identified by the 'iss' in the response. And remove the id_token and JWT parts that . > > If this WG and/or the larger community believes that OAuth needs signed responses, let's develop a proper singed response mechanism. I don't know if it's needed or not but I do know that it's a decent chunk of work that should be conscientiously undertaken independent of what can and should be a simple to understand and implement fix for the idp mix-up problem. > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [3] > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth [3] _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth [3] Links: ------ [1] https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w [2] http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 [3] https://www.ietf.org/mailman/listinfo/oauth --=_9612a26c35054013f894bc18c21c286b Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

I fully agree with Brian. We came = up with a rather simple (=3D=3D w/o crypto) solution to mitigate the mix-up= attack. We should first specify them as discussed and then have a discussi= on in the working group - also about additional attack vectors.

As discussed in Darmstadt, we should also come up with a comprehensive d= escription of the threats arising from the more dynamic way OAuth is used m= eanwhile. I hope the researches will support this effort.

kind regards,
Torsten.

Am 13.01.2016 05:31, schrieb Phil Hunt (IDM):

I am in agreement with Brian. 
 
I understand what Mike is trying to do is sa= fer, but I too am concerned that the escalation in knowledge/skills for oau= th clients is significant. 
 
This may not be the same concern as for OIDC= where we can expect more sophistication. 

Phil

On Jan 12, 2016, at 20:03, Justin Richer <jricher@mit.edu> wrote:

+1 to Brian's point, and points to Mike for promising to address this= =2E I wasn't able to attend the meeting in Darmstadt, but I've been followi= ng the discussion and original papers. Let's take this one piece at a time = and not overreach with a solution.
 
In particular, the whole "late binding discovery" bit would cause huge= problems on its own. There's good reason that OpenID Connect mandates that= the "iss" value returned from the discovery endpoint MUST be the same as t= he "iss" value coming back from the ID Token, so let's not ignore that.
 
 — Justin

On Jan 12, 2016, at 5:53 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

John Bradl= ey and I went over this today and I'm already planning on simplifying the d= raft along the lines described. I would have written this earlier but I've = been busy at a NIST meeting today.

John has also stated writin= g a note about how cut-and-paste does and doesn't apply here but hasn't fin= ished it yet because he's been similarly occupied.  He's also started = writing up the state_hash token request parameter, as he agreed to do.

Watch this space for the new draft...

Best wishes,
-- Mike
From: Brian Campbell
Sent: ‎1/‎12/‎= 2016 5:24 PM
To: oaut= h
Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitig= ation

The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variatio= ns on them) take advantage of the fact that there's nothing in the OAuth au= thorization response to the client's redirect_uri that identifies the autho= rization server. As a result, a variety of techniques can be used to trick = the client into sending the code (or token in some cases) to the wrong endp= oint.

To the best of my recollection the general consensus coming out of the= meetings in Darmstadt (which Hannes mentioned in OAuth Security = Advisory: Authorization Server Mix-Up) was to put forth an I-D as a sim= ple extension to OAuth, which described how to return an issuer identifier = for the authorization server and client identifier as authorization respons= e parameters from the authorization endpoint. Doing so enables the client t= o know which AS the response came from and thus avoid sending the code to a= different AS. Also, it doesn't introduce application/message level cryptog= raphy requirements on client implementations.
The mitigation draft that was posted yesterday diverges considerably= from that with a significantly expanded scope that introduces OpenID Conne= ct ID Tokens (sort of anyway) to regular OAuth and the retrieval of a metad= ata/discovery document in-between the authorization request and the access = token request.

It is possible that my recollection from Darmstadt is wrong. But I exp= ect others who were there could corroborate my account of what transpired= =2E Of course, the agreements out of the Darmstadt meeting were never inten= ded to be the final word - the whole WG would have the opportunity to weigh= , as is now the case. However, a goal of meeting face-to-face was to come a= way with a good consensus towards a proposed solution that could (hopefully= ) be implementable in the very near term and move thought the IETF process = in an expedited manner. I believe we'd reached consensus but the content of= -00 draft does not reflect it.

I've made the plea off-list several times to simplify the draft to ref= lect the simple solution and now I'm doing the same on-list. Simplify the r= esponse validation to just say not to send the code/token back to an AS ent= ity other that the one identified by the 'iss' in the response. And remove = the id_token and JWT parts that .

If this WG and/or the larger community believes that OAuth needs signe= d responses, let's develop a proper singed response mechanism. I don't know= if it's needed or not but I do know that it's a decent chunk of work that = should be conscientiously undertaken independent of what can and should be = a simple to understand and implement fix for the idp mix-up problem.
 


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

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

 

 
--=_9612a26c35054013f894bc18c21c286b-- From nobody Wed Jan 13 05:55:38 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF76D1B2DC2 for ; Wed, 13 Jan 2016 05:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WOVGzjpceLy for ; Wed, 13 Jan 2016 05:55:35 -0800 (PST) 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 925401AD0C7 for ; Wed, 13 Jan 2016 05:55:35 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id g73so223615718ioe.3 for ; Wed, 13 Jan 2016 05:55:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zlpsxCZE4UKgmV/qxNOazhE5WJAVQkQbepWENwhWYuk=; b=CL+PTiQpKFZnMoD/EuwzujoAJaEQcvdbjR/3vHgSkmqR9h0MZrd5KXTfFdDjEOyWtt MQLdJKYg9xRge625D30oFOfkEIskWNPGw5GkR8jyItV6Q6zHUEAn/4zNY2Yj+in/yXEK GS2D9bRsz4F6akYOMJx9EwJsxiBq/llHOzHZg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zlpsxCZE4UKgmV/qxNOazhE5WJAVQkQbepWENwhWYuk=; b=LSZz5t71y2JsFZqXzNlGI61iSOJGH1LZ+Mn2/6XQyPcORpyBw4NbInxVKF4PcfY7G7 57FP5BG/PtD4OtKFFkstBe+z/lj9PrMLimFbZeqkHAjK5jyNumimjoF52SPMg+zu/Qgn l9ngluNeNqS6KIVAJIMq9bKtj/3WPlQy8yVHUS+euAYq5Sq4+O3N8i9FUFUxGVFtLDWS Wj2HNLKpoqlOOV8Xfv8ar5mry2a/5IM1nGWj8A+vBaoJiBWYf1bNkIxK/M6px82ZAB+g b9GKSYVSGBBj19OrDt6W7sibkJkbVeXRq25I0KfZhnCpFDzuA93I6T4ZY8JiiLW+29Ss rp7A== X-Gm-Message-State: ALoCoQn76uMQ/wRK6fDqu/Khh6JX4UTtU1a5KrL67O2bP4Eb05/S1HVYud+uwb47vQLVtDolHc/OwZXRLOukd+HEvOMqn2m3YmvrlPWigosRfrJoqAwz14M= X-Received: by 10.107.16.226 with SMTP id 95mr100205199ioq.147.1452693334988; Wed, 13 Jan 2016 05:55:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.212.69 with HTTP; Wed, 13 Jan 2016 05:55:05 -0800 (PST) In-Reply-To: References: From: Brian Campbell Date: Wed, 13 Jan 2016 06:55:05 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=001a113ecda03328ad05293786a3 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 13:55:37 -0000 --001a113ecda03328ad05293786a3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Mike (and reluctantly John, I guess). I'm pleased to hear about the direction things are taking and look forward to reviewing -01. On Tue, Jan 12, 2016 at 3:53 PM, Mike Jones wrote: > John Bradley and I went over this today and I'm already planning on > simplifying the draft along the lines described. I would have written thi= s > earlier but I've been busy at a NIST meeting today. > > John has also stated writing a note about how cut-and-paste does and > doesn't apply here but hasn't finished it yet because he's been similarly > occupied. He's also started writing up the state_hash token request > parameter, as he agreed to do. > > Watch this space for the new draft... > > Best wishes, > -- Mike > ------------------------------ > From: Brian Campbell > Sent: =E2=80=8E1/=E2=80=8E12/=E2=80=8E2016 5:24 PM > To: oauth > Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation > > The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations > on them) take advantage of the fact that there's nothing in the OAuth > authorization response to the client's redirect_uri that identifies the > authorization server. As a result, a variety of techniques can be used to > trick the client into sending the code (or token in some cases) to the > wrong endpoint. > > To the best of my recollection the general consensus coming out of the > meetings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: > Authorization Server Mix-Up > = ) > was to put forth an I-D as a simple extension to OAuth, which described h= ow > to return an issuer identifier for the authorization server and client > identifier as authorization response parameters from the authorization > endpoint. Doing so enables the client to know which AS the response came > from and thus avoid sending the code to a different AS. Also, it doesn't > introduce application/message level cryptography requirements on client > implementations. > > The mitigation draft that was posted yesterday > > diverges considerably from that with a significantly expanded scope that > introduces OpenID Connect ID Tokens (sort of anyway) to regular OAuth and > the retrieval of a metadata/discovery document in-between the authorizati= on > request and the access token request. > > It is possible that my recollection from Darmstadt is wrong. But I expect > others who were there could corroborate my account of what transpired. Of > course, the agreements out of the Darmstadt meeting were never intended t= o > be the final word - the whole WG would have the opportunity to weigh, as = is > now the case. However, a goal of meeting face-to-face was to come away wi= th > a good consensus towards a proposed solution that could (hopefully) be > implementable in the very near term and move thought the IETF process in = an > expedited manner. I believe we'd reached consensus but the content of -00 > draft does not reflect it. > > I've made the plea off-list several times to simplify the draft to reflec= t > the simple solution and now I'm doing the same on-list. Simplify the > response validation to just say not to send the code/token back to an AS > entity other that the one identified by the 'iss' in the response. And > remove the id_token and JWT parts that . > > If this WG and/or the larger community believes that OAuth needs signed > responses, let's develop a proper singed response mechanism. I don't know > if it's needed or not but I do know that it's a decent chunk of work that > should be conscientiously undertaken independent of what can and should b= e > a simple to understand and implement fix for the idp mix-up problem. > > > > --001a113ecda03328ad05293786a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Mike (and reluctantly John, I guess). I'm pleas= ed to hear about the direction things are taking and look forward to review= ing -01.

On Tue, Jan 12, 2016 at 3:53 PM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:
John Bradley a= nd I went over this today and I'm already planning on simplifying the d= raft along the lines described. I would have written this earlier but I'= ;ve been busy at a NIST meeting today.

John has also stated writing a note about how cut-and-paste does and doesn&= #39;t apply here but hasn't finished it yet because he's been simil= arly occupied.=C2=A0 He's also started writing up the state_hash token = request parameter, as he agreed to do.

Watch this space for the new draft...

Best wishes,
-- Mike
From: Brian Campbell
Sent: =E2=80= =8E1/=E2=80=8E12/=E2=80=8E2016 5:24 PM
To: oauth
Subject: [OAUTH= -WG] Mix-Up About The Mix-Up Mitigation

The "IdP Mix-Up" and "Malicious Endpoint" attacks = (as well as variations on them) take advantage of the fact that there's= nothing in the OAuth authorization response to the client's redirect_u= ri that identifies the authorization server. As a result, a variety of techniques can be used to trick the client into sending the cod= e (or token in some cases) to the wrong endpoint.

To the best of my recollection the general consensus coming out of the= meetings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: Authorization Server Mix-Up) was to put forth = an I-D as a simple extension to OAuth, which described how to return an iss= uer identifier for the authorization server and client identifier as author= ization response parameters from the authorization endpoint. Doing so enables the client to know which AS t= he response came from and thus avoid sending the code to a different AS. Al= so, it doesn't introduce application/message level cryptography require= ments on client implementations.

The mitigation draft that was posted yesterday div= erges considerably from that with a significantly expanded scope that intro= duces OpenID Connect ID Tokens (sort of anyway) to regular OAuth and the retrieval of a metadata/discovery document in-between the au= thorization request and the access token request.

It is possible that my recollection from Darmstadt is wrong. But I exp= ect others who were there could corroborate my account of what transpired. = Of course, the agreements out of the Darmstadt meeting were never intended = to be the final word - the whole WG would have the opportunity to weigh, as is now the case. However, a goa= l of meeting face-to-face was to come away with a good consensus towards a = proposed solution that could (hopefully) be implementable in the very near = term and move thought the IETF process in an expedited manner. I believe we'd reached consensus but the conte= nt of -00 draft does not reflect it.

I've made the plea off-list several times to simplify the draft to= reflect the simple solution and now I'm doing the same on-list. Simpli= fy the response validation to just say not to send the code/token back to a= n AS entity other that the one identified by the 'iss' in the response. And remove the id_token and JWT part= s that .

If this WG and/or the larger community believes that OAuth needs signe= d responses, let's develop a proper singed response mechanism. I don= 9;t know if it's needed or not but I do know that it's a decent chu= nk of work that should be conscientiously undertaken independent of what can and should be a simple to understand and implement= fix for the idp mix-up problem.




--001a113ecda03328ad05293786a3-- From nobody Wed Jan 13 11:36:55 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF151B313E for ; Wed, 13 Jan 2016 11:36:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IJMgWL_bBoA for ; Wed, 13 Jan 2016 11:36:50 -0800 (PST) Received: from nm50-vm4.bullet.mail.bf1.yahoo.com (nm50-vm4.bullet.mail.bf1.yahoo.com [216.109.115.223]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 425951B313C for ; Wed, 13 Jan 2016 11:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1452713809; bh=G+0tP5J+xRlhEZ8SSgFfGiU8bfGkjMnv+bJu0jHBl+M=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=kPGW6LyK2jdvFwCurWE0gSLIp/C3uRuZsLcsN/y8GK2UdV/ozU/PHd8yNnCJr6cMRE0fY4uol02Aus/i6/mxbHYzA9sFzb7dd72239imN/Jo+RFAyvDhLx2dr0whbWI69gs9436EHm2g0gVswS3bZMHLjRzTTLZfdplu8FCS6dduUVbtRkhK6rxCt7unxslvaWEaUzbq6TCXmC/YytRwDLeN2Dy1t4TO5ZgBmOkzeNuxA1Xqet1vLwz2UWpNG/MbmRScBq5aje7GShCKEi0ElgpKEm1GK/2+jkckfd+jlNzI3uohaim0fAsZhfReI0A6b0mpSb7qYJsIA/PpDoHZXg== Received: from [66.196.81.170] by nm50.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jan 2016 19:36:49 -0000 Received: from [98.139.212.232] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 13 Jan 2016 19:36:49 -0000 Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP; 13 Jan 2016 19:36:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 340785.20769.bm@omp1041.mail.bf1.yahoo.com X-YMail-OSG: TqIpJSMVM1nMaEaKf_e1EV.WB8DhfoaVQTKhHDJOQhQVuchhpubF.XWygSAaKgU ehwb4bvxF.RLoPtSqpIeEdO__obzXQiJCaHDigdeUHCZx3LM023417BppfmbVdq96MQYw0vbbW5T O4q7i6t5zTitJsBmlVDoQjBZT2KNLSk7o1PVPuI5uRbnn88_kbqRO7bLeNc0ulSw2yuc1Prxzl_6 xaDVl4bbmmXmUDFeNuJxYc_bMppdsGAMLDXBxzRMx0_gRIqi1_MWg1YWv5lepxwm7oiiBC.JUw3P PRq1Roz2zol_9ZyWJ3IjYLY2bQ82Em422txP7zL3LqKTY0TUbHuf98vZUt3AsoXyRpiDTStyKFUF EbA0jyYkkwUOVgCTfLYRZsCugJ_u6gXegtb3B0WxzOXcoQ0pV.YimU2.Y4guBpYw3pUdL1d8wX8m 8WgMfAWzpSwzxkvAk2JU6Bk9mX5n1pE3LnH8ftAMG03GUhI21PBq6Ul7xjxYROWkZoZOE_WXN07B d6hIc7C5c2NFK_i3.LblLQI4cOl4CZPPHFteN Received: by 66.196.81.106; Wed, 13 Jan 2016 19:36:48 +0000 Date: Wed, 13 Jan 2016 19:36:48 +0000 (UTC) From: Bill Mills To: Justin Richer , Mike Jones Message-ID: <919228671.4963460.1452713808579.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4963459_453117845.1452713808568" Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 19:36:52 -0000 ------=_Part_4963459_453117845.1452713808568 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Maybe this has been covered elsewhere, but one can see the case where "iss"= in an example is set to "my_auth_server" and that cut/paste gets re-used. = =C2=A0 That's also possible even in the OpenID Discovery mechanism, it requ= ires the implementer to actually pick a unique value. =C2=A0It would be bet= ter if this were not dependent on by-hand configuration. -bill=20 On Tuesday, January 12, 2016 8:03 PM, Justin Richer w= rote: =20 +1 to Brian=E2=80=99s point, and points to Mike for promising to address t= his. I wasn=E2=80=99t able to attend the meeting in Darmstadt, but I=E2=80= =99ve been following the discussion and original papers. Let=E2=80=99s take= this one piece at a time and not overreach with a solution. In particular, the whole =E2=80=9Clate binding discovery=E2=80=9D bit would= cause huge problems on its own. There=E2=80=99s good reason that OpenID Co= nnect mandates that the =E2=80=9Ciss=E2=80=9D value returned from the disco= very endpoint MUST be the same as the =E2=80=9Ciss=E2=80=9D value coming ba= ck from the ID Token, so let=E2=80=99s not ignore that. =C2=A0=E2=80=94 Justin On Jan 12, 2016, at 5:53 PM, Mike Jones wrote= : John Bradley and I went over this today and I'm already planning on simplif= ying the draft along the lines described. I would have written this earlier= but I've been busy at a NIST meeting today. John has also stated writing a note about how cut-and-paste does and doesn'= t apply here but hasn't finished it yet because he's been similarly occupie= d.=C2=A0 He's also started writing up the state_hash token request paramete= r, as he agreed to do. Watch this space for the new draft... Best wishes, -- MikeFrom:Brian Campbell Sent:=E2=80=8E1/=E2=80=8E12/=E2=80=8E2016 5:24 PM To:oauth Subject:[OAUTH-WG] Mix-Up About The Mix-Up Mitigation The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as variations on= them) take advantage of the fact that there's nothing in the OAuth authori= zation response to the client's redirect_uri that identifies the authorizat= ion server. As a result, a variety of techniques can be used to trick the c= lient into sending the code (or token in some cases) to the wrong endpoint. To the best of my recollection the general consensus coming out of the meet= ings in Darmstadt (which Hannes mentioned inOAuth Security Advisory: Author= ization Server Mix-Up) was to put forth an I-D as a simple extension to OAu= th, which described how to return an issuer identifier for the authorizatio= n server and client identifier as authorization response parameters from th= e authorization endpoint. Doing so enables the client to know which AS the = response came from and thus avoid sending the code to a different AS. Also,= it doesn't introduce application/message level cryptography requirements o= n client implementations. The mitigation draft that was posted yesterday diverges considerably from t= hat with a significantly expanded scope that introduces OpenID Connect ID T= okens (sort of anyway) to regular OAuth and the retrieval of a metadata/dis= covery document in-between the authorization request and the access token r= equest. It is possible that my recollection from Darmstadt is wrong. But I expect o= thers who were there could corroborate my account of what transpired. Of co= urse, the agreements out of the Darmstadt meeting were never intended to be= the final word - the whole WG would have the opportunity to weigh, as is n= ow the case. However, a goal of meeting face-to-face was to come away with = a good consensus towards a proposed solution that could (hopefully) be impl= ementable in the very near term and move thought the IETF process in an exp= edited manner. I believe we'd reached consensus but the content of -00 draf= t does not reflect it. I've made the plea off-list several times to simplify the draft to reflect = the simple solution and now I'm doing the same on-list. Simplify the respon= se validation to just say not to send the code/token back to an AS entity o= ther that the one identified by the 'iss' in the response. And remove the i= d_token and JWT parts that .=20 If this WG and/or the larger community believes that OAuth needs signed res= ponses, let's develop a proper singed response mechanism. I don't know if i= t's needed or not but I do know that it's a decent chunk of work that shoul= d be conscientiously undertaken independent of what can and should be a sim= ple to understand and implement fix for the idp mix-up problem. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------=_Part_4963459_453117845.1452713808568 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Maybe this has bee= n covered elsewhere, but one can see the case where "iss" in an example is = set to "my_auth_server" and that cut/paste gets re-used.   That's also= possible even in the OpenID Discovery mechanism, it requires the implement= er to actually pick a unique value.  It would be better if this were n= ot dependent on by-hand configuration.

-bill


On Tuesday, January 12, 2016 8:03 PM, Justin Richer <jricher@mit.= edu> wrote:


+1 to Brian=E2=80=99s point, and points to Mik= e for promising to address this. I wasn=E2=80=99t able to attend the meetin= g in Darmstadt, but I=E2=80=99ve been following the discussion and original= papers. Let=E2=80=99s take this one piece at a time and not overreach with= a solution.

In particular, the whole =E2=80= =9Clate binding discovery=E2=80=9D bit would cause huge problems on its own= . There=E2=80=99s good reason that OpenID Connect mandates that the =E2=80= =9Ciss=E2=80=9D value returned from the discovery endpoint MUST be the same= as the =E2=80=9Ciss=E2=80=9D value coming back from the ID Token, so let= =E2=80=99s not ignore that.

 =E2=80=94 Justin
On Jan 12, 2016, at 5:53 P= M, Mike Jones <Michael.Jones@microsoft.com> wro= te:

John Bradley and I went over this today and I'm already plannin= g on simplifying the draft along the lines described. I would have written = this earlier but I've been busy at a NIST meeting today.

John has also stated writing a note about how cut-and-paste does and doesn'= t apply here but hasn't finished it yet because he's been similarly occupie= d.  He's also started writing up the state_hash token request paramete= r, as he agreed to do.

Watch this space for the new draft...

Best wishes,
-- Mike
From: Brian Campbell
Sent: =E2=80=8E1/=E2=80=8E12/=E2=80=8E2016 5:24 PM
To: oauth
Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation
The "IdP Mix-Up" and "Malicious Endpoint" atta= cks (as well as variations on them) take advantage of the fact that there's= nothing in the OAuth authorization response to the client's redirect_uri t= hat identifies the authorization server. As a result, a variety of techniques can be used to trick the client into sending the cod= e (or token in some cases) to the wrong endpoint.

To the best of my recollection the general con= sensus coming out of the meetings in Darmstadt (which Hannes mentioned in OAuth Security Advisory: Authorization Server Mix-Up) was to put forth = an I-D as a simple extension to OAuth, which described how to return an iss= uer identifier for the authorization server and client identifier as author= ization response parameters from the authorization endpoint. Doing so enables the client to know which AS t= he response came from and thus avoid sending the code to a different AS. Al= so, it doesn't introduce application/message level cryptography requirement= s on client implementations.

The mitigation draft that was posted yesterday diverges considerably = from that with a significantly expanded scope that introduces OpenID Connec= t ID Tokens (sort of anyway) to regular OAuth and the retrieval of a metadata/discovery document in-between the au= thorization request and the access token request.

It is possible that my recollection from Darms= tadt is wrong. But I expect others who were there could corroborate my acco= unt of what transpired. Of course, the agreements out of the Darmstadt meet= ing were never intended to be the final word - the whole WG would have the opportunity to weigh, as is now the case. However, a goa= l of meeting face-to-face was to come away with a good consensus towards a = proposed solution that could (hopefully) be implementable in the very near = term and move thought the IETF process in an expedited manner. I believe we'd reached consensus but the content o= f -00 draft does not reflect it.

I've made the plea off-list several times to s= implify the draft to reflect the simple solution and now I'm doing the same= on-list. Simplify the response validation to just say not to send the code= /token back to an AS entity other that the one identified by the 'iss' in the response. And remove the id_token and JWT parts that .=

If this WG and/or the larger community believe= s that OAuth needs signed responses, let's develop a proper singed response= mechanism. I don't know if it's needed or not but I do know that it's a de= cent chunk of work that should be conscientiously undertaken independent of what can and should be a simple to understand and implement= fix for the idp mix-up problem.



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


_______________________________________________OAuth mailing list
OAuth@ietf.or= g
https://www.ietf.org/mailman/listinfo= /oauth


------=_Part_4963459_453117845.1452713808568-- From nobody Thu Jan 14 04:14:22 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F1B1B33B3 for ; Thu, 14 Jan 2016 04:14:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWNh_sWdI9Zl for ; Thu, 14 Jan 2016 04:14:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0693.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::693]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029891B33B7 for ; Thu, 14 Jan 2016 04:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Sh68aSeEShw5jpwp+KxCPlg4r6aQvjPirbMNnaUNJcY=; b=E6AvBWaeYFyfD0OypuiHHopJJSe6/iKh+7KhD8srIvBI88f5PFMUOIVRtB8HwIQ3E5xIQFsIwMROvjUdITGYqxvMqVn0eFBxP4nR9Cz9SqAw6iI9VSf+ekMBom60EZPa6VwGsaqnq2M5DHKPVgT6pp2anXDMDjQbB384p66KBTo= Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1031.namprd02.prod.outlook.com (10.161.203.149) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 14 Jan 2016 12:13:52 +0000 Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) with mapi id 15.01.0365.023; Thu, 14 Jan 2016 12:13:53 +0000 From: Antonio Sanso To: "" Thread-Topic: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation Thread-Index: AQHRTYgJKmIKUbEOKEed37wXEqbUfp74fQUAgABWigCAAAgAAIACGtuA Date: Thu, 14 Jan 2016 12:13:52 +0000 Message-ID: References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> In-Reply-To: <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.104.215.11] x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1031; 5:A4J3k82JIJiXhq9Fl6WCXSSwD5N+N5zjxN3iXIJTDA87yJYDyMvtUr9Hc5Mn3g9uBLxvJYlmq/373zR236VQoaQKvDKANfdfMtqKn6LJX4c1HPXt7vDNRfp1qsDZyeIM1D0oDfjeetivRlgeGSbYXA==; 24:3yuon7+8nrkWn+nUxxiTwGJhxEqGIu4jOdkDuew1Y4SvZCiP6QdQtQ29bLAlAeiC0GofVeYXCr7K9P+eXBNs7l0yEO9N63DJLJ70sSCkwlc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1031; x-ms-office365-filtering-correlation-id: fb120e22-a3dd-4775-43e9-08d31cdc2b23 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BY1PR0201MB1031; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1031; x-forefront-prvs: 08213D42D3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(189002)(199003)(24454002)(377454003)(16236675004)(93886004)(101416001)(4326007)(19580405001)(586003)(54356999)(50986999)(36756003)(19617315012)(33656002)(40100003)(19580395003)(122556002)(10090500001)(2906002)(10400500002)(76176999)(81156007)(105586002)(189998001)(5001960100002)(97736004)(5002640100001)(2950100001)(1096002)(86362001)(106116001)(87936001)(110136002)(2900100001)(106356001)(99286002)(1220700001)(15975445007)(66066001)(3846002)(5004730100002)(6116002)(102836003)(82746002)(5008740100001)(92566002)(77096005)(83716003)(104396002)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1031; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A7FF6797CAA34E64B384A0EEB5442AD1adobecom_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2016 12:13:52.3673 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1031 Archived-At: Subject: Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 12:14:21 -0000 --_000_A7FF6797CAA34E64B384A0EEB5442AD1adobecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aGksDQoNCnNhbWUgaGVyZS4gSSBoYXZlIHRoZSBzYW1lIHJlY29sbGVjdGlvbiBvZiB0aGUgbWVl dGluZyBpbiBEYXJtc3RhZHQgYXMgQnJpYW4uIEkgZG8gYXBwcmVjaWF0ZSB0aGUgZHJhZnQgb2Yg TWlrZSAoa3Vkb3MgdG8gaGltKSBhbmQgaGlzIHdpbGwgdG8gc3RlZXIgdG93YXJkIHRoZSBjb25z ZW5zdXMuDQoNCnJlZ2FyZHMNCg0KYW50b25pbw0KDQpPbiBKYW4gMTMsIDIwMTYsIGF0IDU6MzEg QU0sIFBoaWwgSHVudCAoSURNKSA8cGhpbC5odW50QG9yYWNsZS5jb208bWFpbHRvOnBoaWwuaHVu dEBvcmFjbGUuY29tPj4gd3JvdGU6DQoNCkkgYW0gaW4gYWdyZWVtZW50IHdpdGggQnJpYW4uDQoN CkkgdW5kZXJzdGFuZCB3aGF0IE1pa2UgaXMgdHJ5aW5nIHRvIGRvIGlzIHNhZmVyLCBidXQgSSB0 b28gYW0gY29uY2VybmVkIHRoYXQgdGhlIGVzY2FsYXRpb24gaW4ga25vd2xlZGdlL3NraWxscyBm b3Igb2F1dGggY2xpZW50cyBpcyBzaWduaWZpY2FudC4NCg0KVGhpcyBtYXkgbm90IGJlIHRoZSBz YW1lIGNvbmNlcm4gYXMgZm9yIE9JREMgd2hlcmUgd2UgY2FuIGV4cGVjdCBtb3JlIHNvcGhpc3Rp Y2F0aW9uLg0KDQpQaGlsDQoNCk9uIEphbiAxMiwgMjAxNiwgYXQgMjA6MDMsIEp1c3RpbiBSaWNo ZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQoNCisx IHRvIEJyaWFu4oCZcyBwb2ludCwgYW5kIHBvaW50cyB0byBNaWtlIGZvciBwcm9taXNpbmcgdG8g YWRkcmVzcyB0aGlzLiBJIHdhc27igJl0IGFibGUgdG8gYXR0ZW5kIHRoZSBtZWV0aW5nIGluIERh cm1zdGFkdCwgYnV0IEnigJl2ZSBiZWVuIGZvbGxvd2luZyB0aGUgZGlzY3Vzc2lvbiBhbmQgb3Jp Z2luYWwgcGFwZXJzLiBMZXTigJlzIHRha2UgdGhpcyBvbmUgcGllY2UgYXQgYSB0aW1lIGFuZCBu b3Qgb3ZlcnJlYWNoIHdpdGggYSBzb2x1dGlvbi4NCg0KSW4gcGFydGljdWxhciwgdGhlIHdob2xl IOKAnGxhdGUgYmluZGluZyBkaXNjb3ZlcnnigJ0gYml0IHdvdWxkIGNhdXNlIGh1Z2UgcHJvYmxl bXMgb24gaXRzIG93bi4gVGhlcmXigJlzIGdvb2QgcmVhc29uIHRoYXQgT3BlbklEIENvbm5lY3Qg bWFuZGF0ZXMgdGhhdCB0aGUg4oCcaXNz4oCdIHZhbHVlIHJldHVybmVkIGZyb20gdGhlIGRpc2Nv dmVyeSBlbmRwb2ludCBNVVNUIGJlIHRoZSBzYW1lIGFzIHRoZSDigJxpc3PigJ0gdmFsdWUgY29t aW5nIGJhY2sgZnJvbSB0aGUgSUQgVG9rZW4sIHNvIGxldOKAmXMgbm90IGlnbm9yZSB0aGF0Lg0K DQog4oCUIEp1c3Rpbg0KDQpPbiBKYW4gMTIsIDIwMTYsIGF0IDU6NTMgUE0sIE1pa2UgSm9uZXMg PE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPj4gd3JvdGU6DQoNCkpvaG4gQnJhZGxleSBhbmQgSSB3ZW50IG92ZXIgdGhpcyB0b2Rh eSBhbmQgSSdtIGFscmVhZHkgcGxhbm5pbmcgb24gc2ltcGxpZnlpbmcgdGhlIGRyYWZ0IGFsb25n IHRoZSBsaW5lcyBkZXNjcmliZWQuIEkgd291bGQgaGF2ZSB3cml0dGVuIHRoaXMgZWFybGllciBi dXQgSSd2ZSBiZWVuIGJ1c3kgYXQgYSBOSVNUIG1lZXRpbmcgdG9kYXkuDQoNCkpvaG4gaGFzIGFs c28gc3RhdGVkIHdyaXRpbmcgYSBub3RlIGFib3V0IGhvdyBjdXQtYW5kLXBhc3RlIGRvZXMgYW5k IGRvZXNuJ3QgYXBwbHkgaGVyZSBidXQgaGFzbid0IGZpbmlzaGVkIGl0IHlldCBiZWNhdXNlIGhl J3MgYmVlbiBzaW1pbGFybHkgb2NjdXBpZWQuICBIZSdzIGFsc28gc3RhcnRlZCB3cml0aW5nIHVw IHRoZSBzdGF0ZV9oYXNoIHRva2VuIHJlcXVlc3QgcGFyYW1ldGVyLCBhcyBoZSBhZ3JlZWQgdG8g ZG8uDQoNCldhdGNoIHRoaXMgc3BhY2UgZm9yIHRoZSBuZXcgZHJhZnQuLi4NCg0KQmVzdCB3aXNo ZXMsDQotLSBNaWtlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogQnJp YW4gQ2FtcGJlbGw8bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPg0KU2VudDog4oCO MS/igI4xMi/igI4yMDE2IDU6MjQgUE0NClRvOiBvYXV0aDxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbT0FVVEgtV0ddIE1peC1VcCBBYm91dCBUaGUgTWl4LVVwIE1pdGlnYXRpb24N Cg0KVGhlICJJZFAgTWl4LVVwIiBhbmQgIk1hbGljaW91cyBFbmRwb2ludCIgYXR0YWNrcyAoYXMg d2VsbCBhcyB2YXJpYXRpb25zIG9uIHRoZW0pIHRha2UgYWR2YW50YWdlIG9mIHRoZSBmYWN0IHRo YXQgdGhlcmUncyBub3RoaW5nIGluIHRoZSBPQXV0aCBhdXRob3JpemF0aW9uIHJlc3BvbnNlIHRv IHRoZSBjbGllbnQncyByZWRpcmVjdF91cmkgdGhhdCBpZGVudGlmaWVzIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlci4gQXMgYSByZXN1bHQsIGEgdmFyaWV0eSBvZiB0ZWNobmlxdWVzIGNhbiBiZSB1 c2VkIHRvIHRyaWNrIHRoZSBjbGllbnQgaW50byBzZW5kaW5nIHRoZSBjb2RlIChvciB0b2tlbiBp biBzb21lIGNhc2VzKSB0byB0aGUgd3JvbmcgZW5kcG9pbnQuDQoNClRvIHRoZSBiZXN0IG9mIG15 IHJlY29sbGVjdGlvbiB0aGUgZ2VuZXJhbCBjb25zZW5zdXMgY29taW5nIG91dCBvZiB0aGUgbWVl dGluZ3MgaW4gRGFybXN0YWR0ICh3aGljaCBIYW5uZXMgbWVudGlvbmVkIGluIE9BdXRoIFNlY3Vy aXR5IEFkdmlzb3J5OiBBdXRob3JpemF0aW9uIFNlcnZlciBNaXgtVXA8aHR0cHM6Ly9tYWlsYXJj aGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9vYXV0aC9KSVZ4RkJHc0pCVnRtN2xqd0poUFVtM0ZyLXc+ KSB3YXMgdG8gcHV0IGZvcnRoIGFuIEktRCBhcyBhIHNpbXBsZSBleHRlbnNpb24gdG8gT0F1dGgs IHdoaWNoIGRlc2NyaWJlZCBob3cgdG8gcmV0dXJuIGFuIGlzc3VlciBpZGVudGlmaWVyIGZvciB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIGNsaWVudCBpZGVudGlmaWVyIGFzIGF1dGhvcml6 YXRpb24gcmVzcG9uc2UgcGFyYW1ldGVycyBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50 LiBEb2luZyBzbyBlbmFibGVzIHRoZSBjbGllbnQgdG8ga25vdyB3aGljaCBBUyB0aGUgcmVzcG9u c2UgY2FtZSBmcm9tIGFuZCB0aHVzIGF2b2lkIHNlbmRpbmcgdGhlIGNvZGUgdG8gYSBkaWZmZXJl bnQgQVMuIEFsc28sIGl0IGRvZXNuJ3QgaW50cm9kdWNlIGFwcGxpY2F0aW9uL21lc3NhZ2UgbGV2 ZWwgY3J5cHRvZ3JhcGh5IHJlcXVpcmVtZW50cyBvbiBjbGllbnQgaW1wbGVtZW50YXRpb25zLg0K DQpUaGUgbWl0aWdhdGlvbiBkcmFmdCB0aGF0IHdhcyBwb3N0ZWQgeWVzdGVyZGF5PGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLW1peC11cC1taXRpZ2F0aW9uLTAw PiBkaXZlcmdlcyBjb25zaWRlcmFibHkgZnJvbSB0aGF0IHdpdGggYSBzaWduaWZpY2FudGx5IGV4 cGFuZGVkIHNjb3BlIHRoYXQgaW50cm9kdWNlcyBPcGVuSUQgQ29ubmVjdCBJRCBUb2tlbnMgKHNv cnQgb2YgYW55d2F5KSB0byByZWd1bGFyIE9BdXRoIGFuZCB0aGUgcmV0cmlldmFsIG9mIGEgbWV0 YWRhdGEvZGlzY292ZXJ5IGRvY3VtZW50IGluLWJldHdlZW4gdGhlIGF1dGhvcml6YXRpb24gcmVx dWVzdCBhbmQgdGhlIGFjY2VzcyB0b2tlbiByZXF1ZXN0Lg0KDQpJdCBpcyBwb3NzaWJsZSB0aGF0 IG15IHJlY29sbGVjdGlvbiBmcm9tIERhcm1zdGFkdCBpcyB3cm9uZy4gQnV0IEkgZXhwZWN0IG90 aGVycyB3aG8gd2VyZSB0aGVyZSBjb3VsZCBjb3Jyb2JvcmF0ZSBteSBhY2NvdW50IG9mIHdoYXQg dHJhbnNwaXJlZC4gT2YgY291cnNlLCB0aGUgYWdyZWVtZW50cyBvdXQgb2YgdGhlIERhcm1zdGFk dCBtZWV0aW5nIHdlcmUgbmV2ZXIgaW50ZW5kZWQgdG8gYmUgdGhlIGZpbmFsIHdvcmQgLSB0aGUg d2hvbGUgV0cgd291bGQgaGF2ZSB0aGUgb3Bwb3J0dW5pdHkgdG8gd2VpZ2gsIGFzIGlzIG5vdyB0 aGUgY2FzZS4gSG93ZXZlciwgYSBnb2FsIG9mIG1lZXRpbmcgZmFjZS10by1mYWNlIHdhcyB0byBj b21lIGF3YXkgd2l0aCBhIGdvb2QgY29uc2Vuc3VzIHRvd2FyZHMgYSBwcm9wb3NlZCBzb2x1dGlv biB0aGF0IGNvdWxkIChob3BlZnVsbHkpIGJlIGltcGxlbWVudGFibGUgaW4gdGhlIHZlcnkgbmVh ciB0ZXJtIGFuZCBtb3ZlIHRob3VnaHQgdGhlIElFVEYgcHJvY2VzcyBpbiBhbiBleHBlZGl0ZWQg bWFubmVyLiBJIGJlbGlldmUgd2UnZCByZWFjaGVkIGNvbnNlbnN1cyBidXQgdGhlIGNvbnRlbnQg b2YgLTAwIGRyYWZ0IGRvZXMgbm90IHJlZmxlY3QgaXQuDQoNCkkndmUgbWFkZSB0aGUgcGxlYSBv ZmYtbGlzdCBzZXZlcmFsIHRpbWVzIHRvIHNpbXBsaWZ5IHRoZSBkcmFmdCB0byByZWZsZWN0IHRo ZSBzaW1wbGUgc29sdXRpb24gYW5kIG5vdyBJJ20gZG9pbmcgdGhlIHNhbWUgb24tbGlzdC4gU2lt cGxpZnkgdGhlIHJlc3BvbnNlIHZhbGlkYXRpb24gdG8ganVzdCBzYXkgbm90IHRvIHNlbmQgdGhl IGNvZGUvdG9rZW4gYmFjayB0byBhbiBBUyBlbnRpdHkgb3RoZXIgdGhhdCB0aGUgb25lIGlkZW50 aWZpZWQgYnkgdGhlICdpc3MnIGluIHRoZSByZXNwb25zZS4gQW5kIHJlbW92ZSB0aGUgaWRfdG9r ZW4gYW5kIEpXVCBwYXJ0cyB0aGF0IC4NCg0KSWYgdGhpcyBXRyBhbmQvb3IgdGhlIGxhcmdlciBj b21tdW5pdHkgYmVsaWV2ZXMgdGhhdCBPQXV0aCBuZWVkcyBzaWduZWQgcmVzcG9uc2VzLCBsZXQn cyBkZXZlbG9wIGEgcHJvcGVyIHNpbmdlZCByZXNwb25zZSBtZWNoYW5pc20uIEkgZG9uJ3Qga25v dyBpZiBpdCdzIG5lZWRlZCBvciBub3QgYnV0IEkgZG8ga25vdyB0aGF0IGl0J3MgYSBkZWNlbnQg Y2h1bmsgb2Ygd29yayB0aGF0IHNob3VsZCBiZSBjb25zY2llbnRpb3VzbHkgdW5kZXJ0YWtlbiBp bmRlcGVuZGVudCBvZiB3aGF0IGNhbiBhbmQgc2hvdWxkIGJlIGEgc2ltcGxlIHRvIHVuZGVyc3Rh bmQgYW5kIGltcGxlbWVudCBmaXggZm9yIHRoZSBpZHAgbWl4LXVwIHByb2JsZW0uDQoNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRo QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCg0K --_000_A7FF6797CAA34E64B384A0EEB5442AD1adobecom_ Content-Type: text/html; charset="utf-8" Content-ID: <9E500E0DF5C8624DADA3BBD4116A31D6@namprd02.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KaGksDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5z YW1lIGhlcmUuIEkgaGF2ZSB0aGUgc2FtZSByZWNvbGxlY3Rpb24gb2YgdGhlIG1lZXRpbmcgaW4g RGFybXN0YWR0IGFzIEJyaWFuLiBJIGRvIGFwcHJlY2lhdGUgdGhlIGRyYWZ0IG9mIE1pa2UgKGt1 ZG9zIHRvIGhpbSkgYW5kIGhpcyB3aWxsIHRvIHN0ZWVyIHRvd2FyZCB0aGUgY29uc2Vuc3VzLjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+cmVnYXJkczwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+YW50b25pbzwvZGl2Pg0KPGRpdj48YnI+DQo8ZGl2Pg0KPGRpdj5PbiBKYW4g MTMsIDIwMTYsIGF0IDU6MzEgQU0sIFBoaWwgSHVudCAoSURNKSAmbHQ7PGEgaHJlZj0ibWFpbHRv OnBoaWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9ImF1dG8iPg0KPGRpdj5JIGFtIGluIGFncmVlbWVu dCB3aXRoIEJyaWFuLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSB1bmRl cnN0YW5kIHdoYXQgTWlrZSBpcyB0cnlpbmcgdG8gZG8gaXMgc2FmZXIsIGJ1dCBJIHRvbyBhbSBj b25jZXJuZWQgdGhhdCB0aGUgZXNjYWxhdGlvbiBpbiBrbm93bGVkZ2Uvc2tpbGxzIGZvciBvYXV0 aCBjbGllbnRzIGlzIHNpZ25pZmljYW50LiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+VGhpcyBtYXkgbm90IGJlIHRoZSBzYW1lIGNvbmNlcm4gYXMgZm9yIE9JREMgd2hlcmUg d2UgY2FuIGV4cGVjdCBtb3JlIHNvcGhpc3RpY2F0aW9uLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+ DQpQaGlsPC9kaXY+DQo8ZGl2Pjxicj4NCk9uIEphbiAxMiwgMjAxNiwgYXQgMjA6MDMsIEp1c3Rp biBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiPmpyaWNoZXJAbWl0 LmVkdTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+JiM0MzsxIHRvIEJyaWFu4oCZcyBwb2ludCwgYW5kIHBvaW50cyB0byBNaWtlIGZvciBw cm9taXNpbmcgdG8gYWRkcmVzcyB0aGlzLiBJIHdhc27igJl0IGFibGUgdG8gYXR0ZW5kIHRoZSBt ZWV0aW5nIGluIERhcm1zdGFkdCwgYnV0IEnigJl2ZSBiZWVuIGZvbGxvd2luZyB0aGUgZGlzY3Vz c2lvbiBhbmQgb3JpZ2luYWwgcGFwZXJzLiBMZXTigJlzIHRha2UgdGhpcyBvbmUgcGllY2UgYXQg YSB0aW1lIGFuZCBub3Qgb3ZlcnJlYWNoDQogd2l0aCBhIHNvbHV0aW9uLg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4gcGFydGljdWxhciwgdGhl IHdob2xlIOKAnGxhdGUgYmluZGluZyBkaXNjb3ZlcnnigJ0gYml0IHdvdWxkIGNhdXNlIGh1Z2Ug cHJvYmxlbXMgb24gaXRzIG93bi4gVGhlcmXigJlzIGdvb2QgcmVhc29uIHRoYXQgT3BlbklEIENv bm5lY3QgbWFuZGF0ZXMgdGhhdCB0aGUg4oCcaXNz4oCdIHZhbHVlIHJldHVybmVkIGZyb20gdGhl IGRpc2NvdmVyeSBlbmRwb2ludCBNVVNUIGJlIHRoZSBzYW1lIGFzIHRoZSDigJxpc3PigJ0gdmFs dWUgY29taW5nIGJhY2sNCiBmcm9tIHRoZSBJRCBUb2tlbiwgc28gbGV04oCZcyBub3QgaWdub3Jl IHRoYXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A74oCUIEp1c3RpbjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEphbiAxMiwgMjAxNiwgYXQgNTo1MyBQTSwgTWlrZSBKb25l cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgY2xhc3M9 IiI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxtZXRh IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fu cy1zZXJpZjsgZm9udC1zaXplOjExcHQiIGNsYXNzPSIiPkpvaG4gQnJhZGxleSBhbmQgSSB3ZW50 IG92ZXIgdGhpcyB0b2RheSBhbmQgSSdtIGFscmVhZHkgcGxhbm5pbmcgb24gc2ltcGxpZnlpbmcg dGhlIGRyYWZ0IGFsb25nIHRoZSBsaW5lcyBkZXNjcmliZWQuIEkgd291bGQgaGF2ZSB3cml0dGVu IHRoaXMgZWFybGllciBidXQgSSd2ZSBiZWVuIGJ1c3kgYXQgYSBOSVNUIG1lZXRpbmcNCiB0b2Rh eS4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSm9obiBoYXMgYWxzbyBzdGF0ZWQgd3Jp dGluZyBhIG5vdGUgYWJvdXQgaG93IGN1dC1hbmQtcGFzdGUgZG9lcyBhbmQgZG9lc24ndCBhcHBs eSBoZXJlIGJ1dCBoYXNuJ3QgZmluaXNoZWQgaXQgeWV0IGJlY2F1c2UgaGUncyBiZWVuIHNpbWls YXJseSBvY2N1cGllZC4mbmJzcDsgSGUncyBhbHNvIHN0YXJ0ZWQgd3JpdGluZyB1cCB0aGUgc3Rh dGVfaGFzaCB0b2tlbiByZXF1ZXN0IHBhcmFtZXRlciwgYXMgaGUgYWdyZWVkIHRvIGRvLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldhdGNoIHRoaXMgc3BhY2UgZm9yIHRoZSBuZXcgZHJh ZnQuLi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCZXN0IHdpc2hlcyw8YnIgY2xhc3M9 IiI+DQotLSBNaWtlPC9kaXY+DQo8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGhy IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsg Zm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiIGNsYXNzPSIiPkZyb206DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjEx cHQiIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIg Y2xhc3M9IiI+QnJpYW4gQ2FtcGJlbGw8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBmb250 LXdlaWdodDpib2xkIiBjbGFzcz0iIj5TZW50Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0IiBjbGFzcz0iIj7igI4xL+KA jjEyL+KAjjIwMTYgNToyNCBQTTwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6 Ym9sZCIgY2xhc3M9IiI+VG86DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli cmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiIGNsYXNzPSIiPjxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyIgY2xhc3M9IiI+b2F1dGg8L2E+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0 OyBmb250LXdlaWdodDpib2xkIiBjbGFzcz0iIj5TdWJqZWN0Og0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0IiBjbGFzcz0i Ij5bT0FVVEgtV0ddIE1peC1VcCBBYm91dCBUaGUgTWl4LVVwIE1pdGlnYXRpb248L3NwYW4+PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBk aXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5UaGUgJnF1 b3Q7SWRQIE1peC1VcCZxdW90OyBhbmQgJnF1b3Q7TWFsaWNpb3VzIEVuZHBvaW50JnF1b3Q7IGF0 dGFja3MgKGFzIHdlbGwgYXMgdmFyaWF0aW9ucyBvbiB0aGVtKSB0YWtlIGFkdmFudGFnZSBvZiB0 aGUgZmFjdCB0aGF0IHRoZXJlJ3Mgbm90aGluZyBpbiB0aGUgT0F1dGggYXV0aG9yaXphdGlvbiBy ZXNwb25zZSB0byB0aGUgY2xpZW50J3MgcmVkaXJlY3RfdXJpIHRoYXQgaWRlbnRpZmllcyB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIuIEFzIGEgcmVzdWx0LA0KIGEgdmFyaWV0eSBvZiB0ZWNobmlx dWVzIGNhbiBiZSB1c2VkIHRvIHRyaWNrIHRoZSBjbGllbnQgaW50byBzZW5kaW5nIHRoZSBjb2Rl IChvciB0b2tlbiBpbiBzb21lIGNhc2VzKSB0byB0aGUgd3JvbmcgZW5kcG9pbnQuPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRvIHRoZSBiZXN0IG9m IG15IHJlY29sbGVjdGlvbiB0aGUgZ2VuZXJhbCBjb25zZW5zdXMgY29taW5nIG91dCBvZiB0aGUg bWVldGluZ3MgaW4gRGFybXN0YWR0ICh3aGljaCBIYW5uZXMgbWVudGlvbmVkIGluDQo8YSBocmVm PSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL0pJVnhGQkdzSkJW dG03bGp3SmhQVW0zRnItdyIgY2xhc3M9IiI+DQpPQXV0aCBTZWN1cml0eSBBZHZpc29yeTogQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgTWl4LVVwPC9hPikgd2FzIHRvIHB1dCBmb3J0aCBhbiBJLUQgYXMg YSBzaW1wbGUgZXh0ZW5zaW9uIHRvIE9BdXRoLCB3aGljaCBkZXNjcmliZWQgaG93IHRvIHJldHVy biBhbiBpc3N1ZXIgaWRlbnRpZmllciBmb3IgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCBj bGllbnQgaWRlbnRpZmllciBhcyBhdXRob3JpemF0aW9uIHJlc3BvbnNlIHBhcmFtZXRlcnMgZnJv bQ0KIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBEb2luZyBzbyBlbmFibGVzIHRoZSBjbGll bnQgdG8ga25vdyB3aGljaCBBUyB0aGUgcmVzcG9uc2UgY2FtZSBmcm9tIGFuZCB0aHVzIGF2b2lk IHNlbmRpbmcgdGhlIGNvZGUgdG8gYSBkaWZmZXJlbnQgQVMuIEFsc28sIGl0IGRvZXNuJ3QgaW50 cm9kdWNlIGFwcGxpY2F0aW9uL21lc3NhZ2UgbGV2ZWwgY3J5cHRvZ3JhcGh5IHJlcXVpcmVtZW50 cyBvbiBjbGllbnQgaW1wbGVtZW50YXRpb25zLg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NClRoZSA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1qb25lcy1vYXV0aC1taXgtdXAtbWl0aWdhdGlvbi0wMCIgY2xhc3M9IiI+DQptaXRp Z2F0aW9uIGRyYWZ0IHRoYXQgd2FzIHBvc3RlZCB5ZXN0ZXJkYXk8L2E+IGRpdmVyZ2VzIGNvbnNp ZGVyYWJseSBmcm9tIHRoYXQgd2l0aCBhIHNpZ25pZmljYW50bHkgZXhwYW5kZWQgc2NvcGUgdGhh dCBpbnRyb2R1Y2VzIE9wZW5JRCBDb25uZWN0IElEIFRva2VucyAoc29ydCBvZiBhbnl3YXkpIHRv IHJlZ3VsYXIgT0F1dGggYW5kIHRoZSByZXRyaWV2YWwgb2YgYSBtZXRhZGF0YS9kaXNjb3Zlcnkg ZG9jdW1lbnQgaW4tYmV0d2VlbiB0aGUgYXV0aG9yaXphdGlvbg0KIHJlcXVlc3QgYW5kIHRoZSBh Y2Nlc3MgdG9rZW4gcmVxdWVzdC4gPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkl0IGlzIHBvc3NpYmxlIHRoYXQgbXkgcmVjb2xsZWN0aW9u IGZyb20gRGFybXN0YWR0IGlzIHdyb25nLiBCdXQgSSBleHBlY3Qgb3RoZXJzIHdobyB3ZXJlIHRo ZXJlIGNvdWxkIGNvcnJvYm9yYXRlIG15IGFjY291bnQgb2Ygd2hhdCB0cmFuc3BpcmVkLiBPZiBj b3Vyc2UsIHRoZSBhZ3JlZW1lbnRzIG91dCBvZiB0aGUgRGFybXN0YWR0IG1lZXRpbmcgd2VyZSBu ZXZlciBpbnRlbmRlZCB0byBiZSB0aGUgZmluYWwgd29yZCAtDQogdGhlIHdob2xlIFdHIHdvdWxk IGhhdmUgdGhlIG9wcG9ydHVuaXR5IHRvIHdlaWdoLCBhcyBpcyBub3cgdGhlIGNhc2UuIEhvd2V2 ZXIsIGEgZ29hbCBvZiBtZWV0aW5nIGZhY2UtdG8tZmFjZSB3YXMgdG8gY29tZSBhd2F5IHdpdGgg YSBnb29kIGNvbnNlbnN1cyB0b3dhcmRzIGEgcHJvcG9zZWQgc29sdXRpb24gdGhhdCBjb3VsZCAo aG9wZWZ1bGx5KSBiZSBpbXBsZW1lbnRhYmxlIGluIHRoZSB2ZXJ5IG5lYXIgdGVybSBhbmQgbW92 ZSB0aG91Z2h0DQogdGhlIElFVEYgcHJvY2VzcyBpbiBhbiBleHBlZGl0ZWQgbWFubmVyLiBJIGJl bGlldmUgd2UnZCByZWFjaGVkIGNvbnNlbnN1cyBidXQgdGhlIGNvbnRlbnQgb2YgLTAwIGRyYWZ0 IGRvZXMgbm90IHJlZmxlY3QgaXQuDQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+SSd2ZSBtYWRlIHRoZSBwbGVhIG9mZi1saXN0IHNldmVyYWwgdGlt ZXMgdG8gc2ltcGxpZnkgdGhlIGRyYWZ0IHRvIHJlZmxlY3QgdGhlIHNpbXBsZSBzb2x1dGlvbiBh bmQgbm93IEknbSBkb2luZyB0aGUgc2FtZSBvbi1saXN0LiBTaW1wbGlmeSB0aGUgcmVzcG9uc2Ug dmFsaWRhdGlvbiB0byBqdXN0IHNheSBub3QgdG8gc2VuZCB0aGUgY29kZS90b2tlbiBiYWNrIHRv IGFuIEFTIGVudGl0eSBvdGhlciB0aGF0IHRoZSBvbmUNCiBpZGVudGlmaWVkIGJ5IHRoZSAnaXNz JyBpbiB0aGUgcmVzcG9uc2UuIEFuZCByZW1vdmUgdGhlIGlkX3Rva2VuIGFuZCBKV1QgcGFydHMg dGhhdCAuDQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+SWYgdGhpcyBXRyBhbmQvb3IgdGhlIGxhcmdlciBjb21tdW5pdHkgYmVsaWV2ZXMgdGhhdCBP QXV0aCBuZWVkcyBzaWduZWQgcmVzcG9uc2VzLCBsZXQncyBkZXZlbG9wIGEgcHJvcGVyIHNpbmdl ZCByZXNwb25zZSBtZWNoYW5pc20uIEkgZG9uJ3Qga25vdyBpZiBpdCdzIG5lZWRlZCBvciBub3Qg YnV0IEkgZG8ga25vdyB0aGF0IGl0J3MgYSBkZWNlbnQgY2h1bmsgb2Ygd29yayB0aGF0IHNob3Vs ZCBiZSBjb25zY2llbnRpb3VzbHkNCiB1bmRlcnRha2VuIGluZGVwZW5kZW50IG9mIHdoYXQgY2Fu IGFuZCBzaG91bGQgYmUgYSBzaW1wbGUgdG8gdW5kZXJzdGFuZCBhbmQgaW1wbGVtZW50IGZpeCBm b3IgdGhlIGlkcCBtaXgtdXAgcHJvYmxlbS4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT0F1dGggbWFp bGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiBj bGFzcz0iIj5PQXV0aEBpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4+T0F1dGggbWFpbGlu ZyBsaXN0PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+ T0F1dGhAaWV0Zi5vcmc8L2E+PC9zcGFuPjxicj4NCjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9B dXRoQGlldGYub3JnPC9hPjxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_A7FF6797CAA34E64B384A0EEB5442AD1adobecom_-- From nobody Fri Jan 15 02:34:53 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401571A913E for ; Fri, 15 Jan 2016 02:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i7qWBPGpgYe for ; Fri, 15 Jan 2016 02:34:51 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1911A913A for ; Fri, 15 Jan 2016 02:34:50 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id f206so14724245wmf.0 for ; Fri, 15 Jan 2016 02:34:50 -0800 (PST) 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-type:content-transfer-encoding; bh=Jqvxc7atuogCe6lu1K7BOd3IbnbNJ8NjhwU6QPsmFO0=; b=m++duywAxcE8Jy05fAkzCdy9CKx+qPHUB6HDdOCwdkAugEUOdqI/tYXF2Ji4vMEBtT IwMIEHPO0CAqHHzq12JxNycKvtex6N4MTX/xKWkvfWrT6lgset4AoLWhWu7uqJ4IeTyR 2dHDCagsb4SOcuPbPGE9HeTdgVbbm9k+QVz2kyOJ2fuca2E9i4WD7VQunpOHxRDQO82P wcCFJgmp7UK7QVhG0puPxhj5ySJnyaz0lfEeZVms8Swpi2vMzcdccDdmJmqOC623ggV2 3D8QjZUen3G7SzztcmSAoQXe6Upx6o4qCg0XumUA4A6CsWaGSJ+5giALBo6QLXEtmjge 5FyA== 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-type :content-transfer-encoding; bh=Jqvxc7atuogCe6lu1K7BOd3IbnbNJ8NjhwU6QPsmFO0=; b=ETWUqYFvG1arfm+9kkqZMZihT89dWTr/+KRCc/hnfjdX0uWbpgMH1CnODZ0Jbu7F9o 6iHJkM4+LK3aSLGZ/I6ZWi3yzl5eMPvaVRIROh4eBex8rbD9q+TTEFHhp6wSBQx6i1S2 Rwze0e+KWDXliTcHSOEOb6vJ3dizaY+z5RqJbBKWgUw9VO306i3wK9xent7ccXdvir12 rTQH8VOcONuvkGghVt4wv3SeoXYatlG/TS79TGhITqlw/dOfKraP6ZZYYbeKI2LdmXJN cOg4koCrOvohW6BfNOXXKAAJvu7/lTdkaVzvDPmaaYbHUe6/+ITzcJLlJm4ZpzBaPVb+ z6TA== X-Gm-Message-State: AG10YOS1J+Ekxy6+c/f5Hc8pA0ul5TS/ceGXpThGlrxEJD7xpzf/0JkjgXqYXLS6caEOXA== X-Received: by 10.28.146.8 with SMTP id u8mr2430697wmd.72.1452854089507; Fri, 15 Jan 2016 02:34:49 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id k130sm1954818wmg.6.2016.01.15.02.34.48 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 02:34:48 -0800 (PST) To: oauth@ietf.org References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> From: Sergey Beryozkin Message-ID: <5698CB3D.1030306@gmail.com> Date: Fri, 15 Jan 2016 10:34:37 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 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] Question about RFC 7622 (Token Introspection) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 10:34:52 -0000 Hi All, I'm reviewing RFC 7622 as we are going ahead with implementing it. I have a question: 1. Token Hint in the introspection request. The spec mentions 'refresh_token' as one of the possible values. But a protected resource does not see a refresh token (ever ?), it is Access Token service which does. When would a protected resource use a 'refresh_token' hint when requesting an introspection response ? Thanks, Sergey From nobody Fri Jan 15 03:08:26 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011C11ACD48 for ; Fri, 15 Jan 2016 03:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTK9nUaqWtIj for ; Fri, 15 Jan 2016 03:08:23 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A2B1ACD32 for ; Fri, 15 Jan 2016 03:08:22 -0800 (PST) Received: from [192.168.10.141] ([80.92.119.40]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MK17F-1aLPgP1UAf-001OWc for ; Fri, 15 Jan 2016 12:08:20 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5698D322.6030206@gmx.net> Date: Fri, 15 Jan 2016 12:08:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cdkvSUSNgwNlrFg0eF70rWL7589KGtJWO" X-Provags-ID: V03:K0:m1rzHuFdpeQzZocZofIBAzulXjHRrqOcKfTDI8M2IWrFhJPF4r9 h4d1JvB5e2gzOKKDJVgvLRFq5KTtHWxbKmn0BTFOxaf3MH1NPgOMzaJxjhJQt7wa3Cad7IF S9WtjZPYHnqSuMbGudXlxfDiyt2RzX1EXoJYo5rwvUWmRZS0nogkP6cUUYqfBADY/pNWnPV 1ccOnQOCp2b3Lmdn7SFjQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:znzpNzgmr5I=:2dz9r3epnj2tqoT7tlP6nZ 4CgxS8+5ip9i1fCZjeztI+hwGdWyFuTmZOmsW75Vc8BajsvD0Sylma4VQH5FU68W+uAUYrqN7 uMUy0SwDzH0WWzK3L20pzImf7KIIDDgsloUrg/TgFw78nuTFPT9D76d/Z8bCoISUflW9nR1al 0iTDe90vr/rI5LXRNSOgAPJjy4GelDdMfFqNet8T3sYVgafggznVdapHHgSWHyFRzIjcZSYSN lLhZWJ3PKROCKw56cy0robZvMwDREYnwbqHtqI8XI06x+YXbq3XRkHOfLOq21rYCGtf82QbUJ V9521WJvLtNHPHhkdXnfkaXf45AyMEuwnOf2O5I7KcsjKxMEbCwese2ZOq2e6p81p91mvxW7Q DXvna/IrXfqJ00aefpzvk7P22qQK378IedaY0a/vHNDG5MBuJdBeyKq8RcfD4miNJvAtI0huq Vaj4VtEfXhKhfb+fJ5KUsOgDtsYtrmUxG9LU52O4cre3vLI7lyKVc7XzoGz2j5j+/msfNjBy4 Uma0dZlgwtlmnLn37fLs3yoR5KqFyY8KP2iDdLwFCi5DWPmqMFezewah7MvsH6+Y4y5IW8xsr EOwUhGtinQ5S2gFg7OqEMGhL8oGQZym6TEzWHgRU3lbR2f+FsrjQRtfUCoyR/ky+GgVusEIx0 41s8PMGnw0fETdKVjUpJKezTm7KWFv6+853iPvkw549/TfuUkyXbzp8SkMyFb8L8/XWtXsXlV gPJ6+8KpXzxbFuTEr8vFA8wvu8K41y9eC1riW3VmjU2Q4J3rMueTVuiqddU= Archived-At: Subject: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 11:08:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cdkvSUSNgwNlrFg0eF70rWL7589KGtJWO Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I have just requested a 2 hour meeting slot for the next IETF meeting in Buenos Aires. It would be good to know whether you are planning to attend the upcoming IETF meeting. Please drop me a private mail to tell me your plans. Ciao Hannes --cdkvSUSNgwNlrFg0eF70rWL7589KGtJWO 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 iQEcBAEBCgAGBQJWmNMiAAoJEGhJURNOOiAtJHUH/jy+Okg5NdkQh6VKoES4PUa7 0kbZ2Nwk1QJGFypGeJNhiJviEADmXX8PxMrj2IyaCmNd9gPCu+AKK5FPWZCmw+q6 WW/6pETCDCKzLnnAGkTbRLf8LmP2dBpvzPay9bHH0XGASUlptKm9eDbSpuGAjL48 6rKc3kROdYXWaTzai650nA280eKPErsZpKVm3w0XUoCPLXpPCZb13sPfD53zbtu2 Z07O3l40xqE0ycP3Ck35FneuNMGk8kRYkbNPgRFmBvYGUzsyA/ZZdKH94XnZDWcT pjmG58I+yDlMOH6nMqMonmWglqydRqkoAt9T/k9c2FOQzHd6IHoDbbUewm0QIoo= =Wu6X -----END PGP SIGNATURE----- --cdkvSUSNgwNlrFg0eF70rWL7589KGtJWO-- From nobody Fri Jan 15 04:31:01 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4001B2C31 for ; Fri, 15 Jan 2016 04:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buqYRes-rUKw for ; Fri, 15 Jan 2016 04:30:59 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014E41B2C2E for ; Fri, 15 Jan 2016 04:30:59 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id 65so117217693pff.2 for ; Fri, 15 Jan 2016 04:30:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qa5wMi1ONrzgU5E/kwP9JVtMXp3a2S1j5iRvWiKV+f0=; b=jqeAaMK82unq5gK4eRE+HX+mQM8/53N/F/kiBsShFFD8ecendNcOnS4wttinsOVHwU WgfD+zGMKOoXPTYjE3qi2b/x6IPeQ3e6l9zEnqL/XfABS3W8RyiZDkX3U22xeT6Y2EgP 9+SB8meZHikVftWF738DuywbNFoVTxxxSc85UA+z19xO/4NVWWGP9NGm1dW2lMEck9U9 u6cMDi0YP9bZLF4H4WzYi1MaDJnjKkIyCcTPxXqc6cKNkgc+I3edUFSU6IZhBAxbWIY+ TZxPyYO1Z0ZWtIeComFn/+pp5QuAs0RVw9NSBu0ed8KKRZDWh32RohOqL0/kIYgChj0F x+AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=qa5wMi1ONrzgU5E/kwP9JVtMXp3a2S1j5iRvWiKV+f0=; b=XDFqtFUlWDHcLpiSBjLoz+bQelpoNJI0Y1fEhcPCiKYD3ExYCdRQuFBDFOYBwHutxj vE5ll88Uru+R48MHq4AukdI/Us5zcZQzokhy5JPIFHTcd66E1L6FoOb12SYtg/MGKgD3 S79oANvPh4aEPmF0PyIvdZiBuGLC42MHblwUkSjDV88p5tHlWT8XqxnByHAuqfLW0CkN 9xPDWPTrN/xjrq75iKcvPFHIP1JkJy38N8jE+3r4oFEUJvPaBqwMS1J3tx9LdDAi+rWo XnZu8/Vi6lwWXSzKSSjMCmt+2tDN2PDZUY+6YlYCntt1ZKrmejUIAZnPml8Mn9IqxOl4 a55A== X-Gm-Message-State: ALoCoQlX+J3Uwk5caIl8hgHGrVfAKvh8/YzjJ1fUpI9pst5rhQgEdk9oYelPtWbvjF87ca73vu/1wucEH3sspL3PXvLXEdcMIw== X-Received: by 10.98.2.216 with SMTP id 207mr14449233pfc.3.1452861058606; Fri, 15 Jan 2016 04:30:58 -0800 (PST) Received: from [100.70.225.155] (190.78.239.49.rev.vmobile.jp. [49.239.78.190]) by smtp.gmail.com with ESMTPSA id v75sm15388186pfa.60.2016.01.15.04.30.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 04:30:56 -0800 (PST) Content-Type: text/plain; charset=iso-2022-jp Mime-Version: 1.0 (1.0) From: Nat Sakimura X-Mailer: iPhone Mail (13C75) In-Reply-To: <5698D322.6030206@gmx.net> Date: Fri, 15 Jan 2016 21:30:53 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <70C03AE0-19A0-4A4D-8B5F-093A817A97AB@gmail.com> References: <5698D322.6030206@gmx.net> To: Hannes Tschofenig Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 12:31:00 -0000 I plan to attend.=20 =3Dnat via iPhone 2016/01/15 20:08=1B$B!"=1B(BHannes Tschofenig =1B= $B$N%a%C%;!<%8=1B(B: > Hi all, >=20 > I have just requested a 2 hour meeting slot for the next IETF meeting in > Buenos Aires. >=20 > It would be good to know whether you are planning to attend the upcoming > IETF meeting. Please drop me a private mail to tell me your plans. >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Jan 15 04:58:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD3D1B2C56 for ; Fri, 15 Jan 2016 04:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2xL-8mBRLvc for ; Fri, 15 Jan 2016 04:58:04 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F2C1B2C57 for ; Fri, 15 Jan 2016 04:58:04 -0800 (PST) Received: by mail-qg0-x229.google.com with SMTP id o11so506458007qge.2 for ; Fri, 15 Jan 2016 04:58:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jsqj0zg1jp0L12SgiMMW2TLuY7Fl8dMKoVcM/Jh56kQ=; b=B3FuGYM/jjiocF8w1Em2QA+YRnZDjD8GvasDmjC2QCGRS73DLC+CTUSDXJi1ghEtxG 84Q3juWCwhwjVFe1LPcq6MQfHVZlgSb8nTNRiKl5l5IRwT7SxdzWhS+MESLQoXYRauzy m0AT3UYar4QY03tpna44wzadKzMLCiglFNJNxLq1KwAWVVL/KJKULiLK6y+oqXZWidbc GI/nggRR0m3H2M7+vvgTxiVhCKtdpt7DcKZwVr87lUrs6gpbNqLNXqULWwnL0H+jJG46 wggfmmJjf4RsNAjzXUV/HdvCM4rdQKPPjV+3SCoOsS2R++OTjcrv/ekkBs2OaMdXzdPm P/Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=jsqj0zg1jp0L12SgiMMW2TLuY7Fl8dMKoVcM/Jh56kQ=; b=E+LUNeqxovr5vLibFH+57S/ItwzLzuB67VCeo7HFp4J7W8VKoiRCYCs/zc5xYHy/ms FOZRbTHDMyUPxga1mLNFYU1cBxxxPdeSOhLV/kLA2wlRqDO6Os7AWWNCRr2sjCXCuYYv px6LzrvLKS6LupwFrPrw6ECM/yTNwMdeu7WRKJHNMZRm76uX+NjzJJbpm8vqJ4QLlR78 no4PXhx0zEYx3oBinLyCfq11RvUBI1zjDSxBBC06s/JPSVyXUjLT0GGuXNbPxEJ1fAVl yXq4VhN9VbQk6RKcsIs6Z2qJFJ8NoDKaLN6P4ehFlaOrgpJELdGV8yaxTwxPqazQCduG n9qQ== X-Gm-Message-State: ALoCoQnXHQmbNsP/cxSNi3mM5pzKagiD0OvyanwkufS7MXYdCZLRvpj8CquMDcedR1a+tpL7MP8GGDV5cPwmldYKn28DDOqWGg== X-Received: by 10.140.35.115 with SMTP id m106mr12733841qgm.13.1452862683597; Fri, 15 Jan 2016 04:58:03 -0800 (PST) Received: from [107.17.140.60] ([107.17.140.60]) by smtp.gmail.com with ESMTPSA id w71sm4427320qha.30.2016.01.15.04.58.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 04:58:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <5698D322.6030206@gmx.net> Date: Fri, 15 Jan 2016 07:58:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> References: <5698D322.6030206@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "oauth@ietf.org" , =?utf-8?Q?Rolando_Mart=C3=ADnez?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 12:58:06 -0000 Yes I am going. The University of Chile and RedHat are sponsoring a one day OpenID = Summit on Mar 31. I will send the registration info to the list once we have it up. Anyone interested should email myself or Rolando who is cc=E2=80=99d on = this. John B. > On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > I have just requested a 2 hour meeting slot for the next IETF meeting = in > Buenos Aires. >=20 > It would be good to know whether you are planning to attend the = upcoming > IETF meeting. Please drop me a private mail to tell me your plans. >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Jan 15 05:03:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EDD1B2C5E for ; Fri, 15 Jan 2016 05:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCNppGvCI9RJ for ; Fri, 15 Jan 2016 05:03:48 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 A16BE1B2C7B for ; Fri, 15 Jan 2016 05:03:47 -0800 (PST) Received: by mail-ob0-x236.google.com with SMTP id is5so109434520obc.0 for ; Fri, 15 Jan 2016 05:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=mDLP814/F1r2dDip/YqCFJLh/Rv0/gYORI48utzFCnc=; b=ABK+UxYO8hAm/8QH9YPDOkpE9W/SC71Jzh961aUMmC3IauIl5yz7cFmPpYEb3+E23x pqi4SQc5AcZBEIAWJ9J/lYiHdXraLHKztfxaqH+kpNmEwqIw+qJPEtd9tmkOzsXu/AJ7 ZoqkY0NZAuKwuRuLC6NsHFWeamDaCJ47zKorhW28aSbbDNOm3y+59hE9hyZfp4kyulee 8MYlo+H/tlRO7NP/7EibO85FXD5u7s0O/gHNO5VcdAAky/9rapPKGisHHyk1mEeSYS63 rS8B9AXleAmkAF84w3yYeslkLeOp4qxntDf3ZcYGv6r+oS2RTJxGL/Owx+IkqYHakQ62 dw6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=mDLP814/F1r2dDip/YqCFJLh/Rv0/gYORI48utzFCnc=; b=cncNmR+Ch8Ki8kROcWpKQI+/ANEvrk/uoD/yiKA7v98DuT4LkWm7IS5Pl8fcaT2HBY sFmtc1HgqKjgdqXyfqPlfLh3muJWKlIuPBt84/XBC2GQQiCt0TlDaRXk/tbISz4JYbDB Yy6WBKqZMROX8illt1Khi1L1qilSJf0GEeH55kkJvN+O8oFBys87xwjri7Tnni9UmLcZ weF1FdRNpYapuySitGW2atWlqVZZpt/PkwFlluHE2Uzj10ykh4CQV/378/lzY4+0B3BP wAecrXZWlPhvqL5DxnHFVcaUjhU/1FVdAqMyB6k8FeNV+OnQMnowYpF8ydT5BtJpC43J lVsw== X-Gm-Message-State: ALoCoQllhiY8jOg1IbB4sRrlC7hCIW1eDTKjb+scUvzLO3lwx/DGjZtYEwYWMd87Vbe+TJxGRUVUf9Gv2+hwyqP9UyaBugQAEA== X-Received: by 10.182.88.196 with SMTP id bi4mr8164968obb.56.1452863027048; Fri, 15 Jan 2016 05:03:47 -0800 (PST) MIME-Version: 1.0 References: <5698D322.6030206@gmx.net> <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> In-Reply-To: <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> From: Nat Sakimura Date: Fri, 15 Jan 2016 13:03:36 +0000 Message-ID: To: John Bradley , Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e010d9800a2773905295f0867 Archived-At: Cc: "oauth@ietf.org" , =?UTF-8?Q?Rolando_Mart=C3=ADnez?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 13:03:49 -0000 --089e010d9800a2773905295f0867 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's in Chile? 2016=E5=B9=B41=E6=9C=8815=E6=97=A5(=E9=87=91) 21:58 John Bradley : > Yes I am going. > > The University of Chile and RedHat are sponsoring a one day OpenID Summit > on Mar 31. > > I will send the registration info to the list once we have it up. > > Anyone interested should email myself or Rolando who is cc=E2=80=99d on t= his. > > John B. > > > On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > > > > Hi all, > > > > I have just requested a 2 hour meeting slot for the next IETF meeting i= n > > Buenos Aires. > > > > It would be good to know whether you are planning to attend the upcomin= g > > IETF meeting. Please drop me a private mail to tell me your plans. > > > > Ciao > > Hannes > > > > _______________________________________________ > > 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 > --089e010d9800a2773905295f0867 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's in Chile?
2016= =E5=B9=B41=E6=9C=8815=E6=97=A5(=E9=87=91) 21:58 John Bradley <ve7jtb@ve7jtb.com>:
Yes I am going.

The University of Chile and RedHat are sponsoring a one day OpenID Summit o= n Mar 31.

I will send the registration info to the list once we have it up.

Anyone interested should email myself or Rolando who is cc=E2=80=99d on thi= s.

John B.

> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net&g= t; wrote:
>
> Hi all,
>
> I have just requested a 2 hour meeting slot for the next IETF meeting = in
> Buenos Aires.
>
> It would be good to know whether you are planning to attend the upcomi= ng
> IETF meeting. Please drop me a private mail to tell me your plans.
>
> Ciao
> Hannes
>
> _______________________________________________
> 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
--089e010d9800a2773905295f0867-- From nobody Fri Jan 15 05:11:51 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C681B2C6C for ; Fri, 15 Jan 2016 05:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24hA5_32aDBA for ; Fri, 15 Jan 2016 05:11:48 -0800 (PST) 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 C380B1B2C83 for ; Fri, 15 Jan 2016 05:11:47 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id y67so53175215qkc.2 for ; Fri, 15 Jan 2016 05:11:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=6BFlg2eEGqJpkqOcd1UZiudaxE8q5mVWVzwCwlbNPg0=; b=eEa3rk4/9pycB0POfotakOBQg4PVevaPM8AshSI1ZG/cj7e3SWbyBwIuXc5rOzQJp2 CmyewT/dN3rXTZQIEpm/vtNM2+dPWYFvFPY3Jv9kU0bS7Oijl6vs+lxUT32bvGbn8mjQ n8pvP4jgYdGW4TQ7j5sAU1tIS5+iPwYxxM3fch+uhSN8Egoqncl40+YMuG7iv9U+1AO2 KGIftqdvH7zUeB475Uggsm2NgnQoN7oGsxFJ8tD87VhQ3AoAmuHvsCWywnxX5gY2fCxN wDPN2DXQtLPSHFDKMuqWtJtLbqHs3mWvw2TjZzmtqL46+b/QGgo3AN5kNK2xeRI617Zv 8DMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=6BFlg2eEGqJpkqOcd1UZiudaxE8q5mVWVzwCwlbNPg0=; b=WMn4N52FTVP5vfa+GOTd05jp3yLTRb3cE1F+7K407msOCzKYwm0oUlL2e2iaGzckD5 FK4DIJyYu0er4myZDYaEYX/5m0HrDQ7FHSf1gWq5Hof+CA2Mrh4zvck7bLZ6fu288rz6 j3wSQuhYVweZhu77sYy0WtPX4d6HgHirQ3a8YznaFEmjf1x7JKlkV0puYX+E//GkokYU b1RBkNDpViLVsJTP6W1jHDLNv4vtEiufK9vsm/yqWxnL0InThs45GutTZ4HjBUT30Yhj 3vsM3EZg6dgUOfNwYb5wdidWxrA7dS8hfgxH5tPPkr0NsAXWi83/AZHULGnZBZm2HC7Q 4REA== X-Gm-Message-State: ALoCoQnAYXRjfc4W/ll5uFfzIGi5W8JYHEU6fERhlv7XtSvUI/QeC0Mrc8eD3k6T8lsGVsNoUZDhCfX57w3zTwANoFzkksvicA== X-Received: by 10.55.15.139 with SMTP id 11mr12776193qkp.50.1452863506785; Fri, 15 Jan 2016 05:11:46 -0800 (PST) Received: from [107.17.140.60] ([107.17.140.60]) by smtp.gmail.com with ESMTPSA id w140sm4447108qhb.37.2016.01.15.05.11.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 05:11:46 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5E46037D-B308-4F86-A130-C718CA577E73" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Fri, 15 Jan 2016 08:11:44 -0500 Message-Id: <2620D5EE-5479-444F-8EF3-1B10672D4C9C@ve7jtb.com> References: <5698D322.6030206@gmx.net> <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> To: Nat Sakimura X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "oauth@ietf.org" , =?utf-8?Q?Rolando_Mart=C3=ADnez?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 13:11:49 -0000 --Apple-Mail=_5E46037D-B308-4F86-A130-C718CA577E73 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes in Santiago Chile a short flight or long drive to Buenos Ares. It is the Thursday prior to the IETF so that people have time to visit = my Parcella and go on wine tours etc before heading to BA on Sunday. = http://www.tripadvisor.com/Attraction_Review-g1136527-d8504544-Reviews-Mai= po_Valley_Wine_Tours-Isla_de_Maipo_Santiago_Metropolitan_Region.html = http://santiagotourist.com/30-things-to-do-when-visiting-santiago-chile/ = = John B. > On Jan 15, 2016, at 8:03 AM, Nat Sakimura wrote: >=20 > That's in Chile?=20 > 2016=E5=B9=B41=E6=9C=8815=E6=97=A5(=E9=87=91) 21:58 John Bradley = >: > Yes I am going. >=20 > The University of Chile and RedHat are sponsoring a one day OpenID = Summit on Mar 31. >=20 > I will send the registration info to the list once we have it up. >=20 > Anyone interested should email myself or Rolando who is cc=E2=80=99d = on this. >=20 > John B. >=20 > > On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig = > wrote: > > > > Hi all, > > > > I have just requested a 2 hour meeting slot for the next IETF = meeting in > > Buenos Aires. > > > > It would be good to know whether you are planning to attend the = upcoming > > IETF meeting. Please drop me a private mail to tell me your plans. > > > > Ciao > > Hannes > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_5E46037D-B308-4F86-A130-C718CA577E73 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes in Santiago Chile a short flight or long drive to Buenos = Ares.

It is the = Thursday prior to the IETF so that people have time to visit my Parcella = and go on wine tours etc before heading to BA on Sunday.
http://www.tripadvisor.com/Attraction_Review-g1136527-d8504544-= Reviews-Maipo_Valley_Wine_Tours-Isla_de_Maipo_Santiago_Metropolitan_Region= .html

http://santiagotourist.com/30-things-to-do-when-visiting-santia= go-chile/

John B.
On Jan 15, 2016, at 8:03 AM, Nat Sakimura = <sakimura@gmail.com> wrote:

That's in Chile?
2016=E5=B9=B41=E6=9C=8815=E6=97=A5(=E9=87=91) 21:58 John = Bradley <ve7jtb@ve7jtb.com>:
Yes I am going.

The University of Chile and RedHat are sponsoring a one day OpenID = Summit on Mar 31.

I will send the registration info to the list once we have it up.

Anyone interested should email myself or Rolando who is cc=E2=80=99d on = this.

John B.

> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>
> Hi all,
>
> I have just requested a 2 hour meeting slot for the next IETF = meeting in
> Buenos Aires.
>
> It would be good to know whether you are planning to attend the = upcoming
> IETF meeting. Please drop me a private mail to tell me your = plans.
>
> Ciao
> Hannes
>
> _______________________________________________
> 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=_5E46037D-B308-4F86-A130-C718CA577E73-- From nobody Fri Jan 15 05:32:39 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680AB1A0196 for ; Fri, 15 Jan 2016 05:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsrlfLn1AKVV for ; Fri, 15 Jan 2016 05:32:36 -0800 (PST) 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 06C9D1B2CDD for ; Fri, 15 Jan 2016 05:32:35 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id y67so53385306qkc.2 for ; Fri, 15 Jan 2016 05:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0IdEJUlT5CrBpEi1NkKkpmqPwStxq4ExniDgbH/cV2c=; b=v9G+z+iqOdZjkbPpJW448TUjbjy1hHYeiQVz0xjbDbrB4KRbumL7shH1g16Q6idDjB 4mi8nXj6m/jIRY+M01mXBMl6zYdFgL9eJI/nxgptrkFvGFVtE4dBm9gjzAbXHCY9Kc87 3Nq+d4SWXDSIuJCH2iFgAqoy8gEFHbaQrepi6wQoUyIG3Uj0I0/LRnsu1MoZDbIXsh2V ByGxyBwS0JgYS/Igz57TNtxXcRih7np/LU5qP3cyOligjxCzVY/GiXa4TSAnYpm6TUcT 7wBjL0X2ytHxDD69kbNqDCF12EyWb3V4mOSl1TUbwaDNWrF7C+w4xS58p57ZBLR/uhvG gIvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=0IdEJUlT5CrBpEi1NkKkpmqPwStxq4ExniDgbH/cV2c=; b=g9QmHpxF8e+ZbloIdJL/LGy77nsEjoFEuwktVWMLOY2j4WxBGDr+ydTZvCW+OZivWl TDSlvafPnG1c43KuiojtwNUK9J+2a7Q3x7ZnbHQSeoqBhu1YJm1bWbdywd/NbrV8dc9l IfZAWTe5TfxkvCTb2ccKMKebk5Z0bL2Po6HLqo76S0S1vybSNRVAxXcWNLBTAu1cSA8l fCzc2oxzNuA5B31mIo/caA04cXI8UqMbg4s7GCiTNy+yZwyg1gGsla7K9HZ4fti5MEfL NVVAiH//NAQlwHuaw0Re1GB5BmVWqLnsHQHPhwtZyRLDZdiUXGmHHFjXm/OkV9d6g7h5 iquQ== X-Gm-Message-State: ALoCoQm37RPbeo3eIr5iWyQMYx4g1a7u+D5k+mTtoGiM9ycRv5Mpf9TCGl1uTRaOaCR59NHagoGku20mbHxYk91oXMuk3n2urw== X-Received: by 10.55.18.76 with SMTP id c73mr12563302qkh.54.1452864755129; Fri, 15 Jan 2016 05:32:35 -0800 (PST) Received: from [107.17.140.60] ([107.17.140.60]) by smtp.gmail.com with ESMTPSA id j69sm4532684qkh.21.2016.01.15.05.32.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 05:32:34 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <5698CB3D.1030306@gmail.com> Date: Fri, 15 Jan 2016 08:32:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> To: Sergey Beryozkin X-Mailer: Apple Mail (2.2104) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 13:32:38 -0000 Some people wanted the client to be able to use introspection. The ability to pass a refresh token is a legacy of that. A RS would = never have a refresh token unless it is acting as a client. That is = correct. John B. > On Jan 15, 2016, at 5:34 AM, Sergey Beryozkin = wrote: >=20 > Hi All, >=20 > I'm reviewing RFC 7622 as we are going ahead with implementing it. > I have a question: >=20 > 1. Token Hint in the introspection request. > The spec mentions 'refresh_token' as one of the possible values. But a = protected resource does not see a refresh token (ever ?), it is Access = Token service which does. > When would a protected resource use a 'refresh_token' hint when = requesting an introspection response ? >=20 > Thanks, Sergey >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Fri Jan 15 05:47:55 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1831B2D14 for ; Fri, 15 Jan 2016 05:47:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIpkGLbUYUr1 for ; Fri, 15 Jan 2016 05:47:52 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4562B1B2D13 for ; Fri, 15 Jan 2016 05:47:52 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id f206so21014653wmf.0 for ; Fri, 15 Jan 2016 05:47:52 -0800 (PST) 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-type:content-transfer-encoding; bh=hYlBGzXyEdtWGkq/ecGLI5ZbfIwXIKM1YkysVfncrKo=; b=0cNFo36jpY4/0MWBrvrtsV9nmZH0DlVOHEPcjVVZ47l6aCXN5EsRwc69nb9SkFPKjI OAcSdZM2W48grDYFQWjplgEyAbZXZYl4gEDTrtQ8txILIp0K7akP44/jRlvg0ylQRLVh sMd1cPLrMC1/wd2CKZPTJ86erAF4ucUtkVfsqgRsUkv2eDQYCwxw1qPHfQBRG1bKrTag 6t8xOCPrTZKf0woXyke2c7RqNpX07I3+SJOZ4cHC2EwPbisCtwGJx7nvD7A//CElkEst u6yQfCx2l6/93QeKG/AUIow98HHAn4IB0aJzTvM/0Y+vbFaddRRpY1LW673spxYra/UI 6eqA== 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-type :content-transfer-encoding; bh=hYlBGzXyEdtWGkq/ecGLI5ZbfIwXIKM1YkysVfncrKo=; b=l1HbQgXg2ZZJ07hvpXaLaV+2tV1aFxixwP0X2joj+z20GZUr07+hI5/S0KQeTga0D1 RSwzInfLsF+XrGgLoY5l6LSshwpZfoqsT5L4yheDd/FsAJxLnGYV6jPMwMQQjibXwtQZ eVoIqRyNb7vfIlFV5K3by3OLgkeHTtvuMpPWpIEETb37H6/AcQJCpiW3JoYqQEf/fbmg hXv/vNUEna5N+KYotdvtWQWgxNyHQ1rZ1y3BZedMQrFwqPVCtQioRJ4IeKpfNpJy1syp HOCbcYjUTdncj2iOnB26YlNCxygVX2LCk5Y+n1uheTyvWInbGNXgozdxHV4VcXhcllNt S7lg== X-Gm-Message-State: AG10YOSocv4G0F6izThJm2qKOqETG91yAiILYMka/rmMA5cyxXHe1M1hRA7rnyC4u5BLgQ== X-Received: by 10.28.146.8 with SMTP id u8mr3362959wmd.72.1452865670800; Fri, 15 Jan 2016 05:47:50 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id v82sm2629112wmv.12.2016.01.15.05.47.49 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 05:47:49 -0800 (PST) To: John Bradley References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> From: Sergey Beryozkin Message-ID: <5698F885.3030009@gmail.com> Date: Fri, 15 Jan 2016 13:47:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <69B0E23E-818A-4FE4-81A0-A8106EB6C312@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] Question about RFC 7622 (Token Introspection) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 13:47:54 -0000 Hi John Thanks, looks like it was a last minute change because Introduction does not explain why would clients want to use the introspection endpoint to effectively 'unwrap' the opaque token representations. I have another question. How to report the expiry time in cases when the tokens do not expire ? I'm aware of some deployments where access tokens are only manually deleted and otherwise would not expire. Perhaps not reporting the expiry time is equivalent to the token never expiring ? Or may be reporting 0 or -1 works ? Thanks, Sergey On 15/01/16 13:32, John Bradley wrote: > Some people wanted the client to be able to use introspection. > > The ability to pass a refresh token is a legacy of that. A RS would never have a refresh token unless it is acting as a client. That is correct. > > John B. > >> On Jan 15, 2016, at 5:34 AM, Sergey Beryozkin wrote: >> >> Hi All, >> >> I'm reviewing RFC 7622 as we are going ahead with implementing it. >> I have a question: >> >> 1. Token Hint in the introspection request. >> The spec mentions 'refresh_token' as one of the possible values. But a protected resource does not see a refresh token (ever ?), it is Access Token service which does. >> When would a protected resource use a 'refresh_token' hint when requesting an introspection response ? >> >> Thanks, Sergey >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From nobody Fri Jan 15 06:11:29 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD37B1B2D5D for ; Fri, 15 Jan 2016 06:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 373YP_kquzIz for ; Fri, 15 Jan 2016 06:11:26 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EABE41B2D5B for ; Fri, 15 Jan 2016 06:11:25 -0800 (PST) Received: from [192.168.10.141] ([80.92.119.40]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MPUlV-1aFwMt38T3-004gJP; Fri, 15 Jan 2016 15:11:23 +0100 To: John Bradley References: <5698D322.6030206@gmx.net> <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <5698FE08.8020804@gmx.net> Date: Fri, 15 Jan 2016 15:11:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XaLranqAxA7OPHfP7J5B3XHrNPBJ8djKV" X-Provags-ID: V03:K0:fLt9pmYDt9CmB9m780bghgO/rEbwBaixaFNrFNQ2S7p2KuI8Rl3 a8Eq1WRjwqHj0a+3D6uJXQbHtKhqzBeWP71dochgt5dsNjILU2YZoM4YXbNg1c2/xS+dfen 1t6WJPGHlLYzJFl309/RFsU8Bf0nq2Wv/L+z2Dk9EgseqCzKlHwfpdCoH0xW3t1FiZHK3J7 nszEvndsx89JGvdGT7Fyw== X-UI-Out-Filterresults: notjunk:1;V01:K0:e5aPk8CAqGs=:L+qQu1sObj9VOtulbZ5v4O xkQer7tFjH22qLoK1w5a5JqDynpQ2wARJ6v9HrDg2A/MaxIpdxS8BeGbBHTx7RSoS9/bsSRXv H32RNOsljloDXvdxQWNDkbrg/L8IqEEZqu9kLsdxHDrg8UbfLLf2YyUzDz9EotbLABxf0zIP1 Eyk2ranRHjCkmDTEr356J156wJ3yfArHW6pfOcInrabAVwZ8WXdX3tMATPIPYZ5kxxe/KGwaZ EsyVFb1SIk8ce5YIgrLm/x/I2JtYShBwcMZMEgCrxhjP3YeLYFqSxqYr7ob2HbuHOHaog/PGQ iggUSY8EyBPyLomahz1Tu5w+4hkxNmuht18WYXUnJ1iK4ZVX48dJB8eMRsQyWQcgKm/zlf5AZ fS2PVNo9QY4bBu4DlHks7XHZ7eXL048xrhAbx1DVDNXEKpawu0qcxHUCxaflQOM8cpYppfacW ousXQDg1uqTLFJKtFSaxvZwrsb8vbA2X6AB6xeVwiCHHYlT8Btw0ktDPAbTf1/2IiaVXiLhiQ ZZMZQ/8H6Sz9CZmO0N15tNySKlX3tDXsOeOfnq0TqjLTwIsV2h058/zU000snN6K7XZ1uda7Z 9+SEfRU/n4ZhqSGPoVKNyQIHXEl2d4w7dPAdYRW9XB415sqSEap2Zyh0c7U79CT4LqyPTIbYn 2SOS8jgjGDTgnxM7ZZX+ORQrhAxDz1X6EBFBEVhNVU3YxHiGOOxujja8yvckLwS1qFGyN2XB4 790Ruvvt9JJ64CEXBM3KT+/4dfpt2V24JqneLg5PC1NlmnTs3m7E91RuujU= Archived-At: Cc: "oauth@ietf.org" , =?UTF-8?Q?Rolando_Mart=c3=adnez?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:11:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XaLranqAxA7OPHfP7J5B3XHrNPBJ8djKV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Would it make sense to add an OAuth day to the OpenID Summit to prepare the IETF meeting, to play around with code, etc? On 01/15/2016 01:58 PM, John Bradley wrote: > Yes I am going. >=20 > The University of Chile and RedHat are sponsoring a one day OpenID Summ= it on Mar 31. >=20 > I will send the registration info to the list once we have it up. >=20 > Anyone interested should email myself or Rolando who is cc=E2=80=99d on= this. >=20 > John B. >=20 >> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig wrote: >> >> Hi all, >> >> I have just requested a 2 hour meeting slot for the next IETF meeting = in >> Buenos Aires. >> >> It would be good to know whether you are planning to attend the upcomi= ng >> IETF meeting. Please drop me a private mail to tell me your plans. >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --XaLranqAxA7OPHfP7J5B3XHrNPBJ8djKV 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 iQEcBAEBCgAGBQJWmP4JAAoJEGhJURNOOiAtQuEH/3xR2uWIWxvZG/8QS66wPolv Hjy5Vd7CilyhkhJRfjeGyR1Mvv/uERJEi3pGve1SfWLFyUmNdEEPgJEAzrjVxk/p oZO8lFvliV/hL0vGFe0IMamCdeaZvaJmYcZMa96pLVLEW2PKaIajnPbqIkckvKng z+UXmYMthpF/BOGsQx/7lXhy7JR4RjrFTtHgNyJci+sc5Z37wmMXwssLZp96/PqA mR2pCFeBF8HiYB0g2lhxnm8jz2S8TrBPG5qdkdeK1OHaHEgSFvprua6zvrDHDOjK 8xbHuWYFKcsMTiffSv8QIpVVH80XpgIk+oaTvAyllljTzLM+LPlFuSdbtj5X0L0= =eOUN -----END PGP SIGNATURE----- --XaLranqAxA7OPHfP7J5B3XHrNPBJ8djKV-- From nobody Fri Jan 15 06:13:09 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2DC1B2D60 for ; Fri, 15 Jan 2016 06:13:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smiVUX7SNyhR for ; Fri, 15 Jan 2016 06:13:06 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::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 2178E1B2D5D for ; Fri, 15 Jan 2016 06:13:06 -0800 (PST) Received: by mail-lb0-x22c.google.com with SMTP id cl12so98001183lbc.1 for ; Fri, 15 Jan 2016 06:13:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J/wc9nwsDUq0Wcln7GIABfDYJ5fTpYwcxVIp332t9+w=; b=k6quSjRX4CEr2ZLSBY4JSiPWZZ6X3nzLyoI/ficvCFZUxXzYBfIKxxaEwB7WRWVBl1 m4w+qIEwaWnO3Suf9hLzZSDepcjV9Ci5dTZGYhWuoGCsk2icD9OtlE1W0Qg352XreZxw lLeNFfgdNKQNUVS9mUgSP8AYukkENVJyGMEY83XgYCGKQuxrbfnU54VQa5rqU5CpLGsX AmS7VXhDXy10XZBFTLYhqY3xFIs2XyXqNVGlFT/nHNVwm5N/HwA79RVQm45wTmED2g4B qHXh2wYdl8rfBlSTIGUdoq2RHnD9pFmvKfRoD0D1e4aYNboqWN2lpS6OvYzrQw4mRKhm NU/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=J/wc9nwsDUq0Wcln7GIABfDYJ5fTpYwcxVIp332t9+w=; b=QRMC0CcIRgpDqsh7CC8boZcd2TZe0/RgNys3hQGi+7eQHUkELV/oaw9dAMCaMdEv2i OKs0uS0CKd75CmitoWX8mlcKbn05fejXny9nWaXvJj9eM5lj1mjV9j2Q5y//TsNs89bw hktyLQMwict/HinGgo4jaLsDVGVIVtRbOSKb8qXppoaR1Pexma2IHIF0sQUNo4Q295zS uf+BTSPSHdvxlnw9QP84LvBBKI2oVYi0jbU8mGP7k8GwSBa7ahw6MlAJGO0BFeaAY2Z8 nHyxRqFRcG3b72xIik/59mXEEZ5IQL82RbItFpH6mh9LNohUh/Ok3mYZMownJADW9TFX IkZw== X-Gm-Message-State: AG10YOS5BQ8XhPggckkHUxCOUQsmtArT7ejk0t8YUucXya0vRqoF0Z4SEl3n8ohiU8teFGFOVfhOrX5cHSykNg== MIME-Version: 1.0 X-Received: by 10.112.180.7 with SMTP id dk7mr2789364lbc.65.1452867184314; Fri, 15 Jan 2016 06:13:04 -0800 (PST) Received: by 10.114.217.34 with HTTP; Fri, 15 Jan 2016 06:13:04 -0800 (PST) Received: by 10.114.217.34 with HTTP; Fri, 15 Jan 2016 06:13:04 -0800 (PST) In-Reply-To: <5698CB3D.1030306@gmail.com> References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> Date: Fri, 15 Jan 2016 16:13:04 +0200 Message-ID: From: Buhake Sindi To: Sergey Beryozkin Content-Type: multipart/alternative; boundary=089e0112cad06d520805296000a3 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:13:08 -0000 --089e0112cad06d520805296000a3 Content-Type: text/plain; charset=UTF-8 Hi, Are you not mistaking this with RFC 7662? :-) Kind Regards, Buhake Sindi On 15 Jan 2016 12:34, "Sergey Beryozkin" wrote: > Hi All, > > I'm reviewing RFC 7622 as we are going ahead with implementing it. > I have a question: > > 1. Token Hint in the introspection request. > The spec mentions 'refresh_token' as one of the possible values. But a > protected resource does not see a refresh token (ever ?), it is Access > Token service which does. > When would a protected resource use a 'refresh_token' hint when requesting > an introspection response ? > > Thanks, Sergey > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --089e0112cad06d520805296000a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

Are you not mistaking this with RFC 7662? :-)

Kind Regards,

Buhake Sindi

On 15 Jan 2016 12:34, "Sergey Beryozkin&quo= t; <sberyozkin@gmail.com>= wrote:
Hi All,

I'm reviewing RFC 7622 as we are going ahead with implementing it.
I have a question:

1. Token Hint in the introspection request.
The spec mentions 'refresh_token' as one of the possible values. Bu= t a protected resource does not see a refresh token (ever ?), it is Access = Token service which does.
When would a protected resource use a 'refresh_token' hint when req= uesting an introspection response ?

Thanks, Sergey


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--089e0112cad06d520805296000a3-- From nobody Fri Jan 15 06:15:07 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B101B2D67 for ; Fri, 15 Jan 2016 06:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEW183W3Vfex for ; Fri, 15 Jan 2016 06:15:04 -0800 (PST) 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 6C1991B2D60 for ; Fri, 15 Jan 2016 06:15:04 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id f206so26654666wmf.0 for ; Fri, 15 Jan 2016 06:15:04 -0800 (PST) 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-type:content-transfer-encoding; bh=yj7q7vspNN9bn591zrbypIsNOsAt0eY4AilwKVxdT2g=; b=afYtEgO0qi/uTe1xjiF1jP69oMN8A2zaMRtpM9ilu2ZqEMbnpa+MJK0WdIRuhN28bm /hujJqCe2EK6n80M+bwKTWoJ7O75MvgWMYP1eYGEC1o1xnU/4ILMHfbkBaY6+02hfE2v G0Z8+T2OG6/PmH5dIZY0F8pJDLT4ckOMACnUeAik42mU+m+uZ4U4Z1a2TLCoQOvQ1ja0 ygQvD1VUyGnFpToxmKkKr/uUFYJf0fdvF6jtbCFeU+a5IDOvRYZ+N8xAApkAYr+5RIBt aHWMZr59eUiSiDcEg2WQfJvDao9tF1Cu2YPc1nbVXL4zC2T9QfQf9PHtPl1hFfmcAe9s F0kQ== 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-type :content-transfer-encoding; bh=yj7q7vspNN9bn591zrbypIsNOsAt0eY4AilwKVxdT2g=; b=GJCiy5CxoHZW4PeMxTOfh7BirT0dSIm/2payD586rxN1Lz/REShJ+y4UldRF6nGyKk oNxC7uonapxTUAY310Gy6KDkaENllQmOSnpjgXGLyblh/ByaJZ7XObE2t9Zs/PEHFeww ooHgUtlViB152ESSnKO2oIURAebVvDD2Gnya7s4Tuxcd2Dclt0h4dW/iN9+Yvsj5jkvK b/SbCGh9QquqwxL56GCbxHrvSNSWRJA/aIH2JNO/lgFlGKx1EP4nnWVDhzZ+let9lSFK 1oKNBBSHRtgPU+6aAIDQDQycTjo+Igd/HsUVwC7T7qXbtH9Eq1qgtQves7MszRuPffE2 EWoA== X-Gm-Message-State: AG10YORpqjnWbJvs/lJZ+HiE2mO5P2ueznp8jl/4jNGmiIgig05hGRLE17nR4pSY+XRRAA== X-Received: by 10.28.113.220 with SMTP id d89mr3834553wmi.56.1452867303084; Fri, 15 Jan 2016 06:15:03 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id 75sm2712404wmo.22.2016.01.15.06.15.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 06:15:02 -0800 (PST) To: Buhake Sindi References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> From: Sergey Beryozkin Message-ID: <5698FEE5.9050305@gmail.com> Date: Fri, 15 Jan 2016 14:15:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:15:06 -0000 Ouch, you are right, sorry for the confusion, Thanks, Sergey On 15/01/16 14:13, Buhake Sindi wrote: > Hi, > > Are you not mistaking this with RFC 7662? :-) > > Kind Regards, > > Buhake Sindi > > On 15 Jan 2016 12:34, "Sergey Beryozkin" > wrote: > > Hi All, > > I'm reviewing RFC 7622 as we are going ahead with implementing it. > I have a question: > > 1. Token Hint in the introspection request. > The spec mentions 'refresh_token' as one of the possible values. But > a protected resource does not see a refresh token (ever ?), it is > Access Token service which does. > When would a protected resource use a 'refresh_token' hint when > requesting an introspection response ? > > Thanks, Sergey > > > _______________________________________________ > 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 Jan 15 06:21:26 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2A81B2D56 for ; Fri, 15 Jan 2016 06:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DofNwxzLG7Vu for ; Fri, 15 Jan 2016 06:21:22 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 51DC71B2D70 for ; Fri, 15 Jan 2016 06:21:22 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id c192so283684516lfe.2 for ; Fri, 15 Jan 2016 06:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=4BSacrtK+LKaFYS8m7ZNUcdc9rkGZA3nrzFGUcrsdmo=; b=E/vcP0/LSoUKjxenmPbQDUc+i+N6eOXNIzSj+gc+B0PLHm/Aum4H+i63Lx0A1dKsp0 gqNDdPcOYyJ7VYBxjpiKSG2PStWBlAxPzE+tC6X+cq4Jb0Tu/3156Z5p6VSc/rmh6RKp O0JRUewJHguSXCCtADBgFxPkSqSqG9IxIgO+rDTXHHMpj7jdAtJ53io+oNTWRMA/d8Og IlS1Df2Q06W+hR5EC2lvYb0oFwEFXX0SWomnsH6AwZykjzcs52+vqJgstJeavd9nsgPM lD16uv9AvtIIMimNHWgPGRzPUA9oTO/cREuRJp6v4b82pmPRR8Pv6taVRumbdh0syu/j EQLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4BSacrtK+LKaFYS8m7ZNUcdc9rkGZA3nrzFGUcrsdmo=; b=Q1yoStQy6Usmt/Pwzh0Q+dV9mkGQIe1H2J5ryp5xPGOUX3nGYLthu1bDZKZnDFBcE0 FUaTrrJDdQAfR8Urif6Dxr7hHJ2Os+D5v+oP6rO6x5Zkeaglq1ijrXG4XT8gN6IlMmkU tHrwUGhC2/B2GDqeWOlGaKCLTnHJAyUU22FcNx8Spli+R0J2b7rE6J2yOL4/buxs4nNL N3CZBA4zqcPmFPThO3hhp+dzlh2Fklw3QPCt03H6mL8suVvG6ImnSqykoTavY2Zas7Co rWlwhP5wRvG2AamH3QFADP7WKIV4H/DcIsXPcRszBrVPaKQCSedH29gHkgVpMzVaYbIH pA5g== X-Gm-Message-State: ALoCoQlRlanaiiVl2dFn4WpoK41MO89weP4oc43S7j41SGw7FdFo5WftaAnSIogrC4YhQlIx6wU5U2/YCBBPkjOTkSSq/tYbmA== X-Received: by 10.25.41.203 with SMTP id p194mr3400016lfp.135.1452867680472; Fri, 15 Jan 2016 06:21:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.217.34 with HTTP; Fri, 15 Jan 2016 06:21:00 -0800 (PST) In-Reply-To: <5698FEE5.9050305@gmail.com> References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <5698FEE5.9050305@gmail.com> From: Buhake Sindi Date: Fri, 15 Jan 2016 16:21:00 +0200 Message-ID: To: Sergey Beryozkin Content-Type: multipart/alternative; boundary=001a11411620001ac80529601e09 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:21:25 -0000 --001a11411620001ac80529601e09 Content-Type: text/plain; charset=UTF-8 Hi, Was just reading the specification (RFC 7662) and the following link "breaks" Chapter 2.3 2.3 . Error Response If the protected resource uses OAuth 2.0 client credentials to authenticate to the introspection endpoint and its credentials are invalid, the authorization server responds with an HTTP 401 (Unauthorized) as described in Section 5.2 of OAuth 2.0 [RFC6749 ]. Richer Standards Track [Page 8] ------------------------------ RFC 7662 OAuth Introspection October 2015 If the protected resource uses an OAuth 2.0 bearer token to authorize its call to the introspection endpoint and the token used for authorization does not contain sufficient privileges or is otherwise invalid for this request, the authorization server responds with an HTTP 401 code as described in Section 3 of OAuth 2.0 Bearer Token Usage [RFC6750 ]. The link of [Section 5.2] and [Section 3] both points to the same link (of RFC 7662) instead of the specified RFC. E.g. There is no Section 5.2 on RFC 7662 but the link points to it. Kind Regards, Buhake Sindi On 15 January 2016 at 16:15, Sergey Beryozkin wrote: > Ouch, you are right, sorry for the confusion, > Thanks, Sergey > On 15/01/16 14:13, Buhake Sindi wrote: > >> Hi, >> >> Are you not mistaking this with RFC 7662? :-) >> >> Kind Regards, >> >> Buhake Sindi >> >> On 15 Jan 2016 12:34, "Sergey Beryozkin" > > wrote: >> >> Hi All, >> >> I'm reviewing RFC 7622 as we are going ahead with implementing it. >> I have a question: >> >> 1. Token Hint in the introspection request. >> The spec mentions 'refresh_token' as one of the possible values. But >> a protected resource does not see a refresh token (ever ?), it is >> Access Token service which does. >> When would a protected resource use a 'refresh_token' hint when >> requesting an introspection response ? >> >> Thanks, Sergey >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ > --001a11411620001ac80529601e09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Was just reading the specification = (RFC 7662) and the following link "breaks"

Chapter 2.3


<=
a class=3D"" name=3D"section-2.3" href=3D"https://tools.ietf.org/html/rfc76=
62#section-2.3" style=3D"color:black;text-decoration:none">2.3.  Error =
Response


   If the protected resource uses OAuth 2.0 client credentials to
   authenticate to the introspection endpoint and its credentials are
   invalid, the authorization server responds with an HTTP 401
   (Unauthorized) as described in Section 5.2 of OAuth 2.0 [RFC6749].





Richer                   =
    Standards Track                    [Page 8]
 
RFC 7662       =
            OAuth Introspection              October 2015


   If the protected resource uses an OAuth 2.0 bearer token to authorize
   its call to the introspection endpoint and the token used for
   authorization does not contain sufficient privileges or is otherwise
   invalid for this request, the authorization server responds with an
   HTTP 401 code as described in Section 3 of OAuth 2.0 Bearer Token
   Usage [RFC6750]=
.

The link of [Sec=
tion 5.2] and [Section 3] both points to the same link (of RFC 7662) instea=
d of the specified RFC. E.g. There is no Section 5.2 on RFC 7662 but the li=
nk points to it.

=

Kind Regards,

=


Buhake Sindi


=
On 15 January 2016 at 16:15, Sergey Beryozkin <sberyozkin@gmail.com> wrote:
Ouch, you are right, sorry for the confusion,
Thanks, Sergey
On 15/01/16 14:13, Buhake Sindi wrote:
Hi,

Are you not mistaking this with RFC 7662? :-)

Kind Regards,

Buhake Sindi

On 15 Jan 2016 12:34, "Sergey Beryozkin" <sberyozkin@gmail.com
 <mailto:sberyo= zkin@gmail.com>> wrote:

=C2=A0 =C2=A0 Hi All,

=C2=A0 =C2=A0 I'm reviewing RFC 7622 as we are going ahead with impleme= nting it.
=C2=A0 =C2=A0 I have a question:

=C2=A0 =C2=A0 1. Token Hint in the introspection request.
=C2=A0 =C2=A0 The spec mentions 'refresh_token' as one of the possi= ble values. But
=C2=A0 =C2=A0 a protected resource does not see a refresh token (ever ?), i= t is
=C2=A0 =C2=A0 Access Token service which does.
=C2=A0 =C2=A0 When would a protected resource use a 'refresh_token'= hint when
=C2=A0 =C2=A0 requesting an introspection response ?

=C2=A0 =C2=A0 Thanks, Sergey


=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 OAuth mailing list
=C2=A0 =C2=A0 OAuth@iet= f.org <mailto:OA= uth@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/oau= th



--
Sergey Beryozkin

Talend Community Coders
= http://coders.talend.com/

--001a11411620001ac80529601e09-- From nobody Fri Jan 15 06:21:47 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28ADB1B2D77 for ; Fri, 15 Jan 2016 06:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN7faXhLf4Dj for ; Fri, 15 Jan 2016 06:21:44 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::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 8E77B1B2D76 for ; Fri, 15 Jan 2016 06:21:44 -0800 (PST) Received: by mail-yk0-x22c.google.com with SMTP id a85so466038544ykb.1 for ; Fri, 15 Jan 2016 06:21:44 -0800 (PST) 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:date:message-id:subject:from:to :cc:content-type; bh=wmzDUSrNNwxw85UXuf5rovfiTtvZy9f3/NWcuaKdkKc=; b=w7JPk6DlxdYbnztXSNVcdad5firRYTpVc1lyigxovKHAxgnjp1flMkSWygD/V5kgZ7 CqK9/yKujXZidHgGddQBOLw78FqoCUTlBHcKt9uk7dnRasqSrcGyjigJsh2IWNdGy3Oa BzJakwS/Sa84kzwAcCBsxs7yk56hGfwwVRq3eq9PHkVdoMBik1uKRBtSig3w+7ARPDju XFLR44CkJQhnNaGYeBYlPSC3BTnTlHyRrYtmGYlHUDDfoySC3AbYHndlsJOoHTrQE6Xq XDmGFIy6NyKbiqeXnjAo28P3//tllNU2rTh+IRDhDUNGixGcAk//4i7yoaJH6OIIJgib AXdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wmzDUSrNNwxw85UXuf5rovfiTtvZy9f3/NWcuaKdkKc=; b=i2gG9xbYBEKdvgixeV0/ZKtMTT2C7nNRPXGnvf7hU6AnR92GF4yOnS2DaE+6Lp3F/2 IdbwAhebv9XDTLGe3JueaUzPmkhjbsW0tPOjVNoP5077Yt339RetqGy7CylCLd/olzne KGjL34eRMhV2cgjE+Wxpl2vRqtlkZ7wNFT09E4brmFT2whgGOBYA8AkGJuZQQPpLVmUe LLPro+Tq3u4iUynFNCEgV1TcgXuhvBMktgcSOI5fBxA9wBtD0N38OgjWp9DH88bdzdTp TIMec1K0+fklWueJl1L1TT5ROEO3AaCdEydpinGwBoomCTpJGDm/fGQjws+J5hfYMYbG RQDw== X-Gm-Message-State: ALoCoQnHiabhfEBmgJeQO3jWKR2jdWof/kXUxOMjDbJ+He1vy0u0sdgfw0iQ30BwzaqGqG1lZFLHRZEWOd85k3BJlPKN0yT6Sw== MIME-Version: 1.0 X-Received: by 10.13.210.7 with SMTP id u7mr7514934ywd.100.1452867703848; Fri, 15 Jan 2016 06:21:43 -0800 (PST) Received: by 10.37.207.87 with HTTP; Fri, 15 Jan 2016 06:21:43 -0800 (PST) Received: by 10.37.207.87 with HTTP; Fri, 15 Jan 2016 06:21:43 -0800 (PST) In-Reply-To: <5698FE08.8020804@gmx.net> References: <5698D322.6030206@gmx.net> <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> <5698FE08.8020804@gmx.net> Date: Fri, 15 Jan 2016 11:21:43 -0300 Message-ID: From: John Bradley To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a114e7e7864f2800529601f34 Archived-At: Cc: IETF oauth WG , =?UTF-8?Q?Rolando_Mart=C3=ADnez?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:21:46 -0000 --001a114e7e7864f2800529601f34 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The Friday is available. We can find space if there is interest. I was expecting you to be doing some 100k wine run on the Friday. John B. On Jan 15, 2016 9:11 AM, "Hannes Tschofenig" wrote: > Would it make sense to add an OAuth day to the OpenID Summit to prepare > the IETF meeting, to play around with code, etc? > > On 01/15/2016 01:58 PM, John Bradley wrote: > > Yes I am going. > > > > The University of Chile and RedHat are sponsoring a one day OpenID > Summit on Mar 31. > > > > I will send the registration info to the list once we have it up. > > > > Anyone interested should email myself or Rolando who is cc=E2=80=99d on= this. > > > > John B. > > > >> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> > >> Hi all, > >> > >> I have just requested a 2 hour meeting slot for the next IETF meeting = in > >> Buenos Aires. > >> > >> It would be good to know whether you are planning to attend the upcomi= ng > >> IETF meeting. Please drop me a private mail to tell me your plans. > >> > >> Ciao > >> Hannes > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > --001a114e7e7864f2800529601f34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

The Friday is available. We can find space if there is inter= est.=C2=A0=C2=A0 I was expecting you to be doing some 100k wine run on the = Friday.

John B.

On Jan 15, 2016 9:11 AM, "Hannes Tschofenig= " <hannes.tschofenig@g= mx.net> wrote:
hannes.tschofenig@gmx.net> wrote:
>>
>> Hi all,
>>
>> I have just requested a 2 hour meeting slot for the next IETF meet= ing in
>> Buenos Aires.
>>
>> It would be good to know whether you are planning to attend the up= coming
>> IETF meeting. Please drop me a private mail to tell me your plans.=
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >

--001a114e7e7864f2800529601f34-- From nobody Fri Jan 15 06:25:37 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECACB1B2D84 for ; Fri, 15 Jan 2016 06:25:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A9WHu1BMx6z for ; Fri, 15 Jan 2016 06:25:35 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E7E1B2D7B for ; Fri, 15 Jan 2016 06:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4790; q=dns/txt; s=iport; t=1452867934; x=1454077534; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JUkflMrjAr/oc5KMdHrchqYKL8XdvoFHNuE+2/Pf4Qg=; b=iObD/jS032YOsRTDwd4R4LSEXuQmDRFa9ndFAR3QEn6ZIck8GmOjXItN qB8WT6OrFV2T1qfbM5tYcmqIjWmmeD4cJF4bk1HrLg8Ic+jUDig6j2HKg EQmw9O9vn5AOgYi6UyYdRQY3CkqgYlzqNqeYWllvs/pn8zaXsekrjyM11 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQBhAJlW/5JdJa1egzpSbYhYsy4BD?= =?us-ascii?q?YFjGAEJhW0CgTQ4FAEBAQEBAQGBCoQ1AQEEAQEBawsQAgEIBAoKJwcnCxQRAgQ?= =?us-ascii?q?OBYgUAxIOwQcBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZVgg8IgmiCT4FXEAIBS?= =?us-ascii?q?4MegRsFjXyFF4QGAY1dgV6ERIhfimyDcAEgAQFChApyhjEBAQE?= X-IronPort-AV: E=Sophos;i="5.22,299,1449532800"; d="scan'208,217";a="226360125" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2016 14:25:33 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u0FEPXP5009777 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 15 Jan 2016 14:25:33 GMT Received: from xch-aln-004.cisco.com (173.36.7.14) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 15 Jan 2016 08:25:33 -0600 Received: from xch-aln-004.cisco.com ([173.36.7.14]) by XCH-ALN-004.cisco.com ([173.36.7.14]) with mapi id 15.00.1104.009; Fri, 15 Jan 2016 08:25:33 -0600 From: "Klaas Wierenga (kwiereng)" To: John Bradley Thread-Topic: [OAUTH-WG] IETF 95 - Buenos Aires Thread-Index: AQHRT4USMSoKGK6+dkadDqEaZCfWEJ787kWAgAAUfACAAALngP//nH3M Date: Fri, 15 Jan 2016 14:25:32 +0000 Message-ID: <06DBC883-D856-4457-85AE-C05520C6951A@cisco.com> References: <5698D322.6030206@gmx.net> <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> <5698FE08.8020804@gmx.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_06DBC883D856445785AEC05520C6951Aciscocom_" MIME-Version: 1.0 Archived-At: Cc: IETF oauth WG , =?iso-8859-1?Q?Rolando_Mart=EDnez?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:25:37 -0000 --_000_06DBC883D856445785AEC05520C6951Aciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No, Hannes wants to run from Santiago to Buenos Aires ;-) Sent from my iPhone On 15 Jan 2016, at 15:22, John Bradley > wrote: The Friday is available. We can find space if there is interest. I was ex= pecting you to be doing some 100k wine run on the Friday. John B. On Jan 15, 2016 9:11 AM, "Hannes Tschofenig" > wrote: Would it make sense to add an OAuth day to the OpenID Summit to prepare the IETF meeting, to play around with code, etc? On 01/15/2016 01:58 PM, John Bradley wrote: > Yes I am going. > > The University of Chile and RedHat are sponsoring a one day OpenID Summit= on Mar 31. > > I will send the registration info to the list once we have it up. > > Anyone interested should email myself or Rolando who is cc'd on this. > > John B. > >> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig > wrote: >> >> Hi all, >> >> I have just requested a 2 hour meeting slot for the next IETF meeting in >> Buenos Aires. >> >> It would be good to know whether you are planning to attend the upcoming >> IETF meeting. Please drop me a private mail to tell me your plans. >> >> Ciao >> Hannes >> >> _______________________________________________ >> 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 --_000_06DBC883D856445785AEC05520C6951Aciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
No, Hannes wants to run from Santiago to Buenos Aires ;-)

Sent from my iPhone

On 15 Jan 2016, at 15:22, John Bradley <ve7jtb@ve7jtb.com> wrote:

The Friday is available. We can find space if there is inter= est.   I was expecting you to be doing some 100k wine run on the = Friday.

John B.

On Jan 15, 2016 9:11 AM, "Hannes Tschofenig= " <hannes.tschofenig@g= mx.net> wrote:
Would it make sense to add an OAuth day to the OpenID Summit to prepare
the IETF meeting, to play around with code, etc?

On 01/15/2016 01:58 PM, John Bradley wrote:
> Yes I am going.
>
> The University of Chile and RedHat are sponsoring a one day OpenID Sum= mit on Mar 31.
>
> I will send the registration info to the list once we have it up.
>
> Anyone interested should email myself or Rolando who is cc’d on = this.
>
> John B.
>
>> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>
>> Hi all,
>>
>> I have just requested a 2 hour meeting slot for the next IETF meet= ing in
>> Buenos Aires.
>>
>> It would be good to know whether you are planning to attend the up= coming
>> IETF meeting. Please drop me a private mail to tell me your plans.=
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.i= etf.org/mailman/listinfo/oauth
--_000_06DBC883D856445785AEC05520C6951Aciscocom_-- From nobody Fri Jan 15 06:33:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947BD1B2DAB for ; Fri, 15 Jan 2016 06:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw7aIf2J_IAL for ; Fri, 15 Jan 2016 06:33:30 -0800 (PST) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::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 6C4CE1B2D99 for ; Fri, 15 Jan 2016 06:33:30 -0800 (PST) Received: by mail-yk0-x234.google.com with SMTP id k129so521754614yke.0 for ; Fri, 15 Jan 2016 06:33:30 -0800 (PST) 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:date:message-id:subject:from:to :cc:content-type; bh=K5sWDsxzE3e80K2q4ltrfGBJqHnIqG9jNrVuMmW/4DM=; b=0iSyyGvx/MxlgbyqW9jSv7yYqD9V4FoS8oVhCGRynKywGpcQ/GKRbkmm3q0Yj5vH50 xBdUknk6+4FlZq9zuHtI3MxgGAPNRAPkIsYAULO5Ca1tgVu1+bwUdmAF1s3TIHe1pwRG 6gnndLYHb4YTrn7/yWTOXUDjbgfnALK1ZQAOaMkPBqznotTOqv5xIUyAS4ICGRMLTba7 XmYmqJmUuW93OTH3n+r4NvxN974WZuuOlEjU5r9ZNEznVZYTOzA76UUmgV8Uozu2soGH zA5W72NID1p2QyDVaeNWs4t/cazWKYBZdbcNm++64cZ3Npv9sICVectCpFR9OCgtMQAf L7sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K5sWDsxzE3e80K2q4ltrfGBJqHnIqG9jNrVuMmW/4DM=; b=bnUHahhPyXVQ2fKkDWExbQlVbA37ckVGiLDLq1KZLDmi6Lu5xx7FGHXh0hBUZAAXsI gwVP1PtAO0xbb8bE7FZLnj2jsLyUKf1JYSXjh+wfrr+sj9CTQOd87rWSATcsZI8x5co1 a5P2kFiQR3xzzF4Lp30hiNx1XcYEQrTjpAxl3nGP1rH+kLePej71SP3PQQCIHYv7uAS/ GPueQgIgkbQRU4lpbcd338ijIv/nRSDKe/sHrqSrM9l648x6Tyfy1Bd3zLZ39bRcdedy vWofqxfbyoWxbn7oUlt3ml8ZJGm9BS3S3wU0x7bcYEyWcohKdxHT5ux2D/uCGCxCe99g kTKw== X-Gm-Message-State: ALoCoQlpg3XUPZLbGiaUPPtTO57P0aR3MjZZ6kEVcxIbG9Q5hx5MWNinCELzDEfxtAPyYiXIBpjVwYNnES22mL9Uoo2LoaYWxA== MIME-Version: 1.0 X-Received: by 10.129.155.14 with SMTP id s14mr7394671ywg.317.1452868409502; Fri, 15 Jan 2016 06:33:29 -0800 (PST) Received: by 10.37.207.87 with HTTP; Fri, 15 Jan 2016 06:33:28 -0800 (PST) Received: by 10.37.207.87 with HTTP; Fri, 15 Jan 2016 06:33:28 -0800 (PST) In-Reply-To: <06DBC883-D856-4457-85AE-C05520C6951A@cisco.com> References: <5698D322.6030206@gmx.net> <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> <5698FE08.8020804@gmx.net> <06DBC883-D856-4457-85AE-C05520C6951A@cisco.com> Date: Fri, 15 Jan 2016 11:33:28 -0300 Message-ID: From: John Bradley To: "Klaas Wierenga (kwiereng)" Content-Type: multipart/alternative; boundary=94eb2c0b8d04745dee05296049d0 Archived-At: Cc: IETF oauth WG , =?UTF-8?Q?Rolando_Mart=C3=ADnez?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:33:36 -0000 --94eb2c0b8d04745dee05296049d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It is about a 13day walk with a really big hill (Andies) that he would need to get over. If he came a week early and had a water carrier he might make it depending on route. I would not dare him on it! I am not going to be his water carrier! On Jan 15, 2016 9:25 AM, "Klaas Wierenga (kwiereng)" wrote: > No, Hannes wants to run from Santiago to Buenos Aires ;-) > > Sent from my iPhone > > On 15 Jan 2016, at 15:22, John Bradley wrote: > > The Friday is available. We can find space if there is interest. I was > expecting you to be doing some 100k wine run on the Friday. > > John B. > On Jan 15, 2016 9:11 AM, "Hannes Tschofenig" > wrote: > >> Would it make sense to add an OAuth day to the OpenID Summit to prepare >> the IETF meeting, to play around with code, etc? >> >> On 01/15/2016 01:58 PM, John Bradley wrote: >> > Yes I am going. >> > >> > The University of Chile and RedHat are sponsoring a one day OpenID >> Summit on Mar 31. >> > >> > I will send the registration info to the list once we have it up. >> > >> > Anyone interested should email myself or Rolando who is cc=E2=80=99d o= n this. >> > >> > John B. >> > >> >> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig < >> hannes.tschofenig@gmx.net> wrote: >> >> >> >> Hi all, >> >> >> >> I have just requested a 2 hour meeting slot for the next IETF meeting >> in >> >> Buenos Aires. >> >> >> >> It would be good to know whether you are planning to attend the >> upcoming >> >> IETF meeting. Please drop me a private mail to tell me your plans. >> >> >> >> Ciao >> >> Hannes >> >> >> >> _______________________________________________ >> >> 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 > > --94eb2c0b8d04745dee05296049d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It is about a 13day walk with a really big hill (Andies) tha= t he would need to get over.=C2=A0
If he came a week early and had a water carrier he might make it depending = on route.=C2=A0
I would not dare him on it!

I am not going to be his water carrier!

On Jan 15, 2016 9:25 AM, "Klaas Wierenga (k= wiereng)" <kwiereng@cisco.com= > wrote:
No, Hannes wants to run from Santiago to Buenos Aires ;-)

Sent from my iPhone

On 15 Jan 2016, at 15:22, John Bradley <ve7jtb@ve7jtb.com> wrote:

The Friday is available. We can find space if there is inter= est.=C2=A0=C2=A0 I was expecting you to be doing some 100k wine run on the = Friday.

John B.

On Jan 15, 2016 9:11 AM, "Hannes Tschofenig= " <h= annes.tschofenig@gmx.net> wrote:
Would it make sense to add an OAuth day to the OpenID Summit to prepare
the IETF meeting, to play around with code, etc?

On 01/15/2016 01:58 PM, John Bradley wrote:
> Yes I am going.
>
> The University of Chile and RedHat are sponsoring a one day OpenID Sum= mit on Mar 31.
>
> I will send the registration info to the list once we have it up.
>
> Anyone interested should email myself or Rolando who is cc=E2=80=99d o= n this.
>
> John B.
>
>> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>
>> Hi all,
>>
>> I have just requested a 2 hour meeting slot for the next IETF meet= ing in
>> Buenos Aires.
>>
>> It would be good to know whether you are planning to attend the up= coming
>> IETF meeting. Please drop me a private mail to tell me your plans.=
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> 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
--94eb2c0b8d04745dee05296049d0-- From nobody Fri Jan 15 06:36:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1DE1A8791 for ; Fri, 15 Jan 2016 06:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeCVSIJZtgjo for ; Fri, 15 Jan 2016 06:36:40 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::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 86C401A86E3 for ; Fri, 15 Jan 2016 06:36:40 -0800 (PST) Received: by mail-yk0-x22e.google.com with SMTP id k129so521861924yke.0 for ; Fri, 15 Jan 2016 06:36:40 -0800 (PST) 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:date:message-id:subject:from:to :cc:content-type; bh=ZUc+C9cyX/hpHXC/wqHseDJE/Zma6yIUINmtN2EN3WM=; b=09vynnU1OnqZ8VE8J8a+IrZTf2y/aXq0zcj839t2HFIuEDmBnG7Xi+yiAQswjU6CYd dWUR7uxSnGgiRNd2zs3IjM4Lf48KO7TW5GjOdDAkberz3jeO58DMcSJRT1s/cLULMIP0 oWhhYyJAkiuClQbDX58P2AO3TwRyMRfsV0jt1DaHc9mvIleDjO9VN/czTddnzYtjYZOP 96k9U0fnE9B4dZkfoSeaM9M8RTsVMzlhTyCZClUntK7BwKkxWT/YDQ3kVAMjRkK4za9Z MIpaIElu2wmjfQvEVotTHpXm1KBA5VFNNm4TqWt8sVS+VChyWsWtal1Qe1az7qPOKMdf 3xjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZUc+C9cyX/hpHXC/wqHseDJE/Zma6yIUINmtN2EN3WM=; b=bDA6kIqoQxIc6nKxZOBaV+7Y0JeDJdA/vyQ6jWJ22UK3FyWinCBu7aQRlmGw6Oztpj dqyUK5HLtgfaf5bvvb3EeMwVMHMSrqDYcQPM4IxHx5uJvfj6hDEDOxKVSAxwU1LjXYKP +WcaJt8v/mfHvvXvq7Agj3/qV3kWsrqQ1s01mWS+B03QrvO9XAVCGG6uAjAE5w1ZqFIb UBhreVPuESYU/I71pAMzv8UYQZir9mvJaNKK3UQAvAYoWu6Oj7TC0Tgv7j2xe3I7DPSv Yzo1a+WsFCyZqxxvtoAiCIp58RXUhAgiddPhqk1X1Yq5T2400LWWwg8csntXMN/UrxBK hotQ== X-Gm-Message-State: ALoCoQk0gDBCUAFxYIQpUO53VGc0ZLNz4HZibJ+wIkJFiggFkE9benzRiTqcCnvgIxhr5Pzn6GWKqV2bI6/RRnAkS/Q4rO0atg== MIME-Version: 1.0 X-Received: by 10.129.110.137 with SMTP id j131mr7608526ywc.203.1452868599863; Fri, 15 Jan 2016 06:36:39 -0800 (PST) Received: by 10.37.207.87 with HTTP; Fri, 15 Jan 2016 06:36:39 -0800 (PST) Received: by 10.37.207.87 with HTTP; Fri, 15 Jan 2016 06:36:39 -0800 (PST) In-Reply-To: References: <5698D322.6030206@gmx.net> <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> <5698FE08.8020804@gmx.net> <06DBC883-D856-4457-85AE-C05520C6951A@cisco.com> Date: Fri, 15 Jan 2016 11:36:39 -0300 Message-ID: From: John Bradley To: "Klaas Wierenga (kwiereng)" Content-Type: multipart/alternative; boundary=001a1146f750cd0da3052960548a Archived-At: Cc: IETF oauth WG , =?UTF-8?Q?Rolando_Mart=C3=ADnez?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:36:42 -0000 --001a1146f750cd0da3052960548a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable PS it is about a 19h senic bus ride over the Andies taking a not direct route via Mendoza, for anyone wanting a bus option. I am planing to fly myself. Lots of flights on the domestic airlines. John B. On Jan 15, 2016 9:33 AM, "John Bradley" wrote: > It is about a 13day walk with a really big hill (Andies) that he would > need to get over. > If he came a week early and had a water carrier he might make it dependin= g > on route. > I would not dare him on it! > > I am not going to be his water carrier! > > On Jan 15, 2016 9:25 AM, "Klaas Wierenga (kwiereng)" > wrote: > >> No, Hannes wants to run from Santiago to Buenos Aires ;-) >> >> Sent from my iPhone >> >> On 15 Jan 2016, at 15:22, John Bradley wrote: >> >> The Friday is available. We can find space if there is interest. I was >> expecting you to be doing some 100k wine run on the Friday. >> >> John B. >> On Jan 15, 2016 9:11 AM, "Hannes Tschofenig" >> wrote: >> >>> Would it make sense to add an OAuth day to the OpenID Summit to prepare >>> the IETF meeting, to play around with code, etc? >>> >>> On 01/15/2016 01:58 PM, John Bradley wrote: >>> > Yes I am going. >>> > >>> > The University of Chile and RedHat are sponsoring a one day OpenID >>> Summit on Mar 31. >>> > >>> > I will send the registration info to the list once we have it up. >>> > >>> > Anyone interested should email myself or Rolando who is cc=E2=80=99d = on this. >>> > >>> > John B. >>> > >>> >> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig < >>> hannes.tschofenig@gmx.net> wrote: >>> >> >>> >> Hi all, >>> >> >>> >> I have just requested a 2 hour meeting slot for the next IETF meetin= g >>> in >>> >> Buenos Aires. >>> >> >>> >> It would be good to know whether you are planning to attend the >>> upcoming >>> >> IETF meeting. Please drop me a private mail to tell me your plans. >>> >> >>> >> Ciao >>> >> Hannes >>> >> >>> >> _______________________________________________ >>> >> 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 >> >> --001a1146f750cd0da3052960548a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

PS it is about a 19h senic bus ride over the Andies taking a= not direct route via Mendoza, for anyone wanting a bus option.

I am planing to fly myself.=C2=A0 Lots of flights on the dom= estic airlines.

John B.

On Jan 15, 2016 9:33 AM, "John Bradley"= ; <ve7jtb@ve7jtb.com> wrote:=

It i= s about a 13day walk with a really big hill (Andies) that he would need to = get over.=C2=A0
If he came a week early and had a water carrier he might make it depending = on route.=C2=A0
I would not dare him on it!

I am not going to be his water carrier!

On Jan 15, 2016 9:25 AM, "Klaas Wierenga (k= wiereng)" <= kwiereng@cisco.com> wrote:
No, Hannes wants to run from Santiago to Buenos Aires ;-)

Sent from my iPhone

On 15 Jan 2016, at 15:22, John Bradley <ve7jtb@ve7jtb.com> wrote:

The Friday is available. We can find space if there is inter= est.=C2=A0=C2=A0 I was expecting you to be doing some 100k wine run on the = Friday.

John B.

On Jan 15, 2016 9:11 AM, "Hannes Tschofenig= " <h= annes.tschofenig@gmx.net> wrote:
Would it make sense to add an OAuth day to the OpenID Summit to prepare
the IETF meeting, to play around with code, etc?

On 01/15/2016 01:58 PM, John Bradley wrote:
> Yes I am going.
>
> The University of Chile and RedHat are sponsoring a one day OpenID Sum= mit on Mar 31.
>
> I will send the registration info to the list once we have it up.
>
> Anyone interested should email myself or Rolando who is cc=E2=80=99d o= n this.
>
> John B.
>
>> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>
>> Hi all,
>>
>> I have just requested a 2 hour meeting slot for the next IETF meet= ing in
>> Buenos Aires.
>>
>> It would be good to know whether you are planning to attend the up= coming
>> IETF meeting. Please drop me a private mail to tell me your plans.=
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> 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
--001a1146f750cd0da3052960548a-- From nobody Fri Jan 15 06:44:40 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A8B1ACE39 for ; Fri, 15 Jan 2016 06:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC_QwhkKqW2H for ; Fri, 15 Jan 2016 06:44:37 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d: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 64C3C1ACE38 for ; Fri, 15 Jan 2016 06:44:37 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id q19so263175644qke.3 for ; Fri, 15 Jan 2016 06:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=umeIK9stWWLPXHwRQ4buEygY44S7+V4WYo0NRzA0dNM=; b=zB8npcf23dNEW0VC73Qw3rGupSNEXrtJqThMKb1Yqb6bf2yR/5OF/dHGLJdMgJkb9d DNAp0sawlnALbf8h5tgNoZbOMk/OAfh2psySLXvFPh/dMF25k1JVl4yJnPh/in4x8M+W WWvr7M1eZCqJ24k2uxwfkoxA7A9veU6KWQalP1baMqb7+g33oTofCgAkj5jp0lBzsU4C NSxIOzjDg9Onln8BaH3AXtukJlnLQ6USs2oRmuEG6EBZrxu0XrXgiIyzoQShymUXszLD Q5A7RbnMmnnpi5vZzMyt5mRqhO3CJu3WoOQ9HQo9TWfI3htv2jnrkC/8rqGHBeWR/S1H /rew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=umeIK9stWWLPXHwRQ4buEygY44S7+V4WYo0NRzA0dNM=; b=Puv7/NZGpH4643OjK3X5pJw+fJro0Hkg2HCg/TWk1Fpi4FuTJri+vrSQOJCnpt641M j00LhIaQiFz31cVaw/yt6FFUTim2+vcQxR20XhsT4WztzFbPRlhVPi/KaLB0UWsncijy fZNCEPcr7Mf3QXgUJxrJvNlWvcbR4dSMT4Cfk0hwiAnIrAs9UNkV31J/cqQwbejIijv5 7EiMa3st/I3YeHcbVXtT7jsv2GzO/hqWRjHFqNLd+X4zX5rWksGMOXlHhDRo8HzZUgJA dxkLUkq/gjTm3k0GTbUvEgpOVcUzLGBE/DFUb5q3GaeHxkSqkfasA+bzAf4J/RbTckiN QkvQ== X-Gm-Message-State: ALoCoQk5lefzS7WirnxWiMfW9jPW7PcRiFBHULUIh93WTEW9gfJSgjTcwcD0cb7fk/up2qH8D1Pt4daHiWYk5zrsPVvOamdbig== X-Received: by 10.55.31.9 with SMTP id f9mr13742953qkf.5.1452869076282; Fri, 15 Jan 2016 06:44:36 -0800 (PST) Received: from [107.17.140.60] ([107.17.140.60]) by smtp.gmail.com with ESMTPSA id c2sm4641377qkb.41.2016.01.15.06.44.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 06:44:35 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_A3700AFB-7924-45EF-96DC-F96AD11E98F9" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: Date: Fri, 15 Jan 2016 09:44:34 -0500 Message-Id: <60119AA4-AD27-4C60-BD7E-B0C1D784AB35@ve7jtb.com> References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <5698FEE5.9050305@gmail.com> To: Buhake Sindi X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:44:40 -0000 --Apple-Mail=_A3700AFB-7924-45EF-96DC-F96AD11E98F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Currently the canonical form of RFC is ASCII and there is a external = tool that tries to do HTML markup on the ascii version. When authoring something that works in english may well not get the = right HTML markup. The Authors do there best but there is no way to fix by editing the HTML = as a reasonable person might expect. The process is changing to make the XML the canonical form so that HTML = can be produced with correct markup. Going forward I hope these markup problems are eliminated in new drafts. John B. > On Jan 15, 2016, at 9:21 AM, Buhake Sindi wrote: >=20 > Hi, >=20 > Was just reading the specification (RFC 7662) and the following link = "breaks" >=20 > Chapter 2.3 >=20 >=20 > 2.3 . Error Response >=20 > If the protected resource uses OAuth 2.0 client credentials to > authenticate to the introspection endpoint and its credentials are > invalid, the authorization server responds with an HTTP 401 > (Unauthorized) as described in Section 5.2 = of OAuth 2.0 [RFC6749 = ]. >=20 >=20 >=20 >=20 >=20 > Richer Standards Track [Page = 8] > > RFC 7662 OAuth = Introspection October 2015 >=20 >=20 > If the protected resource uses an OAuth 2.0 bearer token to = authorize > its call to the introspection endpoint and the token used for > authorization does not contain sufficient privileges or is = otherwise > invalid for this request, the authorization server responds with an > HTTP 401 code as described in Section 3 = of OAuth 2.0 Bearer = Token > Usage [RFC6750 ]. >=20 > The link of [Section 5.2] and [Section 3] both points to the same link = (of RFC 7662) instead of the specified RFC. E.g. There is no Section 5.2 = on RFC 7662 but the link points to it. >=20 >=20 > Kind Regards, >=20 >=20 > Buhake Sindi >=20 >=20 > On 15 January 2016 at 16:15, Sergey Beryozkin > wrote: > Ouch, you are right, sorry for the confusion, > Thanks, Sergey > On 15/01/16 14:13, Buhake Sindi wrote: > Hi, >=20 > Are you not mistaking this with RFC 7662? :-) >=20 > Kind Regards, >=20 > Buhake Sindi >=20 > On 15 Jan 2016 12:34, "Sergey Beryozkin" > >> wrote: >=20 > Hi All, >=20 > I'm reviewing RFC 7622 as we are going ahead with implementing it. > I have a question: >=20 > 1. Token Hint in the introspection request. > The spec mentions 'refresh_token' as one of the possible values. = But > a protected resource does not see a refresh token (ever ?), it is > Access Token service which does. > When would a protected resource use a 'refresh_token' hint when > requesting an introspection response ? >=20 > Thanks, Sergey >=20 >=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 --Apple-Mail=_A3700AFB-7924-45EF-96DC-F96AD11E98F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Currently the canonical form of RFC is ASCII and there is a = external tool that tries to do HTML markup on the ascii version.

When authoring something = that works in english may well not get the right HTML markup.
The Authors do there best but there is no way to fix by = editing the HTML as a reasonable person might expect.

The process is changing = to make the XML the canonical form so that HTML can be produced with = correct markup.

Going forward I hope these markup problems are eliminated in = new drafts.

John= B.

On Jan 15, 2016, at 9:21 AM, Buhake Sindi = <buhake@gmail.com> wrote:

Hi,

Was = just reading the specification (RFC 7662) and the following link = "breaks"

Chapter= 2.3


2.3.  Error Response

   If the protected resource uses OAuth 2.0 client credentials to
   authenticate to the introspection endpoint and its credentials are
   invalid, the authorization server responds with an HTTP 401
   (Unauthorized) as described in Section 5.2 of OAuth 2.0 [RFC6749].





Richer                 =
      Standards Track                    [Page 8]
 
RFC 7662                 =
  OAuth Introspection              October 2015


   If the protected resource uses an OAuth 2.0 bearer token to authorize
   its call to the introspection endpoint and the token used for
   authorization does not contain sufficient privileges or is otherwise
   invalid for this request, the authorization server responds with an
   HTTP 401 code as described in Section =
3 of OAuth 2.0 Bearer Token
   Usage [RFC6750].

The link of [Section 5.2] and =
[Section 3] both points to the same link (of RFC 7662) instead of the =
specified RFC. E.g. There is no Section 5.2 on RFC 7662 but the link =
points to it.


Kind Regards,


Buhake Sindi


On 15 January 2016 at 16:15, = Sergey Beryozkin <sberyozkin@gmail.com> wrote:
Ouch, you are right, = sorry for the confusion,
Thanks, Sergey
On 15/01/16 14:13, Buhake Sindi wrote:
Hi,

Are you not mistaking this with RFC 7662? :-)

Kind Regards,

Buhake Sindi

On 15 Jan 2016 12:34, "Sergey Beryozkin" <sberyozkin@gmail.com
= <mailto:sberyozkin@gmail.com>> wrote:

    Hi All,

    I'm reviewing RFC 7622 as we are going ahead with = implementing it.
    I have a question:

    1. Token Hint in the introspection request.
    The spec mentions 'refresh_token' as one of the possible = values. But
    a protected resource does not see a refresh token (ever = ?), it is
    Access Token service which does.
    When would a protected resource use a 'refresh_token' hint = when
    requesting an introspection response ?

    Thanks, Sergey


    _______________________________________________
    OAuth mailing list
     OAuth@ietf.org <mailto: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

= --Apple-Mail=_A3700AFB-7924-45EF-96DC-F96AD11E98F9-- From nobody Fri Jan 15 06:51:02 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21C41ACE48 for ; Fri, 15 Jan 2016 06:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzifUsvLGkJu for ; Fri, 15 Jan 2016 06:50:59 -0800 (PST) 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 279C11ACDFF for ; Fri, 15 Jan 2016 06:50:59 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id y67so54251032qkc.2 for ; Fri, 15 Jan 2016 06:50:59 -0800 (PST) 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-type; bh=Gse6wql1/PVnX0ermPlU7xru9ElXDS02zkVm5GsgH8M=; b=c+qhPkpgyxmEgdEm+Je09uVVRZ8QR6BCWlnW9ZI0baNHJ2N+omdQ+OUwL6t6sbLLM9 DcD2isittE/P6n/AR5be51cTK5Ftj2axckOknsUNnxVL6gKsdPDAMZQWuhkrH0BvfheW HIVMEldTKsLUE5b3zlvaOcG/c8sCBuw0R+Q/D8Ij6hl/mf+h+cLIYo1NUY/aiZryjs/3 Q3r/XFpOXdQFj2pjjvZ26Bs/AYaoTnsdWHtYuz6p6549nOa3DTjyQGZGhyrCfwi5jNB5 dT4G9sf/IsNhu+mlknTBiZ73v/9CK9W86FdPTUkm2zgD7ZG/peXP9uhk61PU4RuK5NLK Brpw== 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-type; bh=Gse6wql1/PVnX0ermPlU7xru9ElXDS02zkVm5GsgH8M=; b=hs4kReoU3SBZXQMEWR+AfUZk6qEE4xgx4g/K+e+x5JGgDeK/poc5sWMQYia3DZUzqV MCKZTTpIlxWtH7UWIB4aMfczfHvNG/8V1zM0g84d1MHpA6Z7zXe+7nFBRkJDoTcYcngW SEbhKgMIxa9TBQcxmyQSlkVc3pNWASgWaN4+YZbeCXczUsAMKpoUHn+dWgG4+1mXBL51 g3pFvtJ/cyuDlkS1D1QHQ3qf8WFa4WyeZM+dNhHw9Q6rq39lF25ljyFs0OWjQx3zJCra qmKx0mRt5JPT+pU+F6NPESjUPFbvHDK7RS64qeQ99l3OmLrSvsSt30eh7z+e8KYPGCG0 CB3g== X-Gm-Message-State: ALoCoQmDK6IHXuctUmHlMKuxLhx5D+kHFXQ13IUzOhdxtz40LQtp0Z6ux/iZGwaUg5sZ/0X/mEqZEws9zZBqpqMUczLwmaRE5Q== X-Received: by 10.55.77.17 with SMTP id a17mr13383572qkb.40.1452869458291; Fri, 15 Jan 2016 06:50:58 -0800 (PST) Received: from [192.168.1.65] (CPE84948c5cbf81-CM84948c5cbf80.cpe.net.cable.rogers.com. [99.224.83.138]) by smtp.googlemail.com with ESMTPSA id w145sm4596957qhw.36.2016.01.15.06.50.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Jan 2016 06:50:57 -0800 (PST) To: John Bradley , "Klaas Wierenga (kwiereng)" References: <5698D322.6030206@gmx.net> <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> <5698FE08.8020804@gmx.net> <06DBC883-D856-4457-85AE-C05520C6951A@cisco.com> From: Paul Madsen Message-ID: <5699074F.40906@gmail.com> Date: Fri, 15 Jan 2016 09:50:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------070108010803070301000103" Archived-At: Cc: IETF oauth WG , =?UTF-8?Q?Rolando_Mart=c3=adnez?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:51:01 -0000 This is a multi-part message in MIME format. --------------070108010803070301000103 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit John, could you not supply a donkey to carry Hannes' luggage? or is it a BYOD instance? On 1/15/16 9:33 AM, John Bradley wrote: > > It is about a 13day walk with a really big hill (Andies) that he would > need to get over. > If he came a week early and had a water carrier he might make it > depending on route. > I would not dare him on it! > > I am not going to be his water carrier! > > On Jan 15, 2016 9:25 AM, "Klaas Wierenga (kwiereng)" > > wrote: > > No, Hannes wants to run from Santiago to Buenos Aires ;-) > > Sent from my iPhone > > On 15 Jan 2016, at 15:22, John Bradley > wrote: > >> The Friday is available. We can find space if there is >> interest. I was expecting you to be doing some 100k wine run on >> the Friday. >> >> John B. >> >> On Jan 15, 2016 9:11 AM, "Hannes Tschofenig" >> > wrote: >> >> Would it make sense to add an OAuth day to the OpenID Summit >> to prepare >> the IETF meeting, to play around with code, etc? >> >> On 01/15/2016 01:58 PM, John Bradley wrote: >> > Yes I am going. >> > >> > The University of Chile and RedHat are sponsoring a one day >> OpenID Summit on Mar 31. >> > >> > I will send the registration info to the list once we have >> it up. >> > >> > Anyone interested should email myself or Rolando who is >> cc’d on this. >> > >> > John B. >> > >> >> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig >> > > wrote: >> >> >> >> Hi all, >> >> >> >> I have just requested a 2 hour meeting slot for the next >> IETF meeting in >> >> Buenos Aires. >> >> >> >> It would be good to know whether you are planning to >> attend the upcoming >> >> IETF meeting. Please drop me a private mail to tell me >> your plans. >> >> >> >> Ciao >> >> Hannes >> >> >> >> _______________________________________________ >> >> 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 --------------070108010803070301000103 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit John, could you not supply a donkey to carry Hannes' luggage? or is it a BYOD instance?

On 1/15/16 9:33 AM, John Bradley wrote:

It is about a 13day walk with a really big hill (Andies) that he would need to get over. 
If he came a week early and had a water carrier he might make it depending on route. 
I would not dare him on it!

I am not going to be his water carrier!

On Jan 15, 2016 9:25 AM, "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> wrote:
No, Hannes wants to run from Santiago to Buenos Aires ;-)

Sent from my iPhone

On 15 Jan 2016, at 15:22, John Bradley <ve7jtb@ve7jtb.com> wrote:

The Friday is available. We can find space if there is interest.   I was expecting you to be doing some 100k wine run on the Friday.

John B.

On Jan 15, 2016 9:11 AM, "Hannes Tschofenig" <hannes.tschofenig@gmx.net> wrote:
Would it make sense to add an OAuth day to the OpenID Summit to prepare
the IETF meeting, to play around with code, etc?

On 01/15/2016 01:58 PM, John Bradley wrote:
> Yes I am going.
>
> The University of Chile and RedHat are sponsoring a one day OpenID Summit on Mar 31.
>
> I will send the registration info to the list once we have it up.
>
> Anyone interested should email myself or Rolando who is cc’d on this.
>
> John B.
>
>> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>
>> Hi all,
>>
>> I have just requested a 2 hour meeting slot for the next IETF meeting in
>> Buenos Aires.
>>
>> It would be good to know whether you are planning to attend the upcoming
>> IETF meeting. Please drop me a private mail to tell me your plans.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> 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

--------------070108010803070301000103-- From nobody Fri Jan 15 06:55:29 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388591ACE8B for ; Fri, 15 Jan 2016 06:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t60InHyUoOWh for ; Fri, 15 Jan 2016 06:55:26 -0800 (PST) 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 D37DD1ACE80 for ; Fri, 15 Jan 2016 06:55:25 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id q19so263291640qke.3 for ; Fri, 15 Jan 2016 06:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=k3wOueu3G0z/52PqtBCSiZOuyEZoETwWlGloQzausSE=; b=HNtGPhWRUD5mRyY/Zxn3Y27oet7rfjALcchBH0aOjwmKbdsD+wZBIyd4M1YaOaSrXM rvrcwStfN+4sg2ayAzgmsw8qHrs+YAxeJHas89QbgaiehNF12wHTiq83TaY4AzsGzr0E VbiMJ9SjxnutLgpCwy/8j9UTUE7Py2szBxh4kzKnCAcsolmmIzNeKzRPsS0H8ESGkwgI COgWzkmVCzd/2m7AuZNfKz7NS3b0s3QX+xD/R5KXwPw/91+Al+HysYAvzXV9sKF2ez04 lxu2c7w2NJGvuFgk6Y3hFfG2/DiVAr0FkwIBq5KuSUAxTzlB2h2cI7IoZT0gB47ql5yN PsYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=k3wOueu3G0z/52PqtBCSiZOuyEZoETwWlGloQzausSE=; b=B1yxKXmUM036yuAiXb1CXSMuDL/V7Ivdn+SlpV5TPQdE7dn4e4HI1isMV3V/iSCw9Y RrFxJb4Odmdnh/0YYO2S+TYU1i7swmlMtr6srY1/V1YGA20SP1WoDKWdgdqZWCETWG5l 7E8BlNbn5Na4tPc/f7H504spJR9JRsNtKSBvOSpVcB4b1WZSTYp5/cf9t/vS4ftDkA5p MpIieqZsMZpnrnR1qgr7E6Ddu1WU0V5Wws5DFE59aJTilcL+DUCo5OxDMDqrI7XM575E pfkWJ8UB4Rou2JS+rhR24mtUImgNEZiEeA5VRsKNRR13QxsHFRw3A/SChtb4hH0i/IhL PKLw== X-Gm-Message-State: ALoCoQkqSoAZApqHitnQD3Jl2LxxvWV840Nm4dMj4ESh6R+MOE3HtF3QcuzvjrHANN1op8+9Xl8hiuxJp7fdMcmyd4KWPS9evQ== X-Received: by 10.55.43.160 with SMTP id r32mr13912249qkr.57.1452869724685; Fri, 15 Jan 2016 06:55:24 -0800 (PST) Received: from [107.17.140.60] ([107.17.140.60]) by smtp.gmail.com with ESMTPSA id a5sm4627383qga.46.2016.01.15.06.55.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 06:55:24 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_24CE6187-C9AC-4D09-AD03-E8B9E54539DA" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <5699074F.40906@gmail.com> Date: Fri, 15 Jan 2016 09:55:22 -0500 Message-Id: <3BCAF093-5390-41E7-9513-C17306EE751D@ve7jtb.com> References: <5698D322.6030206@gmx.net> <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> <5698FE08.8020804@gmx.net> <06DBC883-D856-4457-85AE-C05520C6951A@cisco.com> <5699074F.40906@gmail.com> To: Paul Madsen X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "Klaas Wierenga \(kwiereng\)" , IETF oauth WG , =?utf-8?Q?Rolando_Mart=C3=ADnez?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:55:28 -0000 --Apple-Mail=_24CE6187-C9AC-4D09-AD03-E8B9E54539DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 For the direct route I would take a llama as the pack animal. I could = arrange one , but it would need to be returned for the deposit.=20 I don=92t know of anyone with one way llama rentals. (he could purchase = it outright and eat it in BA I suppose.) I am willing to provide reasonable support, but I am not going over the = glacier with him. John B. > On Jan 15, 2016, at 9:50 AM, Paul Madsen = wrote: >=20 > John, could you not supply a donkey to carry Hannes' luggage? or is it = a BYOD instance? >=20 > On 1/15/16 9:33 AM, John Bradley wrote: >> It is about a 13day walk with a really big hill (Andies) that he = would need to get over. =20 >> If he came a week early and had a water carrier he might make it = depending on route. =20 >> I would not dare him on it! >>=20 >> I am not going to be his water carrier! >>=20 >> On Jan 15, 2016 9:25 AM, "Klaas Wierenga (kwiereng)" = > wrote: >> No, Hannes wants to run from Santiago to Buenos Aires ;-) >>=20 >> Sent from my iPhone >>=20 >> On 15 Jan 2016, at 15:22, John Bradley < = ve7jtb@ve7jtb.com > = wrote: >>=20 >>> The Friday is available. We can find space if there is interest. I = was expecting you to be doing some 100k wine run on the Friday. >>>=20 >>> John B. >>>=20 >>> On Jan 15, 2016 9:11 AM, "Hannes Tschofenig" = > wrote: >>> Would it make sense to add an OAuth day to the OpenID Summit to = prepare >>> the IETF meeting, to play around with code, etc? >>>=20 >>> On 01/15/2016 01:58 PM, John Bradley wrote: >>> > Yes I am going. >>> > >>> > The University of Chile and RedHat are sponsoring a one day OpenID = Summit on Mar 31. >>> > >>> > I will send the registration info to the list once we have it up. >>> > >>> > Anyone interested should email myself or Rolando who is cc=92d on = this. >>> > >>> > John B. >>> > >>> >> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig = > wrote: >>> >> >>> >> Hi all, >>> >> >>> >> I have just requested a 2 hour meeting slot for the next IETF = meeting in >>> >> Buenos Aires. >>> >> >>> >> It would be good to know whether you are planning to attend the = upcoming >>> >> IETF meeting. Please drop me a private mail to tell me your = plans. >>> >> >>> >> Ciao >>> >> Hannes >>> >> >>> >> _______________________________________________ >>> >> 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 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_24CE6187-C9AC-4D09-AD03-E8B9E54539DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 For the direct route I would take a llama as the pack animal. =   I could arrange one , but it would need to be returned for the = deposit. 
I don=92t know of anyone with one way = llama rentals.  (he could purchase it outright and eat it in BA I = suppose.)

I am = willing to provide reasonable support, but I am not going over the = glacier with him.

John B.
On Jan 15, 2016, at 9:50 AM, Paul Madsen = <paul.madsen@gmail.com> wrote:

=20 =20
John, could you not supply a donkey to carry Hannes' luggage? or is it a BYOD instance?

On 1/15/16 9:33 AM, John Bradley = wrote:

It is about a = 13day walk with a really big hill (Andies) that he would need to get over. 
If he came a week early and had a water carrier he might make it depending on route. 
I would not dare him on it!

I am = not going to be his water carrier!

On Jan 15, 2016 9:25 AM, "Klaas = Wierenga (kwiereng)" <kwiereng@cisco.com> wrote:
No, Hannes wants to run from Santiago to = Buenos Aires ;-)

Sent from my iPhone

On 15 Jan 2016, at 15:22, John Bradley <ve7jtb@ve7jtb.com> wrote:

The Friday is = available. We can find space if there is interest.   I was expecting you = to be doing some 100k wine run on the Friday.

John B.

On Jan 15, 2016 9:11 AM, "Hannes Tschofenig" <hannes.tschofenig@gmx.net> wrote:
Would it make sense to add an OAuth day to the OpenID Summit to prepare
the IETF meeting, to play around with code, etc?

On 01/15/2016 01:58 PM, John Bradley wrote:
> Yes I am going.
>
> The University of Chile and RedHat are sponsoring a one day OpenID Summit on Mar 31.
>
> I will send the registration info to the list once we have it up.
>
> Anyone interested should email myself or Rolando who is cc=92d on this.
>
> John B.
>
>> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>
>> Hi all,
>>
>> I have just requested a 2 hour meeting slot for the next IETF meeting in
>> Buenos Aires.
>>
>> It would be good to know whether you are planning to attend the upcoming
>> IETF meeting. Please drop me a private mail to tell me your plans.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> 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=_24CE6187-C9AC-4D09-AD03-E8B9E54539DA-- From nobody Fri Jan 15 06:59:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63A51AD367 for ; Fri, 15 Jan 2016 06:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SARHSoaWkUot for ; Fri, 15 Jan 2016 06:59:21 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5281AD0CD for ; Fri, 15 Jan 2016 06:59:20 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id y67so54345321qkc.2 for ; Fri, 15 Jan 2016 06:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=XeF27jR7xv/ns2tpsyMgTog8jgC1Nx6vZFP75g1Vh+4=; b=LpO956GzUkanttxEoGl747MLaTLA6NYg2oE2EQSIjOY2f+blgAQYr2InujSbiZQRJ+ 81dNMfTezpyBNVv1Gn8c7rQKq8oPJKHPW7l5X6pGFcEqiM+Tjl3kSovJ6Is/MhCbTXAg UmrpPduwDR/S9gVi/fy5D3k8QG+XChtxaqAAwNgVCHe1GJpgjRg9bBw9kqkisnrALHfS FXNh5N5pPoUJyIMLPi817EWpnPxEPSLf1E7RIDRpV9NJXCRvJ6ZnY6ADCBKVuB5Ov56q lT4RKoiDfacbgKseqFlu+yW/FvU/4RQzgoams3PsaynijMw8InMPVzL/TZtevbK4Pepu JIVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=XeF27jR7xv/ns2tpsyMgTog8jgC1Nx6vZFP75g1Vh+4=; b=eER19+/KX6NCWkt1TLHCpwDilB/Awk0+4d44VpEauLV6BxgeChVG1YyvEchVw7NatW YJiy37ExCmhxz97ZMEmTPcsN1bmhcIGbeb12hjsfCgknDQAfFCUt8wPLIajgv4Arzl7a xflP/VvnpF+3h3D10yBnDKnep0ZgUJNnewwdx0IGBMrib+toq//0q8c2mtgMnGQweDDa YWIzA8Wa1okc6LK4TTLyKPpCrb0hiEM+2x8YatvUMqHq3VtIetTaFlwSt9WYSsYQA9wq 6X09xEMjyQ8iJDUzkmUgd/kgJ8FueWP/7c6Qam0oS6oqWdvDpLnBbHnuwBs/SxqiIYRK Rh0A== X-Gm-Message-State: ALoCoQk9fhqiDXyrnBIc3qLwqAblb/gqkoRCED28H3/QWBDpTqzIXMqt18jBXn0LgIlzaZ+m3tP9JKAOksJW3h0VzGKgBytg1Q== X-Received: by 10.55.82.137 with SMTP id g131mr13568411qkb.66.1452869958660; Fri, 15 Jan 2016 06:59:18 -0800 (PST) Received: from [107.17.140.60] ([107.17.140.60]) by smtp.gmail.com with ESMTPSA id 31sm4652835qgz.8.2016.01.15.06.59.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 15 Jan 2016 06:59:17 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D29982A3-888D-49BB-87B1-A60C80D22FC7" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: John Bradley In-Reply-To: <5699074F.40906@gmail.com> Date: Fri, 15 Jan 2016 09:59:16 -0500 Message-Id: References: <5698D322.6030206@gmx.net> <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> <5698FE08.8020804@gmx.net> <06DBC883-D856-4457-85AE-C05520C6951A@cisco.com> <5699074F.40906@gmail.com> To: Paul Madsen X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "Klaas Wierenga \(kwiereng\)" , IETF oauth WG , =?utf-8?Q?Rolando_Mart=C3=ADnez?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 14:59:23 -0000 --Apple-Mail=_D29982A3-888D-49BB-87B1-A60C80D22FC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Paul if you are interested there is something more your speed. http://www.eldertreks.com/tour/ETTD000364 = > On Jan 15, 2016, at 9:50 AM, Paul Madsen = wrote: >=20 > John, could you not supply a donkey to carry Hannes' luggage? or is it = a BYOD instance? >=20 > On 1/15/16 9:33 AM, John Bradley wrote: >> It is about a 13day walk with a really big hill (Andies) that he = would need to get over. =20 >> If he came a week early and had a water carrier he might make it = depending on route. =20 >> I would not dare him on it! >>=20 >> I am not going to be his water carrier! >>=20 >> On Jan 15, 2016 9:25 AM, "Klaas Wierenga (kwiereng)" = > wrote: >> No, Hannes wants to run from Santiago to Buenos Aires ;-) >>=20 >> Sent from my iPhone >>=20 >> On 15 Jan 2016, at 15:22, John Bradley < = ve7jtb@ve7jtb.com > = wrote: >>=20 >>> The Friday is available. We can find space if there is interest. I = was expecting you to be doing some 100k wine run on the Friday. >>>=20 >>> John B. >>>=20 >>> On Jan 15, 2016 9:11 AM, "Hannes Tschofenig" = > wrote: >>> Would it make sense to add an OAuth day to the OpenID Summit to = prepare >>> the IETF meeting, to play around with code, etc? >>>=20 >>> On 01/15/2016 01:58 PM, John Bradley wrote: >>> > Yes I am going. >>> > >>> > The University of Chile and RedHat are sponsoring a one day OpenID = Summit on Mar 31. >>> > >>> > I will send the registration info to the list once we have it up. >>> > >>> > Anyone interested should email myself or Rolando who is cc=92d on = this. >>> > >>> > John B. >>> > >>> >> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig = > wrote: >>> >> >>> >> Hi all, >>> >> >>> >> I have just requested a 2 hour meeting slot for the next IETF = meeting in >>> >> Buenos Aires. >>> >> >>> >> It would be good to know whether you are planning to attend the = upcoming >>> >> IETF meeting. Please drop me a private mail to tell me your = plans. >>> >> >>> >> Ciao >>> >> Hannes >>> >> >>> >> _______________________________________________ >>> >> 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 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 --Apple-Mail=_D29982A3-888D-49BB-87B1-A60C80D22FC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Paul if you are interested there is something more your = speed.
http://www.eldertreks.com/tour/ETTD000364

On Jan 15, 2016, at 9:50 AM, Paul Madsen <paul.madsen@gmail.com> wrote:

=20 =20
John, could you not supply a donkey to carry Hannes' luggage? or is it a BYOD instance?

On 1/15/16 9:33 AM, John Bradley = wrote:

It is about a = 13day walk with a really big hill (Andies) that he would need to get over. 
If he came a week early and had a water carrier he might make it depending on route. 
I would not dare him on it!

I am = not going to be his water carrier!

On Jan 15, 2016 9:25 AM, "Klaas = Wierenga (kwiereng)" <kwiereng@cisco.com> wrote:
No, Hannes wants to run from Santiago to = Buenos Aires ;-)

Sent from my iPhone

On 15 Jan 2016, at 15:22, John Bradley <ve7jtb@ve7jtb.com> wrote:

The Friday is = available. We can find space if there is interest.   I was expecting you = to be doing some 100k wine run on the Friday.

John B.

On Jan 15, 2016 9:11 AM, "Hannes Tschofenig" <hannes.tschofenig@gmx.net> wrote:
Would it make sense to add an OAuth day to the OpenID Summit to prepare
the IETF meeting, to play around with code, etc?

On 01/15/2016 01:58 PM, John Bradley wrote:
> Yes I am going.
>
> The University of Chile and RedHat are sponsoring a one day OpenID Summit on Mar 31.
>
> I will send the registration info to the list once we have it up.
>
> Anyone interested should email myself or Rolando who is cc=92d on this.
>
> John B.
>
>> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>
>> Hi all,
>>
>> I have just requested a 2 hour meeting slot for the next IETF meeting in
>> Buenos Aires.
>>
>> It would be good to know whether you are planning to attend the upcoming
>> IETF meeting. Please drop me a private mail to tell me your plans.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> 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=_D29982A3-888D-49BB-87B1-A60C80D22FC7-- From nobody Fri Jan 15 09:16:32 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A1A1B301A for ; Fri, 15 Jan 2016 09:16:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0pG5l2jKONM for ; Fri, 15 Jan 2016 09:16:29 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865C21A1EB7 for ; Fri, 15 Jan 2016 09:16:29 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id 77so461597674ioc.2 for ; Fri, 15 Jan 2016 09:16:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RnOTeWxGjeGg9Qew8c7inffdVDE6ufKVQ/71qnT/158=; b=NmyryGhL5yQHYPMSwQVvivTia+sd9vBvgHoX6e8bEl0Uu1anQulMABmXig/jg83sZr 6r4wsvsDhyutGj1vDVoCiXNzDjIv37nQjpz3KvzCOJEoq4qFZvjznM6vf9CbgAWyU9M6 y5OlMTDI/z1/2rhmOGdD+0Kaw7Si+jITJSylU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RnOTeWxGjeGg9Qew8c7inffdVDE6ufKVQ/71qnT/158=; b=eqpA/83cGh+OcvUPXJf9Ho9kY4PA3/9ZQmxgI3OfyU6XX0iuIDLvXS2AveKFKNbrh4 WbGhmRRIKZDRDhNS9jg22FJyQ/oLUsK/RfUKVxBEtKU2EN83Uuv6SfUKK+pvdpHJmqDL 87qIX5ARuFAuppNcLXj3v4CHTgSwR+8PG8Bgw+eZVjVqa9Xu7MJytsFToMHalrgg6lUl dRPznQ9FTuXoFFfyqtvcvMIGF7qxWx+hFtlmScPGtmHy32BTg02+3o1te+4iNp4e7We4 JjB5VWtLSS01tgHRnWBqiUoZRjwrS6+g2RO7dex0IdcdObYwL0WryfbYj0Of+TVelWXU U1Zg== X-Gm-Message-State: ALoCoQk1N1uQ2mNJwSCg+BNWhkRu2TteQSAUvbUJsvAJHabVV1Nr+J6JjWJPYb8hHRN/a0vPM6LwIu/FxUqivrT/0/ua0VoxP+A5GH0Q+DNyDBFObaW8Uek= X-Received: by 10.107.3.71 with SMTP id 68mr12396933iod.48.1452878188764; Fri, 15 Jan 2016 09:16:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.212.69 with HTTP; Fri, 15 Jan 2016 09:15:59 -0800 (PST) In-Reply-To: <5698FE08.8020804@gmx.net> References: <5698D322.6030206@gmx.net> <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> <5698FE08.8020804@gmx.net> From: Brian Campbell Date: Fri, 15 Jan 2016 10:15:59 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113eb35c57fd3305296290e8 Archived-At: Cc: "oauth@ietf.org" , =?UTF-8?Q?Rolando_Mart=C3=ADne?= =?UTF-8?Q?z?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 17:16:31 -0000 --001a113eb35c57fd3305296290e8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Speaking for myself but I suspect others might be in the same boat - I'd love to see some additional time beyond the official meeting made available to try and make more progress on the open work in OAuth. But the week before IETF in a different country (even if it's only a 19h bus ride) just isn't logistically feasible for me. On Fri, Jan 15, 2016 at 7:11 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Would it make sense to add an OAuth day to the OpenID Summit to prepare > the IETF meeting, to play around with code, etc? > > On 01/15/2016 01:58 PM, John Bradley wrote: > > Yes I am going. > > > > The University of Chile and RedHat are sponsoring a one day OpenID > Summit on Mar 31. > > > > I will send the registration info to the list once we have it up. > > > > Anyone interested should email myself or Rolando who is cc=E2=80=99d on= this. > > > > John B. > > > >> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> > >> Hi all, > >> > >> I have just requested a 2 hour meeting slot for the next IETF meeting = in > >> Buenos Aires. > >> > >> It would be good to know whether you are planning to attend the upcomi= ng > >> IETF meeting. Please drop me a private mail to tell me your plans. > >> > >> Ciao > >> Hannes > >> > >> _______________________________________________ > >> 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 > > --001a113eb35c57fd3305296290e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Speaking for myself but I suspect others might be in the s= ame boat - I'd love to see some additional time beyond the official mee= ting made available to try and make more progress on the open work in OAuth= . But the week before IETF in a different country (even if it's only a = 19h bus ride) just isn't logistically feasible for me.

On Fri, Jan 15, 2016 at= 7:11 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Would it make sense to add an = OAuth day to the OpenID Summit to prepare
the IETF meeting, to play around with code, etc?

On 01/15/2016 01:58 PM, John Bradley wrote:
> Yes I am going.
>
> The University of Chile and RedHat are sponsoring a one day OpenID Sum= mit on Mar 31.
>
> I will send the registration info to the list once we have it up.
>
> Anyone interested should email myself or Rolando who is cc=E2=80=99d o= n this.
>
> John B.
>
>> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>
>> Hi all,
>>
>> I have just requested a 2 hour meeting slot for the next IETF meet= ing in
>> Buenos Aires.
>>
>> It would be good to know whether you are planning to attend the up= coming
>> IETF meeting. Please drop me a private mail to tell me your plans.=
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth<= br> >


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


--001a113eb35c57fd3305296290e8-- From nobody Fri Jan 15 12:15:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5CBA1B321C for ; Fri, 15 Jan 2016 12:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOQ0TkHbVbY0 for ; Fri, 15 Jan 2016 12:15:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9E51B3215 for ; Fri, 15 Jan 2016 12:15:39 -0800 (PST) Received: from [192.168.10.141] ([80.92.119.40]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LxPAo-1a5Psi2jxC-016zHz; Fri, 15 Jan 2016 21:15:34 +0100 To: Barry Leiba From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56995365.6030401@gmx.net> Date: Fri, 15 Jan 2016 21:15:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w8hCb33IUcEwp9215TInMBjr0c7taxRUr" X-Provags-ID: V03:K0:H14bu2JcnClFFcc6XLRO4hB11H6Nr8EdeADjogkqKlU/fdEWOU/ A1/YXlfBiX8TnbwXmzT/UO24doQL5Kvdek10g7/I5o1KHIxZ2fd19PD1aiNjgXehudgOfQP BvTK/Dsty2/gLfvq60ke+WTRswXvE0bQDexvy3poXz6VVPv4uE7FSfWzFYxtOD8LjCObiOg ZMq8cAXB2QpCjmOzWNLEg== X-UI-Out-Filterresults: notjunk:1;V01:K0:cZvrWyPaU+0=:RmZRXJtUnSB29c8E60uRLl FlyZ8E3VpKsIpLrh/Xs+IU6jNLWSIxXzBvneN9AG+HLm9027EVQfIwmfIoNtj/XxkmUso+J+U lhyC/o0Dt94Q7AVCrUoklRmt65l07Ccz6LlE667RMsSnVRh6g440U965ZZ99WjmQMw7DrriOc igFOiZ0TmH3e+rEZdjkJGfJ3VYPw4hjIcd+90siMnb3wnZBPsbNY5ij4ByYNLAUlMCVqmcDM6 Y3/xB0SqNguG+DyKyEz9d6RniLi/sbMwgXxv7QNHGnMjf/1lK13mWSxoXIFy7O5NIoRp/JV3a wYIohud7gv3CcD30NtMnQiqjLxYtfKR9Xm/qn7MsfqDZn4rnIGLcNGsmYbzxufCBvLjvjaiZc xpiWSfGX9FtejBh1O4DPOCF+fG0+aaqOUgZTTD72oA7doy6dMud4rlTJmablpMgw8FSANR+YK 27Drcv1dNAHKWRvzBUc8SWIsrhwNr6JhsFMuxzqFEnuG6eKqk3glNAUZOX4nEzPM5oXicjGFd 1DRygFmXgzjdsryEFNjgbcZbtAzmFszAVJV4UJgDfnh+RLJPJ648IJh3fOt5wDsP32S45K6oR GjmkYfKfp1YmD6q+HC9WvDOwqDDFJtl2v45vvsz1rfFIvTDcVsY1zixNR1xyaaYhsd7dYjAK4 Ysjst5+ujw7I+/IVu/rbOVAKElTVwB0ySPO4qJ58nTnQez1JpR+5DXi5TVBlHg/LG1fuTN6ss O5kIOPfTpCHnOyzcWELoOpIognKKcC7Iawz0cW8oeM2dIx1BA6SNfsyo22M= Archived-At: Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Rechartering OAuth: New Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 20:15:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --w8hCb33IUcEwp9215TInMBjr0c7taxRUr Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Barry, as discussed today I am forwarding you the new charter text for the OAuth working group. In parallel to the IESG processing this re-chartering request we will run a call for adoption to also update the milestone list at the same tim= e. Ciao Hannes & Derek -------------------------- Charter Text The Web Authorization (OAuth) protocol allows a user to grant a third-party Web site or application access to the user's protected resources, without necessarily revealing their long-term credentials, or even their identity. For example, a photo-sharing site that supports OAuth could allow its users to use a third-party printing Web site to print their private pictures, without allowing the printing site to gain full control of the user's account and without having the user share his or her photo-sharing sites' long-term credential with the printing site. The OAuth 2.0 protocol suite already includes * a procedure for enabling a client to register with an authorization server, * a protocol for obtaining authorization tokens from an authorization server with the resource owner's consent, and * protocols for presenting these authorization tokens to protected resources for access to a resource. This protocol suite has been enhanced with functionality for interworking with legacy identity infrastructure (e.g., SAML), token revocation, token exchange, dynamic client registration, token introspection, a standardized token format with the JSON Web Token, and specifications that mitigate security attacks, such as Proof Key for Code Exchange. The ongoing standardization efforts within the OAuth working group focus on increasing interoperability of OAuth deployments and to improve security. More specifically, the working group is defining proof of possession tokens, developing a discovery mechanism, providing guidance for the use of OAuth with native apps, re-introducing the device flow used by devices with limited user interfaces, additional security enhancements for clients communicating with multiple service providers, definition of claims used with JSON Web Tokens, techniques to mitigate open redirector attacks, as well as guidance on encoding state information. For feedback and discussion about our specifications please subscribe to our public mailing list at . For security related bug reports that relate to our specifications please contact . If the reported bug report turns out to be implementation-specific we will attempt to forward it to the appropriate developers. --w8hCb33IUcEwp9215TInMBjr0c7taxRUr 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 iQEcBAEBCgAGBQJWmVNlAAoJEGhJURNOOiAtjSIH/1txQXhBj8SwJBapFqY/lRmg CfntRGqpg/6q53Tcx0ywtPlkNcroGRnrUqYuhMDQqNorMFHxM6x3lx8GIJgQ+E97 4+QeoVULDUBQuLacupYr7lCsgkYfR8Xyil7ciwxv9VgAkUzXSQ7/u7LxhR48IXqe PRwjPJaIzg/BKtxHe+HdON4NrKrAk2x7S4QJ67e9S1y3b+4TCtH4vezTNXH82OKG fGIfSpIHNXZiE7ikrtxiVYzfbK4IlNOoCDTQtYiub1sR0+sR8d8LByTKzj+JzmLa lDmTpJmCXCtKC94/WoN1bk3Cq/bkbS9RFBmX/4ZAl/knL41Gm1nIKWiRHERV/Ug= =zDf6 -----END PGP SIGNATURE----- --w8hCb33IUcEwp9215TInMBjr0c7taxRUr-- From nobody Fri Jan 15 12:37:56 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5451B3258 for ; Fri, 15 Jan 2016 12:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1P9j-XKILQ6Z for ; Fri, 15 Jan 2016 12:37:52 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E241B3257 for ; Fri, 15 Jan 2016 12:37:52 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0FKbn4h024942 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Jan 2016 20:37:50 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u0FKbnBI001790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Jan 2016 20:37:49 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u0FKbnvd002956; Fri, 15 Jan 2016 20:37:49 GMT Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Jan 2016 12:37:49 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13C75) In-Reply-To: <56995365.6030401@gmx.net> Date: Fri, 15 Jan 2016 12:37:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <14B41AE0-E8B6-4710-86D2-651E781B96F5@oracle.com> References: <56995365.6030401@gmx.net> To: Hannes Tschofenig X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: Barry Leiba , "oauth@ietf.org" Subject: Re: [OAUTH-WG] Rechartering OAuth: New Charter Text X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 20:37:54 -0000 Hannes I would like to propose a brief presentation on "events". While this might n= ot end up being oauth wg activity, I think a lot of attendees may be interes= ted.=20 We might make this one of those if we have time topics.=20 Phil > On Jan 15, 2016, at 12:15, Hannes Tschofenig w= rote: >=20 > Hi Barry, >=20 > as discussed today I am forwarding you the new charter text for the > OAuth working group. >=20 > In parallel to the IESG processing this re-chartering request we will > run a call for adoption to also update the milestone list at the same time= . >=20 > Ciao > Hannes & Derek >=20 > -------------------------- >=20 > Charter Text >=20 > The Web Authorization (OAuth) protocol allows a user to grant a > third-party Web site or application access to the user's protected > resources, without necessarily revealing their long-term credentials, > or even their identity. For example, a photo-sharing site that > supports OAuth could allow its users to use a third-party printing Web > site to print their private pictures, without allowing the printing > site to gain full control of the user's account and without having the > user share his or her photo-sharing sites' long-term credential with > the printing site. >=20 > The OAuth 2.0 protocol suite already includes >=20 > * a procedure for enabling a client to register with an authorization > server, > * a protocol for obtaining authorization tokens from an authorization > server with the resource owner's consent, and > * protocols for presenting these authorization tokens to protected > resources for access to a resource. >=20 > This protocol suite has been enhanced with functionality for > interworking with legacy identity infrastructure (e.g., SAML), token > revocation, token exchange, dynamic client registration, token > introspection, a standardized token format with the JSON Web Token, and > specifications that mitigate security attacks, such as Proof Key for > Code Exchange. >=20 > The ongoing standardization efforts within the OAuth working group > focus on increasing interoperability of OAuth deployments and to > improve security. More specifically, the working group is defining proof > of possession tokens, developing a discovery mechanism, providing > guidance for the use of OAuth with native apps, re-introducing > the device flow used by devices with limited user interfaces, additional > security enhancements for clients communicating with multiple service > providers, definition of claims used with JSON Web Tokens, techniques to > mitigate open redirector attacks, as well as guidance on encoding state > information. >=20 > For feedback and discussion about our specifications please > subscribe to our public mailing list at . >=20 > For security related bug reports that relate to our specifications > please contact . If the reported > bug report turns out to be implementation-specific we will attempt > to forward it to the appropriate developers. >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Sat Jan 16 08:02:51 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C760C1A8A45 for ; Sat, 16 Jan 2016 08:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCJ8Onhx8JMj for ; Sat, 16 Jan 2016 08:02:47 -0800 (PST) Received: from p3plsmtpa06-05.prod.phx3.secureserver.net (p3plsmtpa06-05.prod.phx3.secureserver.net [173.201.192.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8DA1A8A42 for ; Sat, 16 Jan 2016 08:02:47 -0800 (PST) Received: from [192.168.0.112] ([77.77.164.50]) by p3plsmtpa06-05.prod.phx3.secureserver.net with id 6g2l1s00B15ZTut01g2mcD; Sat, 16 Jan 2016 09:02:47 -0700 To: oauth@ietf.org References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> From: Vladimir Dzhuvinov Organization: Connect2id Ltd. Message-ID: <569A69A5.7020006@connect2id.com> Date: Sat, 16 Jan 2016 18:02:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <5698F885.3030009@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090207040008090505070309" Archived-At: Subject: Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 16:02:48 -0000 This is a cryptographically signed message in MIME format. --------------ms090207040008090505070309 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 15/01/16 15:47, Sergey Beryozkin wrote: > Hi John > > Thanks, looks like it was a last minute change because Introduction > does not explain why would clients want to use the introspection > endpoint to effectively 'unwrap' the opaque token representations. > > I have another question. How to report the expiry time in cases when > the tokens do not expire ? I'm aware of some deployments where access > tokens are only manually deleted and otherwise would not expire. > > Perhaps not reporting the expiry time is equivalent to the token never > expiring ? Or may be reporting 0 or -1 works ? The core OAuth 2.0 spec seems to imply the former: http://tools.ietf.org/html/rfc6749#section-5.1 Using a zero or negative integer may not be a good idea, as clients may just take the value as it is and add it to the current system time, concluding that the token has expired :) Cheers, Vladimir > > Thanks, Sergey > On 15/01/16 13:32, John Bradley wrote: >> Some people wanted the client to be able to use introspection. >> >> The ability to pass a refresh token is a legacy of that. A RS >> would never have a refresh token unless it is acting as a client.=20 >> That is correct. >> >> John B. >> >>> On Jan 15, 2016, at 5:34 AM, Sergey Beryozkin >>> wrote: >>> >>> Hi All, >>> >>> I'm reviewing RFC 7622 as we are going ahead with implementing it. >>> I have a question: >>> >>> 1. Token Hint in the introspection request. >>> The spec mentions 'refresh_token' as one of the possible values. But >>> a protected resource does not see a refresh token (ever ?), it is >>> Access Token service which does. >>> When would a protected resource use a 'refresh_token' hint when >>> requesting an introspection response ? >>> >>> 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 --=20 Vladimir Dzhuvinov --------------ms090207040008090505070309 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+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAxMTYxNjAyNDVaMC8GCSqGSIb3DQEJBDEiBCBHoqqsuYcVNlZ16CLOohf0nRvtEsGo nWO1fAm1SIfocDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQCNr7T4UODD cCTPr6aViTPrv+ZcwjiRoKgMhJgMha09a9+ZaGYXL+ctVuGGBomaEYXoFjr2OW0YA6r+gVv5 nain6HIBNePKYWoq2vKr+pAYMa4Ul0aDNIvdzeK7Y8EeJ4A2i+zUi3+xcFgUtgVxpKecx7+6 SB+vOLFa0CJUr/D8ktT1mXmP7ggRvwk2vd5T3+X+SMHRwKBzuh+BKgC7Vxog9GzO7N/Kwu3i e3Ez5k4u4GB/GPbRbsaRiTJVHzfEFyX3Ouj0S+mNXIX8hhUfcW1Qmkg5vSGUBa4A74zVSUUe +81RmYVfyzp9x+okBAOqdreqQCqxauCFaGqLWGcjXEqGAAAAAAAA --------------ms090207040008090505070309-- From nobody Sat Jan 16 08:14:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11311A8A51 for ; Sat, 16 Jan 2016 08:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egP-KeuZLyAQ for ; Sat, 16 Jan 2016 08:14:27 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311D61A8A4F for ; Sat, 16 Jan 2016 08:14:26 -0800 (PST) X-AuditID: 1209190c-f79c96d00000038e-a0-569a6c61e75c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 91.80.00910.16C6A965; Sat, 16 Jan 2016 11:14:25 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u0GGEOMd014282; Sat, 16 Jan 2016 11:14:25 -0500 Received: from [107.16.90.107] ([107.16.90.107]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u0GGEMBZ012216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 16 Jan 2016 11:14:24 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9C540280-AD4D-4875-B74B-C139927DF1AA"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5.2 From: Justin Richer In-Reply-To: <569A69A5.7020006@connect2id.com> Date: Sat, 16 Jan 2016 11:14:22 -0500 Message-Id: References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> To: Vladimir Dzhuvinov X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEKsWRmVeSWpSXmKPExsUixG6nrpuYMyvM4OcbOYuTb1+xWbx794HR gclj/ucWVo8lS34yBTBFcdmkpOZklqUW6dslcGU0H/7NVvBItmLR3q0sDYw/JboYOTkkBEwk 7m5pZoOwxSQu3FsPZHNxCAksZpL4dHwulLORUeLwnu0sEM5aJonWdV9ZQFqEBVwlrj08yQxi 8wroSby6dZkVpIhZYAqjxMMdf4ESHEBzpSRm7BcAqWETUJWYvqaFCcTmBKpfNq0XbDULUHzV tiuMIOXMAuoS7SddIEZaSVx/+B7qiIPMEi/X/WEFSYgIGEg8fn2eGeJsWYndvx8xTWAUnIXk jFnIzgBJMAtoSyxb+BrKNpB42vmKFcKWl9j+dg5U3FJi8cwbLBC2rcStvgVMELadxKNpi1gX MHKsYpRNya3SzU3MzClOTdYtTk7My0st0jXUy80s0UtNKd3ECIoeTkmeHYxvDiodYhTgYFTi 4d3gODNMiDWxrLgy9xCjJAeTkijvd85ZYUJ8SfkplRmJxRnxRaU5qcWHGFWAdj3asPoCoxRL Xn5eqpIIb2skUB1vSmJlVWpRPkyZNAeLkjjvt8opYUIC6YklqdmpqQWpRTBZGQ4OJQnezdlA jYJFqempFWmZOSUIaSYOzkOMEhw8QMOVQWp4iwsSc4sz0yHypxgVpcR5nUESAiCJjNI8uF5Q 0ssWiMp+xSgO9JYw71aQKh5gwoTrfgU0mAloMG/AdJDBJYkIKakGRi3nFvd5emZx/G7H2jY2 3dLefeT7WYlIS9ZKpgOuzNsT7Gbd70wK3bDeaFHVou/frxlHGGanvXFgWzsrpFLv+PQ//3pk L8Qu/ZM+MSUsduM6CY+vP4Ryak9dkdM4GD3trEQpZ6etc+R5+76rr6dGCq36v5CzUr3M6iND 6kyXc+7mHMY/ZxafUWIpzkg01GIuKk4EAGW5WopVAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 16:14:29 -0000 --Apple-Mail=_9C540280-AD4D-4875-B74B-C139927DF1AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All the values in the token introspection response are optional, except = for =93active=94. If you don=92t have anything to say about a particular = aspect of the token, or can=92t say it to the software that=92s asking, = then you generally leave it out of the response. =97 Justin > On Jan 16, 2016, at 11:02 AM, Vladimir Dzhuvinov = wrote: >=20 >=20 >=20 > On 15/01/16 15:47, Sergey Beryozkin wrote: >> Hi John >>=20 >> Thanks, looks like it was a last minute change because Introduction >> does not explain why would clients want to use the introspection >> endpoint to effectively 'unwrap' the opaque token representations. >>=20 >> I have another question. How to report the expiry time in cases when >> the tokens do not expire ? I'm aware of some deployments where access >> tokens are only manually deleted and otherwise would not expire. >>=20 >> Perhaps not reporting the expiry time is equivalent to the token = never >> expiring ? Or may be reporting 0 or -1 works ? >=20 > The core OAuth 2.0 spec seems to imply the former: >=20 > http://tools.ietf.org/html/rfc6749#section-5.1 >=20 > Using a zero or negative integer may not be a good idea, as clients = may > just take the value as it is and add it to the current system time, > concluding that the token has expired :) >=20 >=20 > Cheers, >=20 > Vladimir >=20 >=20 >>=20 >> Thanks, Sergey >> On 15/01/16 13:32, John Bradley wrote: >>> Some people wanted the client to be able to use introspection. >>>=20 >>> The ability to pass a refresh token is a legacy of that. A RS >>> would never have a refresh token unless it is acting as a client. >>> That is correct. >>>=20 >>> John B. >>>=20 >>>> On Jan 15, 2016, at 5:34 AM, Sergey Beryozkin = >>>> wrote: >>>>=20 >>>> Hi All, >>>>=20 >>>> I'm reviewing RFC 7622 as we are going ahead with implementing it. >>>> I have a question: >>>>=20 >>>> 1. Token Hint in the introspection request. >>>> The spec mentions 'refresh_token' as one of the possible values. = But >>>> a protected resource does not see a refresh token (ever ?), it is >>>> Access Token service which does. >>>> When would a protected resource use a 'refresh_token' hint when >>>> requesting an introspection response ? >>>>=20 >>>> Thanks, Sergey >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > -- > Vladimir Dzhuvinov >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_9C540280-AD4D-4875-B74B-C139927DF1AA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWmmxeAAoJEDPAngkbd+w96rQH/0xORs05BOFWq0VPYpnTJJxA 5ZWOAjsO/d/pj1YuQbBDtLG5/qt2yM3utdcUgQqMQsbHwzZc28nQEINYDw8w6u5J mCLqN0Pw9m8yeKyETObUy+YuVrAlkxh/nB9R+ydn/IxEgBkR7q8njMFfuUIW4e1g 5n4k4dWASjHbcq7wkquETKGe5JjvQSAha/WqQdtQWkHgtBgVg26DZ/N/F0lePHnL +qQqhnkasZx1MpjjeH1/V8fNP69H/Ro5WpTmtBQtoxVZD9rfuE4jGSlQcqOsgtQc n4nmXh0jUT5cu6Bw6uJVeRRy3eN2OYSSBu9u8QJ9SirxLBazqph7LHAn0wB6NxU= =yLXt -----END PGP SIGNATURE----- --Apple-Mail=_9C540280-AD4D-4875-B74B-C139927DF1AA-- From nobody Sat Jan 16 11:17:44 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2695A1A90C5 for ; Sat, 16 Jan 2016 11:17:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5Ptp917-yR1 for ; Sat, 16 Jan 2016 11:17:40 -0800 (PST) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::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 F3BB91A90C0 for ; Sat, 16 Jan 2016 11:17:39 -0800 (PST) Received: by mail-yk0-x233.google.com with SMTP id a85so498692358ykb.1 for ; Sat, 16 Jan 2016 11:17:39 -0800 (PST) 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 :content-type; bh=FCEExBvV5GlDa1YW+XHrgtpXYehGYZIxDFlFGIRsv/8=; b=ytZwBTp3oI7Qu3GblWe5BY8JOn9a3xt825Tmro7a1rcVWbWlHUP+9i4NHLY03r2cTd h3ArZ3/oTqFsrv4iGweddExria9t/ZRmM83veu/QKshQlGhVslykwo37f/7tP0BjPE+T 7q+7zpAH8H7bCKrCufKB8PCpHYGezE8XuTG9BwvgNTkdFxUUF+TYzsDmS3vJMc9u5+Wg Pc2VTm2AMlWhyaBTPxGuzWXbnyQTu83sERUa9fQI+2U3uCDHKwYvJTYyZoyLtI3pYDo1 p2Ujd/YkPVejkS7NHwkEUS7FiKeKVKTitFt9OaR0PlmzjrrGhqQ5WWOTyudkRSrAWolt axVA== 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:content-type; bh=FCEExBvV5GlDa1YW+XHrgtpXYehGYZIxDFlFGIRsv/8=; b=klZgzvRX5QZan+ssaOUH69O32bJkdJX0ici5ie1f462VysDKK0a3aSr/htHBetv3mK NeME35uyTmPAzT6qyDS8P+BDEwu2KzydT9qwCsau6WSj68JfII2nfBESe2ta3KJo5v9j /FYHflzUkg7SiW1U2nsslbGJUT263Sd6Awgnna03YPejY7zzIBO2XcZHwTgCOhP67Z8o v8DUTikC65iNS43UxK6xKV34zE0MNviwOMW3+O8UfKzkbxsHEmXoOoMmApUwl3QdhbuS +az3XKHxVz+jdcjBDuSPE+37i7vcwgPC3yGTsS+ELxB/TUeHZ6m1xG8NSsJqMFmp4FiW ER9A== X-Gm-Message-State: ALoCoQkK9vGiH3LxHVDK+/N8RXFMr+eOvxDaI6o+f5EU4sq5lhtuf+OI+kzxlXMe5AZppnlsjE+e26XTRPfbzAgFP0iCwf/5rw== X-Received: by 10.37.35.67 with SMTP id j64mr2607314ybj.35.1452971859298; Sat, 16 Jan 2016 11:17:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jason Harmon Date: Sat, 16 Jan 2016 19:17:30 +0000 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a113d50108ad04a0529785f26 Archived-At: Subject: [OAUTH-WG] Unsubscribe X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jan 2016 19:17:42 -0000 --001a113d50108ad04a0529785f26 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 15, 2016 at 14:00 wrote: > Send OAuth mailing list submissions to > oauth@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > oauth-request@ietf.org > > You can reach the person managing the list at > 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: > > 1. Re: IETF 95 - Buenos Aires (Brian Campbell) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 15 Jan 2016 10:15:59 -0700 > From: Brian Campbell > To: Hannes Tschofenig > Cc: "oauth@ietf.org" , Rolando Mart?nez > Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires > Message-ID: > UDh5hv4rbi5eq8MYdeMyt9CHhBA@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Speaking for myself but I suspect others might be in the same boat - I'd > love to see some additional time beyond the official meeting made available > to try and make more progress on the open work in OAuth. But the week > before IETF in a different country (even if it's only a 19h bus ride) just > isn't logistically feasible for me. > > On Fri, Jan 15, 2016 at 7:11 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > > > Would it make sense to add an OAuth day to the OpenID Summit to prepare > > the IETF meeting, to play around with code, etc? > > > > On 01/15/2016 01:58 PM, John Bradley wrote: > > > Yes I am going. > > > > > > The University of Chile and RedHat are sponsoring a one day OpenID > > Summit on Mar 31. > > > > > > I will send the registration info to the list once we have it up. > > > > > > Anyone interested should email myself or Rolando who is cc?d on this. > > > > > > John B. > > > > > >> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig < > > hannes.tschofenig@gmx.net> wrote: > > >> > > >> Hi all, > > >> > > >> I have just requested a 2 hour meeting slot for the next IETF meeting > in > > >> Buenos Aires. > > >> > > >> It would be good to know whether you are planning to attend the > upcoming > > >> IETF meeting. Please drop me a private mail to tell me your plans. > > >> > > >> Ciao > > >> Hannes > > >> > > >> _______________________________________________ > > >> 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 > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://mailarchive.ietf.org/arch/browse/oauth/attachments/20160115/e52131aa/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 87, Issue 23 > ************************************* > --001a113d50108ad04a0529785f26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 15, 2016 at 14:00 <oauth-request@ietf.org> wrote:
Send OAuth mailing list submissions to
=C2=A0 =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 =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 =C2=A0 oauth-request@ietf.org

You can reach the person managing the list at
=C2=A0 =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 =C2=A01. Re: IETF 95 - Buenos Aires (Brian Campbell)


----------------------------------------------------------------------

Message: 1
Date: Fri, 15 Jan 2016 10:15:59 -0700
From: Brian Campbell <bcampbell@pingidentity.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Cc: "oauth@ietf.or= g" <oauth@i= etf.org>, Rolando Mart?nez <m@rtinez.cl>
Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CA+k3eCSqy=3Dd3hzX1m2Arrc=3DUDh5hv4rbi= 5eq8MYdeMyt9CHhBA@mail.gmail.com>
Content-Type: text/plain; charset=3D"utf-8"

Speaking for myself but I suspect others might be in the same boat - I'= d
love to see some additional time beyond the official meeting made available=
to try and make more progress on the open work in OAuth. But the week
before IETF in a different country (even if it's only a 19h bus ride) j= ust
isn't logistically feasible for me.

On Fri, Jan 15, 2016 at 7:11 AM, Hannes Tschofenig <
hannes.tscho= fenig@gmx.net> wrote:

> Would it make sense to add an OAuth day to the OpenID Summit to prepar= e
> the IETF meeting, to play around with code, etc?
>
> On 01/15/2016 01:58 PM, John Bradley wrote:
> > Yes I am going.
> >
> > The University of Chile and RedHat are sponsoring a one day OpenI= D
> Summit on Mar 31.
> >
> > I will send the registration info to the list once we have it up.=
> >
> > Anyone interested should email myself or Rolando who is cc?d on t= his.
> >
> > John B.
> >
> >> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig <
> hannes.= tschofenig@gmx.net> wrote:
> >>
> >> Hi all,
> >>
> >> I have just requested a 2 hour meeting slot for the next IETF= meeting in
> >> Buenos Aires.
> >>
> >> It would be good to know whether you are planning to attend t= he upcoming
> >> IETF meeting. Please drop me a private mail to tell me your p= lans.
> >>
> >> Ciao
> >> Hannes
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@iet= f.org
> >> https://www.ietf.org/mailman/listinfo/oau= th
> >
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20160115/e52131= aa/attachment.html>

------------------------------

Subject: Digest Footer

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


------------------------------

End of OAuth Digest, Vol 87, Issue 23
*************************************
--001a113d50108ad04a0529785f26-- From nobody Sun Jan 17 22:08:37 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331421B2AAE for ; Sun, 17 Jan 2016 22:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7I9FbgLQd6L for ; Sun, 17 Jan 2016 22:08:30 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0144.outbound.protection.outlook.com [65.55.169.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246531B2AAD for ; Sun, 17 Jan 2016 22:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4cr/RQzfR7Pyr4BLJyM9GPYeS+Ljt/v2u8ourYfT6Tc=; b=WaKSDqidwvG8x8Xg3GS8krNLAP141N3gngfdi+w/PcTOkbvHoygahZXr5+hpkwIpRC7jxwW+5AVUXGnq93E1Puc3OHSV6oynH2NAtPB0F35xfRlo1VVtZgoJhD/S3VTHhuowtdLA1lk9psOOzz16OgaOnbClUjK7tjHgzQqQJsM= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1236.namprd03.prod.outlook.com (10.161.207.24) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 18 Jan 2016 06:08:27 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0365.024; Mon, 18 Jan 2016 06:08:26 +0000 From: Anthony Nadalin To: Brian Campbell , Hannes Tschofenig Thread-Topic: [OAUTH-WG] IETF 95 - Buenos Aires Thread-Index: AQHRT4US4zW+/6BgHkuvCYGkGF712Z78ibCAgAAUfACAADOXgIAD/E4Q Date: Mon, 18 Jan 2016 06:08:26 +0000 Message-ID: References: <5698D322.6030206@gmx.net> <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> <5698FE08.8020804@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: [118.163.65.13] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1236; 5:hkNqHtEg6PaI7z6TjKEu2XVvtzBkQKN4TNVdxker4D/cRT7DI+zGzHF3CKlFL5Pg1uDjo6l4o3U0+wDApO86oyNhhNITAzrFzaOt24ZiWhHaQhqkskMqtz3WTpuxkFrmx8pSZLruvSkt+2Lqp1DKyQ==; 24:yR1miUhCVLl5FzgZ/NhXp7mX/Ep+4uzwxfyq8scWVrCtO83tIhX52dzV9PNiuWiOkMP5cSYLHE/BwsQKxjA9HXZ0zXGDBzQpQeeLCRdy66k= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1236; x-ms-office365-filtering-correlation-id: 06ea97ec-eba0-42da-3c08-08d31fcdc7c0 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BN3PR0301MB1236; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1236; x-forefront-prvs: 08252193F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(24454002)(199003)(53754006)(479174004)(377454003)(52254002)(19617315012)(76576001)(106116001)(106356001)(2900100001)(15975445007)(5002640100001)(2950100001)(99286002)(122556002)(33656002)(5003600100002)(5004730100002)(40100003)(93886004)(19580405001)(19609705001)(77096005)(105586002)(87936001)(76176999)(54356999)(790700001)(189998001)(86362001)(4326007)(19300405004)(6116002)(10400500002)(74316001)(81156007)(16236675004)(97736004)(19580395003)(92566002)(1096002)(1220700001)(50986999)(2906002)(10090500001)(8990500004)(5001960100002)(19625215002)(3846002)(102836003)(86612001)(5008740100001)(66066001)(101416001)(5005710100001)(5001770100001)(10290500002)(586003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1236; H:BN3PR0301MB1234.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234DE8BA0D31AEE8321B3C8A6C00BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2016 06:08:26.6111 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1236 Archived-At: Cc: "oauth@ietf.org" , =?utf-8?B?Um9sYW5kbyBNYXJ0w61uZXo=?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 06:08:36 -0000 --_000_BN3PR0301MB1234DE8BA0D31AEE8321B3C8A6C00BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gYWZyYWlkIHRoYXQgSSB3b3VsZCBoYXZlIHRvIGFncmVlIHdpdGggQnJpYW4gKGhvcGVm dWxseSB0aGlzIGlzIG5vdCBhIHRyZW5kKQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogRnJpZGF5 LCBKYW51YXJ5IDE1LCAyMDE2IDk6MTYgQU0NClRvOiBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVz LnRzY2hvZmVuaWdAZ214Lm5ldD4NCkNjOiBvYXV0aEBpZXRmLm9yZzsgUm9sYW5kbyBNYXJ0w61u ZXogPG1AcnRpbmV6LmNsPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gSUVURiA5NSAtIEJ1ZW5v cyBBaXJlcw0KDQpTcGVha2luZyBmb3IgbXlzZWxmIGJ1dCBJIHN1c3BlY3Qgb3RoZXJzIG1pZ2h0 IGJlIGluIHRoZSBzYW1lIGJvYXQgLSBJJ2QgbG92ZSB0byBzZWUgc29tZSBhZGRpdGlvbmFsIHRp bWUgYmV5b25kIHRoZSBvZmZpY2lhbCBtZWV0aW5nIG1hZGUgYXZhaWxhYmxlIHRvIHRyeSBhbmQg bWFrZSBtb3JlIHByb2dyZXNzIG9uIHRoZSBvcGVuIHdvcmsgaW4gT0F1dGguIEJ1dCB0aGUgd2Vl ayBiZWZvcmUgSUVURiBpbiBhIGRpZmZlcmVudCBjb3VudHJ5IChldmVuIGlmIGl0J3Mgb25seSBh IDE5aCBidXMgcmlkZSkganVzdCBpc24ndCBsb2dpc3RpY2FsbHkgZmVhc2libGUgZm9yIG1lLg0K DQpPbiBGcmksIEphbiAxNSwgMjAxNiBhdCA3OjExIEFNLCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFu bmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+ IHdyb3RlOg0KV291bGQgaXQgbWFrZSBzZW5zZSB0byBhZGQgYW4gT0F1dGggZGF5IHRvIHRoZSBP cGVuSUQgU3VtbWl0IHRvIHByZXBhcmUNCnRoZSBJRVRGIG1lZXRpbmcsIHRvIHBsYXkgYXJvdW5k IHdpdGggY29kZSwgZXRjPw0KDQpPbiAwMS8xNS8yMDE2IDAxOjU4IFBNLCBKb2huIEJyYWRsZXkg d3JvdGU6DQo+IFllcyBJIGFtIGdvaW5nLg0KPg0KPiBUaGUgVW5pdmVyc2l0eSBvZiBDaGlsZSBh bmQgUmVkSGF0IGFyZSBzcG9uc29yaW5nIGEgb25lIGRheSBPcGVuSUQgU3VtbWl0IG9uIE1hciAz MS4NCj4NCj4gSSB3aWxsIHNlbmQgdGhlIHJlZ2lzdHJhdGlvbiBpbmZvIHRvIHRoZSBsaXN0IG9u Y2Ugd2UgaGF2ZSBpdCB1cC4NCj4NCj4gQW55b25lIGludGVyZXN0ZWQgc2hvdWxkIGVtYWlsIG15 c2VsZiBvciBSb2xhbmRvIHdobyBpcyBjY+KAmWQgb24gdGhpcy4NCj4NCj4gSm9obiBCLg0KPg0K Pj4gT24gSmFuIDE1LCAyMDE2LCBhdCA2OjA4IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVz LnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdy b3RlOg0KPj4NCj4+IEhpIGFsbCwNCj4+DQo+PiBJIGhhdmUganVzdCByZXF1ZXN0ZWQgYSAyIGhv dXIgbWVldGluZyBzbG90IGZvciB0aGUgbmV4dCBJRVRGIG1lZXRpbmcgaW4NCj4+IEJ1ZW5vcyBB aXJlcy4NCj4+DQo+PiBJdCB3b3VsZCBiZSBnb29kIHRvIGtub3cgd2hldGhlciB5b3UgYXJlIHBs YW5uaW5nIHRvIGF0dGVuZCB0aGUgdXBjb21pbmcNCj4+IElFVEYgbWVldGluZy4gUGxlYXNlIGRy b3AgbWUgYSBwcml2YXRlIG1haWwgdG8gdGVsbCBtZSB5b3VyIHBsYW5zLg0KPj4NCj4+IENpYW8N Cj4+IEhhbm5lcw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+IE9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0 aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2E1NDkzYjkwNTgwZTRh ZmYyYzIwMDhkMzFkY2Y5ZmJlJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2Mx JnNkYXRhPTlYczcwWWJQSFpKQzBvN0dlRGVjZWpwYXRxSjM2eERUZ2M1JTJiemFiaCUyZkRVJTNk Pg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3 LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9u eW5hZCU0MG1pY3Jvc29mdC5jb20lN2NhNTQ5M2I5MDU4MGU0YWZmMmMyMDA4ZDMxZGNmOWZiZSU3 YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT05WHM3MFliUEhaSkMw bzdHZURlY2VqcGF0cUozNnhEVGdjNSUyYnphYmglMmZEVSUzZD4NCg0K --_000_BN3PR0301MB1234DE8BA0D31AEE8321B3C8A6C00BN3PR0301MB1234_ 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 YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPknigJltIGFmcmFpZCB0aGF0IEkgd291bGQgaGF2ZSB0byBh Z3JlZSB3aXRoIEJyaWFuIChob3BlZnVsbHkgdGhpcyBpcyBub3QgYSB0cmVuZCk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBv c2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+QnJpYW4gQ2FtcGJlbGw8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBKYW51YXJ5IDE1LCAyMDE2IDk6MTYgQU08YnI+DQo8Yj5Ubzo8L2I+IEhhbm5lcyBUc2Nob2Zl bmlnICZsdDtoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Jmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1 dGhAaWV0Zi5vcmc7IFJvbGFuZG8gTWFydMOtbmV6ICZsdDttQHJ0aW5lei5jbCZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gSUVURiA5NSAtIEJ1ZW5vcyBBaXJlczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZWFraW5nIGZvciBteXNlbGYgYnV0 IEkgc3VzcGVjdCBvdGhlcnMgbWlnaHQgYmUgaW4gdGhlIHNhbWUgYm9hdCAtIEknZCBsb3ZlIHRv IHNlZSBzb21lIGFkZGl0aW9uYWwgdGltZSBiZXlvbmQgdGhlIG9mZmljaWFsIG1lZXRpbmcgbWFk ZSBhdmFpbGFibGUgdG8gdHJ5IGFuZCBtYWtlIG1vcmUgcHJvZ3Jlc3Mgb24gdGhlIG9wZW4gd29y ayBpbiBPQXV0aC4gQnV0IHRoZSB3ZWVrIGJlZm9yZSBJRVRGIGluIGENCiBkaWZmZXJlbnQgY291 bnRyeSAoZXZlbiBpZiBpdCdzIG9ubHkgYSAxOWggYnVzIHJpZGUpIGp1c3QgaXNuJ3QgbG9naXN0 aWNhbGx5IGZlYXNpYmxlIGZvciBtZS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKYW4gMTUsIDIwMTYgYXQgNzoxMSBBTSwgSGFubmVzIFRz Y2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0IiB0 YXJnZXQ9Il9ibGFuayI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIGl0 IG1ha2Ugc2Vuc2UgdG8gYWRkIGFuIE9BdXRoIGRheSB0byB0aGUgT3BlbklEIFN1bW1pdCB0byBw cmVwYXJlPGJyPg0KdGhlIElFVEYgbWVldGluZywgdG8gcGxheSBhcm91bmQgd2l0aCBjb2RlLCBl dGM/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gMDEvMTUvMjAxNiAwMTo1OCBQTSwg Sm9obiBCcmFkbGV5IHdyb3RlOjxicj4NCiZndDsgWWVzIEkgYW0gZ29pbmcuPGJyPg0KJmd0Ozxi cj4NCiZndDsgVGhlIFVuaXZlcnNpdHkgb2YgQ2hpbGUgYW5kIFJlZEhhdCBhcmUgc3BvbnNvcmlu ZyBhIG9uZSBkYXkgT3BlbklEIFN1bW1pdCBvbiBNYXIgMzEuPGJyPg0KJmd0Ozxicj4NCiZndDsg SSB3aWxsIHNlbmQgdGhlIHJlZ2lzdHJhdGlvbiBpbmZvIHRvIHRoZSBsaXN0IG9uY2Ugd2UgaGF2 ZSBpdCB1cC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBbnlvbmUgaW50ZXJlc3RlZCBzaG91bGQgZW1h aWwgbXlzZWxmIG9yIFJvbGFuZG8gd2hvIGlzIGNj4oCZZCBvbiB0aGlzLjxicj4NCiZndDs8YnI+ DQomZ3Q7IEpvaG4gQi48YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgT24gSmFuIDE1LCAyMDE2LCBh dCA2OjA4IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50 c2Nob2ZlbmlnQGdteC5uZXQiPmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7IEkgaGF2ZSBqdXN0IHJlcXVlc3RlZCBhIDIgaG91ciBtZWV0aW5nIHNsb3QgZm9y IHRoZSBuZXh0IElFVEYgbWVldGluZyBpbjxicj4NCiZndDsmZ3Q7IEJ1ZW5vcyBBaXJlcy48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEl0IHdvdWxkIGJlIGdvb2QgdG8ga25vdyB3aGV0aGVy IHlvdSBhcmUgcGxhbm5pbmcgdG8gYXR0ZW5kIHRoZSB1cGNvbWluZzxicj4NCiZndDsmZ3Q7IElF VEYgbWVldGluZy4gUGxlYXNlIGRyb3AgbWUgYSBwcml2YXRlIG1haWwgdG8gdGVsbCBtZSB5b3Vy IHBsYW5zLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQ2lhbzxicj4NCiZndDsmZ3Q7IEhh bm5lczxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYu b3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFp bG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNy b3NvZnQuY29tJTdjYTU0OTNiOTA1ODBlNGFmZjJjMjAwOGQzMWRjZjlmYmUlN2M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPTlYczcwWWJQSFpKQzBvN0dlRGVj ZWpwYXRxSjM2eERUZ2M1JTJiemFiaCUyZkRVJTNkIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUy ZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAx JTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2E1NDkzYjkwNTgwZTRhZmYyYzIwMDhk MzFkY2Y5ZmJlJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0 YT05WHM3MFliUEhaSkMwbzdHZURlY2VqcGF0cUozNnhEVGdjNSUyYnphYmglMmZEVSUzZCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_BN3PR0301MB1234DE8BA0D31AEE8321B3C8A6C00BN3PR0301MB1234_-- From nobody Sun Jan 17 22:13:29 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2F41B2AC8 for ; Sun, 17 Jan 2016 22:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmztH328Tzlj for ; Sun, 17 Jan 2016 22:13:26 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099051B2AC6 for ; Sun, 17 Jan 2016 22:13:25 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0I6DLg9011062 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 18 Jan 2016 06:13:22 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u0I6DLgq021613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Jan 2016 06:13:21 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u0I6DLwp000485; Mon, 18 Jan 2016 06:13:21 GMT Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 17 Jan 2016 22:13:21 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-0544FB12-03E9-47D3-9FA5-06D7789A21BF Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13C75) In-Reply-To: Date: Sun, 17 Jan 2016 22:13:18 -0800 Content-Transfer-Encoding: 7bit Message-Id: <67DFA9BA-CC42-414E-B88A-A6943ECD8DA4@oracle.com> References: <5698D322.6030206@gmx.net> <98165008-9094-4FF4-8627-4B1CBE014939@ve7jtb.com> <5698FE08.8020804@gmx.net> To: Anthony Nadalin X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "oauth@ietf.org" , =?utf-8?Q?Rolando_Mart=C3=ADnez?= Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 06:13:28 -0000 --Apple-Mail-0544FB12-03E9-47D3-9FA5-06D7789A21BF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1.=20 Phil > On Jan 17, 2016, at 22:08, Anthony Nadalin wrote: >=20 > I=E2=80=99m afraid that I would have to agree with Brian (hopefully this i= s not a trend) > =20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell > Sent: Friday, January 15, 2016 9:16 AM > To: Hannes Tschofenig > Cc: oauth@ietf.org; Rolando Mart=C3=ADnez > Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires > =20 > Speaking for myself but I suspect others might be in the same boat - I'd l= ove to see some additional time beyond the official meeting made available t= o try and make more progress on the open work in OAuth. But the week before I= ETF in a different country (even if it's only a 19h bus ride) just isn't log= istically feasible for me. > =20 > On Fri, Jan 15, 2016 at 7:11 AM, Hannes Tschofenig wrote: > Would it make sense to add an OAuth day to the OpenID Summit to prepare > the IETF meeting, to play around with code, etc? >=20 > On 01/15/2016 01:58 PM, John Bradley wrote: > > Yes I am going. > > > > The University of Chile and RedHat are sponsoring a one day OpenID Summi= t on Mar 31. > > > > I will send the registration info to the list once we have it up. > > > > Anyone interested should email myself or Rolando who is cc=E2=80=99d on t= his. > > > > John B. > > > >> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig wrote: > >> > >> Hi all, > >> > >> I have just requested a 2 hour meeting slot for the next IETF meeting i= n > >> Buenos Aires. > >> > >> It would be good to know whether you are planning to attend the upcomin= g > >> IETF meeting. Please drop me a private mail to tell me your plans. > >> > >> Ciao > >> Hannes > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-0544FB12-03E9-47D3-9FA5-06D7789A21BF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1. 

Phil

On= Jan 17, 2016, at 22:08, Anthony Nadalin <tonynad@microsoft.com> wrote:

I=E2=80=99m afraid that I would have to agree with Br= ian (hopefully this is not a trend)

 <= /a>

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Friday, January 15, 2016 9:16 AM
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Cc: oauth@ietf.org; Rolando Mar= t=C3=ADnez <m@rtinez.cl>
Subject: Re: [OAUTH-WG] IETF 95 - Buenos Aires

 

Speaking for myself but I suspect others might be in t= he same boat - I'd love to see some additional time beyond the official meet= ing made available to try and make more progress on the open work in OAuth. B= ut the week before IETF in a different country (even if it's only a 19h bus ride) just isn't logisticall= y feasible for me.

 

On Fri, Jan 15, 2016 at 7:11 AM, Hannes Tschofenig &l= t;hannes.tsch= ofenig@gmx.net> wrote:

Would it make sense to add an OAuth day to the OpenID= Summit to prepare
the IETF meeting, to play around with code, etc?


On 01/15/2016 01:58 PM, John Bradley wrote:
> Yes I am going.
>
> The University of Chile and RedHat are sponsoring a one day OpenID Summ= it on Mar 31.
>
> I will send the registration info to the list once we have it up.
>
> Anyone interested should email myself or Rolando who is cc=E2=80=99d on= this.
>
> John B.
>
>> On Jan 15, 2016, at 6:08 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>
>> Hi all,
>>
>> I have just requested a 2 hour meeting slot for the next IETF meeti= ng in
>> Buenos Aires.
>>
>> It would be good to know whether you are planning to attend the upc= oming
>> IETF meeting. Please drop me a private mail to tell me your plans.<= br> >>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> 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<= /p>

 

____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-0544FB12-03E9-47D3-9FA5-06D7789A21BF-- From nobody Mon Jan 18 02:59:58 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABD31B34A7 for ; Mon, 18 Jan 2016 02:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpHayRda2DXR for ; Mon, 18 Jan 2016 02:59:55 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F141B34A6 for ; Mon, 18 Jan 2016 02:59:55 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id b14so116670822wmb.1 for ; Mon, 18 Jan 2016 02:59:55 -0800 (PST) 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-type:content-transfer-encoding; bh=6l1yERMNXTU7lfrPmgVLuys+/aKo/vCwK6du7gDj56c=; b=xYwpGJ1QVugFL6jlucnmkVD818egO/YDhj+bDKWDh50dWkwd62AsWGHgJyzmFb2i5G aI/YxHSbDC4FAPftp57/K6pma8eFtbrqW7LbjswZC/7BbsbE76t/2vgk1JQUCXbWJIjY ag/BgVRZNt2QYSSedCvyqwK/hgzU8Y6j6haYpbeAUFQHeFbIexxlGowVRcmo4WI9WI6Y Q7Np+1xZCwW4w28r/gEdQltgnq/1FP8hGU8xJJfKgy7QT0+HpgLAuRa+p0S2olH3svdS ThdWY56ECLYhtYkpSVpTGeZIfXd0a3hkctS2rHsjd4UpZmBspl1kobjh6ExqA1gVZdcd 0hmg== 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-type:content-transfer-encoding; bh=6l1yERMNXTU7lfrPmgVLuys+/aKo/vCwK6du7gDj56c=; b=nBv+uQZrHnWJ4ypH1bjE9knmvvM9P8Rg0ULj1dcqMddzMJAlMH6W/SyLy2u91qjCIk PY1EINWeCOs0Zej6d8c2d3i6HspE9zh3NzcTzuyaP8z9KbVCvYVfcvZxRPk2b7w/A//K z44Q1o601OCLrI9E9rLIrXy+QrAlTpMa4+u7RybCAmNGZ+7ylocA7KH4Fnd6ft60AGxz egY7vM9h9b4b5HwmYvFnPXDGUaehmuqox9aM7pgH8JTqZXEKA+mhpG54drKB1H4QKHCN Yo3aVk7S+mVw8rzRGG2OJNgaYspAArlnmLnjQFyr/gHiIl490bsJD0G6U2i3LlJSSutl pWMQ== X-Gm-Message-State: AG10YOR9O3f0rIxEdo2llswx5AoNsLZx5n6qzUosT68TYDGdnJmlSiiChU0ICGe/pr/2zg== X-Received: by 10.28.184.136 with SMTP id i130mr11907797wmf.96.1453114793776; Mon, 18 Jan 2016 02:59:53 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id qs1sm23288267wjc.2.2016.01.18.02.59.52 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 02:59:52 -0800 (PST) To: oauth@ietf.org From: Sergey Beryozkin Message-ID: <569CC5A8.6050501@gmail.com> Date: Mon, 18 Jan 2016 10:59:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] Can the repeated authorization of scopes be avoided ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 10:59:57 -0000 Hi All The question relates to the process of showing the authorization code/implicit flow consent screen to a user. I'm discussing with my colleagues the possibility of avoiding asking the same user whose session has expired and who is re-authenticating with AS which scopes should be approved. For example, suppose the OAuth2 client redirects a user with the requested scope 'a'. The user signs in to AS and is shown a consent screen asking to approve the 'a' scope. The user approves 'a' and the flow continues. Some time later, when the user's session has expired, the user is redirected to AS with the same 'a' scope. Would it be a good idea, at this point, not to show the user the consent screen asking to approve the 'a' scope again ? For example, AS can persist the fact that a given user has already approved 'a' for a given client earlier, so when the user re-authenticates, AS will use this info and will avoid showing the consent screen. That seems to make sense, but I'm wondering, can there be some security implications associated with it, any recommendations/advices will be welcome Sergey From nobody Mon Jan 18 03:48:03 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17F11B3572 for ; Mon, 18 Jan 2016 03:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuoOkkkzUCln for ; Mon, 18 Jan 2016 03:48:00 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2BB1B3573 for ; Mon, 18 Jan 2016 03:48:00 -0800 (PST) X-AuditID: 12074425-f793c6d000006975-c1-569cd0eee865 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id E5.27.26997.EE0DC965; Mon, 18 Jan 2016 06:47:58 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u0IBlw8p013925; Mon, 18 Jan 2016 06:47:58 -0500 Received: from [IPv6:2607:fb90:e6d:4da5:0:4e:efc7:b501] (m9c2436d0.tmodns.net [208.54.36.156]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u0IBlti4018320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 Jan 2016 06:47:57 -0500 Date: Mon, 18 Jan 2016 06:47:54 -0500 Message-ID: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> Importance: normal From: Justin Richer To: Sergey Beryozkin , oauth@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_525150427075080" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixG6novvuwpwwg2fXzSxOvn3FZvFvqb0D k8fOWXfZPZYs+ckUwBTFZZOSmpNZllqkb5fAlTH9wyf2gpfaFd9WdbM0MB7U6mLk5JAQMJG4 0NDBAmGLSVy4t54NxBYSWMwk0fcgoYuRC8jeyCix7Pw/ZgjnNpPEhBWTWUGqWARUJVoWTgXq 4OAQFvCXuHAkA8TkFXCT+LqhFMTkFBCS6NolAVLMBlQ8fU0LE4gtImAtcePxdEYQm1dAUOLk zCdgJzALhEjMPjqLaQIj7ywkqVlIUhC2usSfeZeYIWxFiSndD9lnAW1jFlCTWNaqhCy8gJFt FaNsSm6Vbm5iZk5xarJucXJiXl5qka6FXm5miV5qSukmRnB4uqjuYJxwSOkQowAHoxIPr8PZ 2WFCrIllxZW5hxglOZiURHmzz88JE+JLyk+pzEgszogvKs1JLT7EKMHBrCTCG7weKMebklhZ lVqUD5OS5mBREuf9VjklTEggPbEkNTs1tSC1CCYrw8GhJMFbDjJUsCg1PbUiLTOnBCHNxMEJ MpwHaPhRkBre4oLE3OLMdIj8KUZTKXHelyAJAZBERmkeXK+SkJCAGvvvCXy5vksZGBj83h/f yghKMxfMVOa8YhQHek+YtwikkweYouAmvgJaxgS07KfHbJBlJYkIKakGxlLfhZFXGw+FvmCr +PNpRdoPExO+608vnrRh5OgtnL5A+tWioIY315Meeob9cb847YBtTeAXqx2PtL6EKFSYbLU6 6FSmePr76+lsh3Xf8vQeNrC4uanhqPV2l8q5b9rvqVjsvFeofTxkh7n7iz132Da7c7kwno4s 2Du/dmtG0fN5t+Qnr3L4KqfEUpyRaKjFXFScCAACFzslDgMAAA== Archived-At: Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 11:48:03 -0000 ----_com.android.email_525150427075080 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 CiAgICAKWWVzLCB0aGlzIGlzIGNvbW1vbiBwcmFjdGljZS4gR2l2ZSB0aGUgdXNlciB0aGUgb3B0 aW9uIHRvIHJlbWVtYmVyIHRoZSBkZWNpc2lvbi4gVGhpcyBpcyBrbm93biBhcyAidHJ1c3Qgb24g Zmlyc3QgdXNlIiwgb3IgdG9mdS4gT3VyIHNlcnZlciwgTUlUUkVpZCBDb25uZWN0LCBpbXBsZW1l bnRzIHRoaXMgYXMgZG8gbWFueSBvdGhlcnMuwqAKCgotLSBKdXN0aW4KLyBTZW50IGZyb20gbXkg cGhvbmUgLwoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tOiBTZXJnZXkg QmVyeW96a2luIDxzYmVyeW96a2luQGdtYWlsLmNvbT4gCkRhdGU6IDEvMTgvMjAxNiAgNTo1OSBB TSAgKEdNVC0wNTowMCkgClRvOiBvYXV0aEBpZXRmLm9yZyAKU3ViamVjdDogW09BVVRILVdHXSBD YW4gdGhlIHJlcGVhdGVkIGF1dGhvcml6YXRpb24gb2Ygc2NvcGVzIGJlIGF2b2lkZWQgPyAKCkhp IEFsbAoKVGhlIHF1ZXN0aW9uIHJlbGF0ZXMgdG8gdGhlIHByb2Nlc3Mgb2Ygc2hvd2luZyB0aGUg YXV0aG9yaXphdGlvbiAKY29kZS9pbXBsaWNpdCBmbG93IGNvbnNlbnQgc2NyZWVuIHRvIGEgdXNl ci4KCgpJJ20gZGlzY3Vzc2luZyB3aXRoIG15IGNvbGxlYWd1ZXMgdGhlIHBvc3NpYmlsaXR5IG9m IGF2b2lkaW5nIGFza2luZyB0aGUgCnNhbWUgdXNlciB3aG9zZSBzZXNzaW9uIGhhcyBleHBpcmVk IGFuZCB3aG8gaXMgcmUtYXV0aGVudGljYXRpbmcgd2l0aCBBUyAKd2hpY2ggc2NvcGVzIHNob3Vs ZCBiZSBhcHByb3ZlZC4KCkZvciBleGFtcGxlLCBzdXBwb3NlIHRoZSBPQXV0aDIgY2xpZW50IHJl ZGlyZWN0cyBhIHVzZXIgd2l0aCB0aGUgCnJlcXVlc3RlZCBzY29wZSAnYScuIFRoZSB1c2VyIHNp Z25zIGluIHRvIEFTIGFuZCBpcyBzaG93biBhIGNvbnNlbnQgCnNjcmVlbiBhc2tpbmcgdG8gYXBw cm92ZSB0aGUgJ2EnIHNjb3BlLiBUaGUgdXNlciBhcHByb3ZlcyAnYScgYW5kIHRoZSAKZmxvdyBj b250aW51ZXMuCgpTb21lIHRpbWUgbGF0ZXIsIHdoZW4gdGhlIHVzZXIncyBzZXNzaW9uIGhhcyBl eHBpcmVkLCB0aGUgdXNlciBpcyAKcmVkaXJlY3RlZCB0byBBUyB3aXRoIHRoZSBzYW1lICdhJyBz Y29wZS4KCldvdWxkIGl0IGJlIGEgZ29vZCBpZGVhLCBhdCB0aGlzIHBvaW50LCBub3QgdG8gc2hv dyB0aGUgdXNlciB0aGUgY29uc2VudCAKc2NyZWVuIGFza2luZyB0byBhcHByb3ZlIHRoZSAnYScg c2NvcGUgYWdhaW4gPyBGb3IgZXhhbXBsZSwgQVMgY2FuIApwZXJzaXN0IHRoZSBmYWN0IHRoYXQg YSBnaXZlbiB1c2VyIGhhcyBhbHJlYWR5IGFwcHJvdmVkICdhJyBmb3IgYSBnaXZlbiAKY2xpZW50 IGVhcmxpZXIsIHNvIHdoZW4gdGhlIHVzZXIgcmUtYXV0aGVudGljYXRlcywgQVMgd2lsbCB1c2Ug dGhpcyBpbmZvIAphbmQgd2lsbCBhdm9pZCBzaG93aW5nIHRoZSBjb25zZW50IHNjcmVlbi4KClRo YXQgc2VlbXMgdG8gbWFrZSBzZW5zZSwgYnV0IEknbSB3b25kZXJpbmcsIGNhbiB0aGVyZSBiZSBz b21lIHNlY3VyaXR5IAppbXBsaWNhdGlvbnMgYXNzb2NpYXRlZCB3aXRoIGl0LCBhbnkgcmVjb21t ZW5kYXRpb25zL2FkdmljZXMgd2lsbCBiZSB3ZWxjb21lCgpTZXJnZXkKCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk9BdXRoIG1haWxpbmcgbGlzdApPQXV0 aEBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoCg== ----_com.android.email_525150427075080 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT4KICAgIAo8ZGl2PlllcywgdGhpcyBp cyBjb21tb24gcHJhY3RpY2UuIEdpdmUgdGhlIHVzZXIgdGhlIG9wdGlvbiB0byByZW1lbWJlciB0 aGUgZGVjaXNpb24uIFRoaXMgaXMga25vd24gYXMgInRydXN0IG9uIGZpcnN0IHVzZSIsIG9yIHRv ZnUuIE91ciBzZXJ2ZXIsIE1JVFJFaWQgQ29ubmVjdCwgaW1wbGVtZW50cyB0aGlzIGFzIGRvIG1h bnkgb3RoZXJzLiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PG1ldGEgaHR0cC1lcXVpdj0i Q29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjxkaXY8IGRp dj0iIj48ZGl2PjxkaXY+LS0gSnVzdGluPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4vIFNlbnQg ZnJvbSBteSBwaG9uZSAvPC9kaXY+PC9kaXY+PGRpdj48L2Rpdj48L2Rpdjw+PC9kaXY+PGJyPjxi cj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPkZyb206IFNlcmdleSBCZXJ5 b3praW4gJmx0O3NiZXJ5b3praW5AZ21haWwuY29tJmd0OyA8YnI+RGF0ZTogMS8xOC8yMDE2ICA1 OjU5IEFNICAoR01ULTA1OjAwKSA8YnI+VG86IG9hdXRoQGlldGYub3JnIDxicj5TdWJqZWN0OiBb T0FVVEgtV0ddIENhbiB0aGUgcmVwZWF0ZWQgYXV0aG9yaXphdGlvbiBvZiBzY29wZXMgYmUgYXZv aWRlZCA/IDxicj48YnI+SGkgQWxsPGJyPjxicj5UaGUgcXVlc3Rpb24gcmVsYXRlcyB0byB0aGUg cHJvY2VzcyBvZiBzaG93aW5nIHRoZSBhdXRob3JpemF0aW9uIDxicj5jb2RlL2ltcGxpY2l0IGZs b3cgY29uc2VudCBzY3JlZW4gdG8gYSB1c2VyLjxicj48YnI+PGJyPkknbSBkaXNjdXNzaW5nIHdp dGggbXkgY29sbGVhZ3VlcyB0aGUgcG9zc2liaWxpdHkgb2YgYXZvaWRpbmcgYXNraW5nIHRoZSA8 YnI+c2FtZSB1c2VyIHdob3NlIHNlc3Npb24gaGFzIGV4cGlyZWQgYW5kIHdobyBpcyByZS1hdXRo ZW50aWNhdGluZyB3aXRoIEFTIDxicj53aGljaCBzY29wZXMgc2hvdWxkIGJlIGFwcHJvdmVkLjxi cj48YnI+Rm9yIGV4YW1wbGUsIHN1cHBvc2UgdGhlIE9BdXRoMiBjbGllbnQgcmVkaXJlY3RzIGEg dXNlciB3aXRoIHRoZSA8YnI+cmVxdWVzdGVkIHNjb3BlICdhJy4gVGhlIHVzZXIgc2lnbnMgaW4g dG8gQVMgYW5kIGlzIHNob3duIGEgY29uc2VudCA8YnI+c2NyZWVuIGFza2luZyB0byBhcHByb3Zl IHRoZSAnYScgc2NvcGUuIFRoZSB1c2VyIGFwcHJvdmVzICdhJyBhbmQgdGhlIDxicj5mbG93IGNv bnRpbnVlcy48YnI+PGJyPlNvbWUgdGltZSBsYXRlciwgd2hlbiB0aGUgdXNlcidzIHNlc3Npb24g aGFzIGV4cGlyZWQsIHRoZSB1c2VyIGlzIDxicj5yZWRpcmVjdGVkIHRvIEFTIHdpdGggdGhlIHNh bWUgJ2EnIHNjb3BlLjxicj48YnI+V291bGQgaXQgYmUgYSBnb29kIGlkZWEsIGF0IHRoaXMgcG9p bnQsIG5vdCB0byBzaG93IHRoZSB1c2VyIHRoZSBjb25zZW50IDxicj5zY3JlZW4gYXNraW5nIHRv IGFwcHJvdmUgdGhlICdhJyBzY29wZSBhZ2FpbiA/IEZvciBleGFtcGxlLCBBUyBjYW4gPGJyPnBl cnNpc3QgdGhlIGZhY3QgdGhhdCBhIGdpdmVuIHVzZXIgaGFzIGFscmVhZHkgYXBwcm92ZWQgJ2En IGZvciBhIGdpdmVuIDxicj5jbGllbnQgZWFybGllciwgc28gd2hlbiB0aGUgdXNlciByZS1hdXRo ZW50aWNhdGVzLCBBUyB3aWxsIHVzZSB0aGlzIGluZm8gPGJyPmFuZCB3aWxsIGF2b2lkIHNob3dp bmcgdGhlIGNvbnNlbnQgc2NyZWVuLjxicj48YnI+VGhhdCBzZWVtcyB0byBtYWtlIHNlbnNlLCBi dXQgSSdtIHdvbmRlcmluZywgY2FuIHRoZXJlIGJlIHNvbWUgc2VjdXJpdHkgPGJyPmltcGxpY2F0 aW9ucyBhc3NvY2lhdGVkIHdpdGggaXQsIGFueSByZWNvbW1lbmRhdGlvbnMvYWR2aWNlcyB3aWxs IGJlIHdlbGNvbWU8YnI+PGJyPlNlcmdleTxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1dGggbWFpbGluZyBsaXN0PGJyPk9BdXRoQGll dGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+ PC9ib2R5PjwvaHRtbD4= ----_com.android.email_525150427075080-- From nobody Mon Jan 18 04:44:27 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E0D1B366B for ; Mon, 18 Jan 2016 04:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVkK3j5jUVAn for ; Mon, 18 Jan 2016 04:44:24 -0800 (PST) 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 3A4961B366A for ; Mon, 18 Jan 2016 04:44:24 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id r129so49800200wmr.0 for ; Mon, 18 Jan 2016 04:44:24 -0800 (PST) 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-type:content-transfer-encoding; bh=tDIFUfHK4HzoZkNHPQiGKKkEALCaDQpp8aX+eBx63fM=; b=iWrty4cBhK00Y8LsAp4t/pOQLgYZE4/rfl9pjNKwT51RS4KelfKNCv4NPRQPNZizP9 825g9sFe0xYSfkPfjcoMIaigQnh0uEbhDK7DNvAWOmaS+DiFYiIOzfn05UKUOjMxhnbm iQUaTHp8DdTI+vJIVShu5bJsNjaBUbFbbY+elu9mXJS50dBQkfNKtKfsRnUoxim7XK8y 8oG0JeQ64cThWlQiKCTYlYLu3MRj39dbm7/cjZr95zdCd+TQMqYAjuPmRAZqGjDeTIZI qN3r1n1FmgAy4s8sBVqx5yrzX+ZD7Fiae0ehwJwU9FU50KOwDE/FCrDRFPIRRwsM1h4v 5bWA== 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-type :content-transfer-encoding; bh=tDIFUfHK4HzoZkNHPQiGKKkEALCaDQpp8aX+eBx63fM=; b=N8xn50pj//0Q/xyHMckqOOHNKR09PGi5+VM3mA6fVAFKHlndnPEf1lU3qNyKsXkgnk OnNk5c/6d1YDB9R/tjYS3NTiNn6TXn+JOyVJaKjM7FVMxqBQSNrRHDO6DKRiMN07QFe1 0KUWrVfbbMDRFp4Uw4hL0I21qw1luY6+jEfEEawJnehqPqBx2QBYM7QeMfMleH8/XUyy 5Ca+w6J58azE+lA9sEpCDYYhOkC5q8u1wMkNJcPx342YFZSPx1B4NlybSsgiN0QLIjMu YOu/0ufvyQi5Gi5/7RGUQ+WOsRnlsZv6ZsJeLLmXla4fUPgFQj/+4WGoNF6O6m1C0nSV GdLQ== X-Gm-Message-State: ALoCoQmFzS5JJEwmYe0o+zhuwFyCpdbnIsq6uV+sf/YSSCSeKWiKuZ/UzgLRfwVNgQTGxQvlhf05VgFhPfC32fNvtZp4H338gg== X-Received: by 10.194.86.166 with SMTP id q6mr27094647wjz.69.1453121062778; Mon, 18 Jan 2016 04:44:22 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id q129sm15712848wmd.14.2016.01.18.04.44.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 04:44:21 -0800 (PST) To: Justin Richer , oauth@ietf.org References: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> From: Sergey Beryozkin Message-ID: <569CDE25.90908@gmail.com> Date: Mon, 18 Jan 2016 12:44:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 12:44:26 -0000 Hi Justin, thanks for the advice, Cheers, Sergey On 18/01/16 11:47, Justin Richer wrote: > Yes, this is common practice. Give the user the option to remember the > decision. This is known as "trust on first use", or tofu. Our server, > MITREid Connect, implements this as do many others. > > > > -- Justin > > / Sent from my phone / > > > -------- Original message -------- > From: Sergey Beryozkin > Date: 1/18/2016 5:59 AM (GMT-05:00) > To: oauth@ietf.org > Subject: [OAUTH-WG] Can the repeated authorization of scopes be avoided ? > > Hi All > > The question relates to the process of showing the authorization > code/implicit flow consent screen to a user. > > > I'm discussing with my colleagues the possibility of avoiding asking the > same user whose session has expired and who is re-authenticating with AS > which scopes should be approved. > > For example, suppose the OAuth2 client redirects a user with the > requested scope 'a'. The user signs in to AS and is shown a consent > screen asking to approve the 'a' scope. The user approves 'a' and the > flow continues. > > Some time later, when the user's session has expired, the user is > redirected to AS with the same 'a' scope. > > Would it be a good idea, at this point, not to show the user the consent > screen asking to approve the 'a' scope again ? For example, AS can > persist the fact that a given user has already approved 'a' for a given > client earlier, so when the user re-authenticates, AS will use this info > and will avoid showing the consent screen. > > That seems to make sense, but I'm wondering, can there be some security > implications associated with it, any recommendations/advices will be welcome > > Sergey > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Mon Jan 18 08:43:36 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B0F1B399C for ; Mon, 18 Jan 2016 08:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enua5CdDq7Nu for ; Mon, 18 Jan 2016 08:43:33 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AC931B3999 for ; Mon, 18 Jan 2016 08:43:32 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id r129so58610816wmr.0 for ; Mon, 18 Jan 2016 08:43:32 -0800 (PST) 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-type:content-transfer-encoding; bh=VG5dO+aNNXx9LxNbufqmEQnv5wHR27P2EmQdHN2rDeE=; b=xfu6kv6/a91XqDlTQMfMPeLbwAYEb/+//7VaqY5ZajjWaiRoDxFaksEuXbg2WHpzoo pRPIT6z9Qr/8mY0bviIwOJYBzXegozY9Q4G7P0+NN7p8SrlUWAXH1d3owSj/v97FwlpY DsVepYgc6dIr7AG5UQ9C0OqM6cnDASJAkL2ObxEoOgF7t5TVW+nJmBj1HvLs7pHalrUo SxqTsF+/uJvRolfWq97YPVnflDnKOjCaEIzNGKG6aEx1/1xiD/djq6u9FWfYUSLBclXV C3wwHhyxNTLC11kYgxpPi1nnBiFHeKQNMx+hkbpn7ACb2RiPrBnHYt+yoIha+aNiX6tB xlPQ== 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-type :content-transfer-encoding; bh=VG5dO+aNNXx9LxNbufqmEQnv5wHR27P2EmQdHN2rDeE=; b=EfsMqRjMmJEGIucsG1Qm4PQ9ua1XNplyvtNA8dxf8xOsJ2a0rhoJXfJHXkGeIkkgRL slVJscXZn1FzyAbgWz/RbleEE//kyVK61V3ipDdYQ4/KuIWoRib2iqA7M84mUnrLUzKk 602ZhT1Ze1OZR5VX/WKwoPZ0YPpquMmExg98tWya+ahxlo5V0metdqAxhySTEgbfLF8U HVxRref4C09qj52R1bGTQzh2SUzMUXc5kBWxn4qkA1RmJ2TlI/C5TwqnJLrhg1kCRvf5 odxzHds6zfCutKsiHVeJ3vzKNoS1eHuY4WcpTrHXN6UfVkz4X7FB2vWPcakh6kkM836/ 8mfw== X-Gm-Message-State: AG10YOTqtDKgRU8zsAdwIVQD9noODOD6ZCXX+zGv/BfWzaEukZt6A5RiLbn0T8sSYuZyeQ== X-Received: by 10.28.45.207 with SMTP id t198mr15090590wmt.32.1453135411156; Mon, 18 Jan 2016 08:43:31 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id xx3sm24608679wjc.32.2016.01.18.08.43.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Jan 2016 08:43:29 -0800 (PST) To: Justin Richer References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> From: Sergey Beryozkin Message-ID: <569D1631.4030705@gmail.com> Date: Mon, 18 Jan 2016 16:43:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569D1297.2000805@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 16:43:35 -0000 Hi Justin Sorry I did not copy to the list with my previous response... That sounds convincing, I was about to suggest that AS may opt not to report the expiry time simply because it is an optional property, but I guess that would be just an argument for the sake of the argument :-), as I guess in practice AS will report the expiry time of the tokens that actually expire... Many thanks, Sergey On 18/01/16 16:28, Justin Richer wrote: > If the AS doesn't include the expiration then that means that the RS > doesn't know anything about the token expiring or not. This can be > caused by: > > 1) The token never expiring from a timestamp (could still get revoked > or expire after a number of uses) > 2) The RS not being allowed to know if the token expires > > Either way, the RS doesn't know anything about the token expiring or not > and so should treat it as if it hasn't expired since that's all the AS > has told it. An RS trying to second guess the AS response here is going > to get into trouble. > > If the token expires "shortly" then there would be an expiration in the > response, if the RS is allowed to know that. There's no interoperability > issue here, still, and a special value wouldn't fix this. > > -- Justin > > On 1/18/2016 11:10 AM, Sergey Beryozkin wrote: >> Hi >> >> If the only way for AS to indicate the token has expired is not to >> report this value, while the other AS does not report the specific >> expiry time simply because the expiry property is optional, then RS >> working with both of those 2 AS has no way to understand if a given >> token expires shortly or never expires at all. >> >> That is why I'm thinking having no special value indicating the token >> does not expire is an interoperability issue (the communication >> between RS and third-part AS servers) >> >> Thanks, Sergey >> On 18/01/16 15:55, Justin Richer wrote: >>> That's a problem for the RS to figure out in its logs system regardless >>> of whether you choose a "special" value for non-expiration or not. I >>> don't see how this changes interoperability. >>> >>> -- Justin >>> >>> On 1/16/2016 4:50 PM, Sergey Beryozkin wrote: >>>> Hi Justin >>>> This is reasonable and it works with the introspection protocol >>>> because the text says 'active' means AS must've checked the token has >>>> not expired, but even so, it is in a 'conflict' with the >>>> interoperability concept. >>>> Consider a simple case where RS wants to log "Client uses access token >>>> with this ID, the token expiry time - this time/never" and some other >>>> RS wants to block the requests with the token which will expire in >>>> less then say 5/10 secs. >>>> When this RS works with one AS - this AS thinks it should not report >>>> the expiry time because it means omitting it indicates the token never >>>> expires. The other AS does not report it because: it either does not >>>> know how to rep a 'never expires' value. The next AS thinks it is not >>>> needed to be reported at all. >>>> What should RS do willing to do the above tasks around the expiry time >>>> do :-) ? >>>> >>>> Thanks, Sergey >>>> >>>> On 16/01/16 16:14, Justin Richer wrote: >>>>> All the values in the token introspection response are optional, >>>>> except for “active”. If you don’t have anything to say about a >>>>> particular aspect of the token, or can’t say it to the software >>>>> that’s asking, then you generally leave it out of the response. >>>>> >>>>> — Justin >>>>> >>>>>> On Jan 16, 2016, at 11:02 AM, Vladimir Dzhuvinov >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 15/01/16 15:47, Sergey Beryozkin wrote: >>>>>>> Hi John >>>>>>> >>>>>>> Thanks, looks like it was a last minute change because Introduction >>>>>>> does not explain why would clients want to use the introspection >>>>>>> endpoint to effectively 'unwrap' the opaque token representations. >>>>>>> >>>>>>> I have another question. How to report the expiry time in cases when >>>>>>> the tokens do not expire ? I'm aware of some deployments where >>>>>>> access >>>>>>> tokens are only manually deleted and otherwise would not expire. >>>>>>> >>>>>>> Perhaps not reporting the expiry time is equivalent to the token >>>>>>> never >>>>>>> expiring ? Or may be reporting 0 or -1 works ? >>>>>> >>>>>> The core OAuth 2.0 spec seems to imply the former: >>>>>> >>>>>> http://tools.ietf.org/html/rfc6749#section-5.1 >>>>>> >>>>>> Using a zero or negative integer may not be a good idea, as >>>>>> clients may >>>>>> just take the value as it is and add it to the current system time, >>>>>> concluding that the token has expired :) >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Vladimir >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, Sergey >>>>>>> On 15/01/16 13:32, John Bradley wrote: >>>>>>>> Some people wanted the client to be able to use introspection. >>>>>>>> >>>>>>>> The ability to pass a refresh token is a legacy of that. A RS >>>>>>>> would never have a refresh token unless it is acting as a client. >>>>>>>> That is correct. >>>>>>>> >>>>>>>> John B. >>>>>>>> >>>>>>>>> On Jan 15, 2016, at 5:34 AM, Sergey Beryozkin >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> I'm reviewing RFC 7622 as we are going ahead with implementing it. >>>>>>>>> I have a question: >>>>>>>>> >>>>>>>>> 1. Token Hint in the introspection request. >>>>>>>>> The spec mentions 'refresh_token' as one of the possible >>>>>>>>> values. But >>>>>>>>> a protected resource does not see a refresh token (ever ?), it is >>>>>>>>> Access Token service which does. >>>>>>>>> When would a protected resource use a 'refresh_token' hint when >>>>>>>>> requesting an introspection response ? >>>>>>>>> >>>>>>>>> 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 >>>>>> >>>>>> -- >>>>>> 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 >>>>> >>>> >>>> >>> >> > -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ From nobody Mon Jan 18 18:59:01 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 941E11A8928 for ; Mon, 18 Jan 2016 18:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXPelKsDBSVn for ; Mon, 18 Jan 2016 18:58:58 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::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 9FBDD1A8925 for ; Mon, 18 Jan 2016 18:58:58 -0800 (PST) Received: by mail-ob0-x232.google.com with SMTP id is5so176615495obc.0 for ; Mon, 18 Jan 2016 18:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8OM5UfwBmLfSg6LFDSb3bPPmU8YlY8wEiEIg8ex0VCA=; b=bBJZK8W/W5mxwKlIMFFYo+yQ2Fm3vRlnV8kyV0RlMbjX4ydib1J9ImX7uThEfsar/i JwS0BgnCaLfc2Y6A1sUWuANrbCJH1niuuat2Rx/nsMdtiwGaswTXmJMqsjaMrUmDHSdT AxBqlxGeesD0eEV65e0k8kB4OrWhslMGVordHCr6F8hiZElTK9Y2v2E7H3PrvjC4TAHk ojypgyvH3eqCsR0mZkN+KdmAAo5Bzp6dTBPI7kYVGIekQcPoj4GmmFN8WWkgU8mmXhrY IG25J/MXJxSAJjuAq3kwwp33t8Zs5seXnhjtfXm4aF9+VxZKOycILWmjlYExwMgsfgm8 uOPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8OM5UfwBmLfSg6LFDSb3bPPmU8YlY8wEiEIg8ex0VCA=; b=Rv7rw/nKKrPwtd70D3ZhHdSPTOrQfXqVF1e9hyuAHlyB9ctO5MtISJwl8ZTPzvySql V9CL5V333Fd56jUnubuI5SxpVVnQuqc4dOVjd6+k2KfA5A5rYND9uEfMol18AnQB0PAH JEKDBwZXPtFtqxWRmr8Etz1bDeLtnPxFA1pDP6edkVJPiopg1XG0LaJ18p3IUCRth5fh 6p6hAPx4QYtrGwBsgdXSFfzqysPBMOuBc/kE1dAocN2JXv0oTceATzU2XYq04kEGwl02 AtITP0pSIVqCBeyLO4WjA0bJUQTbZt8s44C9KyAChDOYg+RT/aha2yllk8tlA4MCitOg 112w== X-Gm-Message-State: ALoCoQm4zQJz0Fx1rcIPMoGBBkImxnkvsfCn5z2J+l3A2I1ZconPVvblcI7lDfXkQXAJiTTvgzhCrDCOGV6KYvmbZKoEGpCb3tetqqGC6WN347sXtWptpR8= X-Received: by 10.60.51.70 with SMTP id i6mr22212979oeo.3.1453172337972; Mon, 18 Jan 2016 18:58:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Mon, 18 Jan 2016 18:58:37 -0800 (PST) In-Reply-To: <568D5610.6000506@lodderstedt.net> References: <568D24DD.3050501@connect2id.com> <568D5610.6000506@lodderstedt.net> From: William Denniss Date: Mon, 18 Jan 2016 18:58:37 -0800 Message-ID: To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001a11c301cc00e4490529a70d0c Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 02:59:00 -0000 --001a11c301cc00e4490529a70d0c Content-Type: text/plain; charset=UTF-8 Seems like we agree this should be added. How should it look? Two ideas: "code_challenge_methods_supported": ["plain", "S256"] or "pkce_methods_supported": ["plain", "S256"] On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt wrote: > +1 > > > Am 06.01.2016 um 18:25 schrieb William Denniss: > > +1 > > On Wed, Jan 6, 2016 at 6:40 AM, John Bradley wrote: > >> Good point. Now that PKCE is a RFC we should add it to discovery. >> >> John B. >> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov >> wrote: >> > >> > I just noticed PKCE support is missing from the discovery metadata. >> > >> > Is it a good idea to add it? >> > >> > Cheers, >> > >> > Vladimir >> > >> > -- >> > 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 >> > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > --001a11c301cc00e4490529a70d0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Seems like we agree this should be added. How should it lo= ok?

Two ideas:

"code_challenge_methods_supported": = ["plain", "S256"]

or

<= div>"pkce_methods_supported": ["plain", "S256"= ;]



On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=20 =20 =20
+1


Am 06.01.2016 um 18:25 schrieb William Denniss:
+1

On Wed, Jan 6, 2016 at 6:40 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Good point.=C2=A0 Now that PKCE is a RFC we should add it to discovery.

John B.
> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
>
> I just noticed PKCE support is missing from the discovery metadata.
>
> Is it a good idea to add it?
>
> Cheers,
>
> Vladimir
>
> --
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@= ietf.org
> https://www.ietf.org/mailman/listinfo/oa= uth

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



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


--001a11c301cc00e4490529a70d0c-- From nobody Mon Jan 18 19:10:40 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1651A897E for ; Mon, 18 Jan 2016 19:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4LChE5Ov2i4 for ; Mon, 18 Jan 2016 19:10:38 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 839781A8987 for ; Mon, 18 Jan 2016 19:10:35 -0800 (PST) Received: by mail-ob0-x22a.google.com with SMTP id is5so176782179obc.0 for ; Mon, 18 Jan 2016 19:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BXswcOPKHP7nUrJTVvRBcK61dGANmLgYiupEPhqOfkw=; b=GsZbUkIYzncw70yu7q6lm2M2cJJg1Aaz7TwRgujRiEA6XnM2hiqp6e+Z+BnRXAkwrM S1bGg3g6ZxITQ7PQiNFCjWynmEPB+I/bbLt/eQf/6uWx3FUH4moHMDT1H+Vhb8Eim9XE NTpNHV2rlKl9Mqju5l9g8dHsdT7oy2Ao1/P9niN2gjAUB2PtxPGvsmI2tAtBSCgg1kmu +TjeNG2mOp/eSh4PqxXDOqVAgoOiDVzQzhli+romg8sevE8Jna0E/jEAofwi64td5v1s LtPg9z4RelDl8lD8qhivpffLFVaMtf/tx+Leq5nQrFICCpNdgDYUnTV4K8Eh0gzlh1gi 2pyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BXswcOPKHP7nUrJTVvRBcK61dGANmLgYiupEPhqOfkw=; b=hDduQfIP932Dki5C/2uBEImLcG5idshN6bj9ByfUCKwm4DyfNaRcaT90cUjXiJ+IHG /umJJ0HHUakNJ0KXFkiDgn+dqBJFkDMaXILKpsDDTbpDnvm5KEonBluztY1DkapjpmW0 wHEUVGOBJQBvKMRhai2TiFiid3NQ4p6A6iPG6oLq/p3Eb/zlEWtuShdodoCwIOCnA08S jWl9WttK8rhsuug/KIfFyWirCUX+myZOkeyfENgTVhsUXGpMxhKsjB8TgWo45TkCDaJF m8UTWqL65cwgydzm/rHNF0o4p3sI+XCAwZZ2mSIP/+DZS5/ttWlWwAnKsAM+cyMj2Z+W +t5w== X-Gm-Message-State: ALoCoQlry3cEZIiLfcQEgbqVuqUSsCW2yBTpeKeN632d5tjpOKCP4B9KlTrMSFluzVX+1WskJbXafXYh+i4+VEMTYx551aZvgvLG4Ki8yD3a/G9/kgvRk8g= X-Received: by 10.60.124.83 with SMTP id mg19mr21367233oeb.14.1453173034851; Mon, 18 Jan 2016 19:10:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Mon, 18 Jan 2016 19:10:15 -0800 (PST) In-Reply-To: <569CDE25.90908@gmail.com> References: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> <569CDE25.90908@gmail.com> From: William Denniss Date: Mon, 18 Jan 2016 19:10:15 -0800 Message-ID: To: Sergey Beryozkin Content-Type: multipart/alternative; boundary=047d7b5d2fd28a63970529a736a1 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 03:10:40 -0000 --047d7b5d2fd28a63970529a736a1 Content-Type: text/plain; charset=UTF-8 Agree with Justin, this is pretty common. We support it for re-auth as well as incremental auth (where the user has already approved scope "a" and is presented with a request for scopes "a b", they will only need to approve scope "b"). In fact if you don't do this, then incremental auth isn't really viable. Regarding security: don't do this for non-confidential clients where you can't verify the identity of the app by the redirect (e.g. a localhost redirect to an installed app). On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin wrote: > Hi Justin, thanks for the advice, > > Cheers, Sergey > > On 18/01/16 11:47, Justin Richer wrote: > >> Yes, this is common practice. Give the user the option to remember the >> decision. This is known as "trust on first use", or tofu. Our server, >> MITREid Connect, implements this as do many others. >> >> >> >> -- Justin >> >> / Sent from my phone / >> >> >> -------- Original message -------- >> From: Sergey Beryozkin >> Date: 1/18/2016 5:59 AM (GMT-05:00) >> To: oauth@ietf.org >> Subject: [OAUTH-WG] Can the repeated authorization of scopes be avoided ? >> >> Hi All >> >> The question relates to the process of showing the authorization >> code/implicit flow consent screen to a user. >> >> >> I'm discussing with my colleagues the possibility of avoiding asking the >> same user whose session has expired and who is re-authenticating with AS >> which scopes should be approved. >> >> For example, suppose the OAuth2 client redirects a user with the >> requested scope 'a'. The user signs in to AS and is shown a consent >> screen asking to approve the 'a' scope. The user approves 'a' and the >> flow continues. >> >> Some time later, when the user's session has expired, the user is >> redirected to AS with the same 'a' scope. >> >> Would it be a good idea, at this point, not to show the user the consent >> screen asking to approve the 'a' scope again ? For example, AS can >> persist the fact that a given user has already approved 'a' for a given >> client earlier, so when the user re-authenticates, AS will use this info >> and will avoid showing the consent screen. >> >> That seems to make sense, but I'm wondering, can there be some security >> implications associated with it, any recommendations/advices will be >> welcome >> >> 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 > --047d7b5d2fd28a63970529a736a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree with Justin, this is pretty common. We support it fo= r re-auth as well as incremental auth (where the user has already approved = scope "a" and is presented with a request for scopes "a b&qu= ot;, they will only need to approve scope "b").=C2=A0 In fact if = you don't do this, then incremental auth isn't really viable.
<= br>
Regarding security: don't do this for non-confidential cl= ients where you can't verify the identity of the app by the redirect (e= .g. a localhost redirect to an installed app).

On Mon, Jan 18, 2016 at 4:44 AM, S= ergey Beryozkin <sberyozkin@gmail.com> wrote:
Hi Justin, thanks for the advice,

Cheers, Sergey

On 18/01/16 11:47, Justin Richer wrote:
Yes, this is common practice. Give the user the option to remember the
decision. This is known as "trust on first use", or tofu. Our ser= ver,
MITREid Connect, implements this as do many others.



-- Justin

/ Sent from my phone /


-------- Original message --------
From: Sergey Beryozkin <sberyozkin@gmail.com>
Date: 1/18/2016 5:59 AM (GMT-05:00)
To: oauth@ietf.org<= br> Subject: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?
Hi All

The question relates to the process of showing the authorization
code/implicit flow consent screen to a user.


I'm discussing with my colleagues the possibility of avoiding asking th= e
same user whose session has expired and who is re-authenticating with AS which scopes should be approved.

For example, suppose the OAuth2 client redirects a user with the
requested scope 'a'. The user signs in to AS and is shown a consent=
screen asking to approve the 'a' scope. The user approves 'a= 9; and the
flow continues.

Some time later, when the user's session has expired, the user is
redirected to AS with the same 'a' scope.

Would it be a good idea, at this point, not to show the user the consent screen asking to approve the 'a' scope again ? For example, AS can<= br> persist the fact that a given user has already approved 'a' for a g= iven
client earlier, so when the user re-authenticates, AS will use this info and will avoid showing the consent screen.

That seems to make sense, but I'm wondering, can there be some security=
implications associated with it, any recommendations/advices will be welcom= e

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

--047d7b5d2fd28a63970529a736a1-- From nobody Mon Jan 18 21:46:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1DC1A9152 for ; Mon, 18 Jan 2016 21:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joHyc5wT2_YG for ; Mon, 18 Jan 2016 21:46:25 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611601A9127 for ; Mon, 18 Jan 2016 21:46:25 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id w75so155727131oie.0 for ; Mon, 18 Jan 2016 21:46:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=J4bbEbBNUsaJgNEoVwCTCqowq2NtEpNOt1dSNdu7Or4=; b=llJYkuSjCyp4KalBwXys9Ux2EEux53Wmlm7OOgx00koCVrssXuWK2sifkeLP2/3lWA 6ZjsIuUtZcwZzKelOv1PfZUmtA5tW/DHCcLSzVpSFXOTh8UTmi6e3AvE57iudkB5RiKF H6UaHM9RLWAr9JzY9viZ+Nj/iZ3mtPudAgoOFkdCXURDiHu1Q8j7pvxTk34hKIyPjxww 2uRFazzGusZ3cbCGQ165GdeHLBru+3fNBubxLeLY6/m9wcCPQjKKbg6X70B8O/YGZ1DJ 242qnP5NGYI+kX7vS1lLYyRcciyte5jaGs+9Vc2/oFUZiDEywFTx2bfxWSUaf5HYihZT xLVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=J4bbEbBNUsaJgNEoVwCTCqowq2NtEpNOt1dSNdu7Or4=; b=kUkF5TEA3wzapgpH5jLe9db0LE5xVnFgEsjue4Wb3qDtv8Va/gtE732KWti02cCOdi 6kmH0PcEsEvUJD+EfYPsxrTwmBWQb+I05E9KFapDL5zTKxUM83zglKyo3TzfAvb7TtyY itPn/f98tYiV4nGPiMatVRYkSD9D9nDccMKyFp8u3NtuEuohhZ/TPLPM5nNzbI4JNf7w ft8LfH5coTuY30FcORoROrz5F1jgyxZ3YJjsgxMqAmDpTaQEb7avPI2WAigzptBG3/QZ yHDfqvs3Lgl0qFDCi4Bbbl5ZmWmwhaQwam9tdGZRjjVXP0MtQJIq7FWVeBNS8YFBy5ew n53A== X-Gm-Message-State: AG10YOQtaNunwVzjXTI3bZRvzsN5Qe9g1D97bWq8BWuLLZIR/DvQ8LpQ0sTWjDPNm+nvuvoV5p2UMd9G6aPjjoIk MIME-Version: 1.0 X-Received: by 10.202.189.138 with SMTP id n132mr2955075oif.12.1453182384617; Mon, 18 Jan 2016 21:46:24 -0800 (PST) Received: by 10.182.227.39 with HTTP; Mon, 18 Jan 2016 21:46:24 -0800 (PST) Date: Mon, 18 Jan 2016 21:46:24 -0800 Message-ID: From: William Denniss To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a113d6d5ed47cea0529a9636c Archived-At: Subject: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 05:46:27 -0000 --001a113d6d5ed47cea0529a9636c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This month we rolled out full PKCE (RFC7636) support on our OAuth endpoints= . We'd previously implemented an earlier draft but were not conformant to the final spec when it was published =E2=80=93 now we are. Both "plain" and "S2= 56" transforms are supported. As always, get the latest endpoints from our discovery document: https://accounts.google.com/.well-known/openid-configuration If you give it a spin, let me know how you go! The team monitors the Stack Overflow google-oauth tag too, for any implementation questions. I'm keen to know what we should be putting in our discovery doc to declare PKCE support (see the thread "Advertise PKCE support in OAuth 2.0 Discovery"), hope we can agree on that soon. One implementation detail not covered in the spec: we error if you send code_verifier to the token endpoint when exchanging a code that was issued without a code_challenge being present. The assumption being that if you are sending code_verifier on the token exchange, you are using PKCE and should have sent code_challenge on the authorization request, so something is amiss. William --001a113d6d5ed47cea0529a9636c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This month we rolled out full PKCE (RFC7636) support on our OAuth endp= oints.

We'd previously implemented an earlier = draft but were not conformant to the final spec when it was published =E2= =80=93 now we are. Both "plain" and "S256" transforms a= re supported. As always, get the latest endpoints from our discovery docume= nt:=C2=A0https://accounts.google.com/.well-known/openid-con= figuration

If you give it a spin, let me know = how you go! The team monitors the Stack Overflow=C2=A0google-oaut= h=C2=A0tag=C2=A0too, for any implementation questions.

I'm keen to know what we should be putting in our discovery doc to = declare PKCE support (see the thread "Advertise PKCE support in OAuth = 2.0 Discovery"), hope we can agree on that soon.

On= e implementation detail not covered in the spec: we error if you send=C2=A0= code_verifier=C2=A0to the token endpoint when exchanging a code that was is= sued without a code_challenge being present. The assumption being that if y= ou are sending code_verifier on the token exchange, you are using PKCE and = should have sent code_challenge on the authorization request, so something = is amiss.

William




--001a113d6d5ed47cea0529a9636c-- From nobody Tue Jan 19 01:43:34 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 56C621AD068; Tue, 19 Jan 2016 01:43:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160119094331.7895.68438.idtracker@ietfa.amsl.com> Date: Tue, 19 Jan 2016 01:43:31 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 09:43:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 JWT Authorization Request Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-07.txt Pages : 16 Date : 2016-01-19 Abstract: The authorization request in OAuth 2.0 [RFC6749] utilizes query parameter serialization, which means that parameters are encoded in the URI of the request. This document introduces the ability to send request parameters in form of a JSON Web Token (JWT) instead, which allows the request to be signed and encrypted. using JWT serialization. The request is 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 19 01:45:22 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055DA1AD055 for ; Tue, 19 Jan 2016 01:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.309 X-Spam-Level: *** X-Spam-Status: No, score=3.309 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7t4FYy_huvw for ; Tue, 19 Jan 2016 01:45:20 -0800 (PST) Received: from nrifs02.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id B356C1ACF5B for ; Tue, 19 Jan 2016 01:45:19 -0800 (PST) Received: from nriea04.index.or.jp (unknown [172.19.246.39]) by nrifs02.index.or.jp (Postfix) with SMTP id DB165196880; Tue, 19 Jan 2016 18:45:18 +0900 (JST) Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea04.index.or.jp (unknown) with ESMTP id u0J9jI4D018932; Tue, 19 Jan 2016 18:45: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 u0J9jI75051238; Tue, 19 Jan 2016 18:45:18 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u0J9jIfX051237; Tue, 19 Jan 2016 18:45:18 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u0J9jIB6051232; Tue, 19 Jan 2016 18:45:18 +0900 From: "Nat Sakimura" To: "'William Denniss'" , References: In-Reply-To: Date: Tue, 19 Jan 2016 18:45:28 +0900 Message-ID: <046601d1529e$213c10b0$63b43210$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0467_01D152E9.91273B20" X-Mailer: Microsoft Outlook 15.0 thread-index: AQFmWO0EHwXYNXWS+OyceOcyoSZ/G5/Yijog Content-Language: ja X-MailAdviser: 20141126 Archived-At: Subject: Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 09:45:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0467_01D152E9.91273B20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Wow, Congratulations, and thanks very much! =20 Best,=20 =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 William Denniss Sent: Tuesday, January 19, 2016 2:46 PM To: oauth@ietf.org Subject: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE = (RFC7636) =20 This month we rolled out full PKCE (RFC7636) support on our OAuth = endpoints. =20 We'd previously implemented an earlier draft but were not conformant to = the final spec when it was published =E2=80=93 now we are. Both "plain" = and "S256" transforms are supported. As always, get the latest endpoints = from our discovery document: = https://accounts.google.com/.well-known/openid-configuration =20 If you give it a spin, let me know how you go! The team monitors the = Stack Overflow google-oauth = tag too, for = any implementation questions. =20 I'm keen to know what we should be putting in our discovery doc to = declare PKCE support (see the thread "Advertise PKCE support in OAuth = 2.0 Discovery"), hope we can agree on that soon. =20 One implementation detail not covered in the spec: we error if you send = code_verifier to the token endpoint when exchanging a code that was = issued without a code_challenge being present. The assumption being that = if you are sending code_verifier on the token exchange, you are using = PKCE and should have sent code_challenge on the authorization request, = so something is amiss. =20 William =20 =20 =20 =20 ------=_NextPart_000_0467_01D152E9.91273B20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

W= ow, Congratulations, and thanks very much!

<= o:p> 

B= est,

<= 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=C2=A0 and delete this e-mail.

<= o:p> 

From:<= /b> OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of William = Denniss
Sent: Tuesday, January 19, 2016 2:46 PM
To: = oauth@ietf.org
Subject: [OAUTH-WG] Google's OAuth endpoints = now fully support PKCE (RFC7636)

 

This month we rolled out full PKCE = (RFC7636) support on our OAuth = endpoints.

 

We'd previously implemented an = earlier draft but were not conformant to the final spec when it was = published =E2=80=93 now we are. Both "plain" and = "S256" transforms are supported. As always, get the latest = endpoints from our discovery document: https://accounts.google.com/.well-known/openid-configur= ation

 

If you give it a spin, let me know = how you go! The team monitors the Stack Overflow google-oauth tag too, for any = implementation questions.

 

I'm keen to know what we should be = putting in our discovery doc to declare PKCE support (see the thread = "Advertise PKCE support in OAuth 2.0 Discovery"), hope we can = agree on that soon.

 

One implementation detail not = covered in the spec: we error if you send code_verifier to the = token endpoint when exchanging a code that was issued without a = code_challenge being present. The assumption being that if you are = sending code_verifier on the token exchange, you are using PKCE and = should have sent code_challenge on the authorization request, so = something is amiss.

 

William

 

 

 

 

------=_NextPart_000_0467_01D152E9.91273B20-- From nobody Tue Jan 19 01:55:04 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918CF1AD0AD for ; Tue, 19 Jan 2016 01:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.608 X-Spam-Level: X-Spam-Status: No, score=0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIRmweKAbgQo for ; Tue, 19 Jan 2016 01:55:02 -0800 (PST) Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58AE1AD0AB for ; Tue, 19 Jan 2016 01:55:01 -0800 (PST) Received: from nriea02.index.or.jp (unknown [172.19.246.37]) by nrifs03.index.or.jp (Postfix) with SMTP id 4CAA217EA40 for ; Tue, 19 Jan 2016 18:55:01 +0900 (JST) Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea02.index.or.jp (unknown) with ESMTP id u0J9t1Ah025294 for ; Tue, 19 Jan 2016 18:55:01 +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 u0J9t0n3050728; Tue, 19 Jan 2016 18:55:00 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u0J9t0w0050727; Tue, 19 Jan 2016 18:55:00 +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 u0J9t0X5050724 for ; Tue, 19 Jan 2016 18:55:00 +0900 From: "Nat Sakimura" To: References: <20160119094331.7895.68438.idtracker@ietfa.amsl.com> In-Reply-To: <20160119094331.7895.68438.idtracker@ietfa.amsl.com> Date: Tue, 19 Jan 2016 18:55:11 +0900 Message-ID: <047501d1529f$7c7b7b40$757271c0$@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: AQGHmPdrDB93G3/pOdb2tld9cUlLxJ+WClzA Content-Language: ja X-MailAdviser: 20141126 Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 09:55:03 -0000 Hi. Took much longer than I anticipated but I finally applied the comments I received during the WGLC. When broken down, there were 44 comments that needed to be dealt with. I have accepted most of them. There are a few discussion points, and a few rejects. I am now making the list of those, but as I am going into a meeting now, it will not be available before tomorrow. For a preview, you can go and see them in https://bitbucket.org/Nat/oauth-jwsreq/issues?status=new&status=open. There are two sets of comments provided by Mike and Brian as of the time of this writing. They have unresolved comments. I have recorded my dispositions there so if you are so inclined, please have a look. I will pull out those points as separate issues in the tracker so that they can be individually tracked. Cheers, Nat Sakimura -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Tuesday, January 19, 2016 6:44 PM To: i-d-announce@ietf.org Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : OAuth 2.0 JWT Authorization Request Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-07.txt Pages : 16 Date : 2016-01-19 Abstract: The authorization request in OAuth 2.0 [RFC6749] utilizes query parameter serialization, which means that parameters are encoded in the URI of the request. This document introduces the ability to send request parameters in form of a JSON Web Token (JWT) instead, which allows the request to be signed and encrypted. using JWT serialization. The request is 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-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jan 19 01:59:39 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931F51AD065 for ; Tue, 19 Jan 2016 01:59:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGulclPa0uP8 for ; Tue, 19 Jan 2016 01:59:36 -0800 (PST) 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 88C2B1AD055 for ; Tue, 19 Jan 2016 01:59:36 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id n5so102945608wmn.0 for ; Tue, 19 Jan 2016 01:59:36 -0800 (PST) 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-type:content-transfer-encoding; bh=kBQHXCMtmr9ItNY+wwJbJrl9LFBldj+iUv1FjsMYOEU=; b=GU5goMN6sSVhv39feMyy2YnYW0KxHqgbmYisiJng3fQtEMMuJKnpccWRY2ZyHd9+LN XMRFwOtK9hDjJMAJHhk8a3ocyFz2rA3l7tdq+uAfbdn9cMONv7QLqysvaiABUug9OXgY cpe2WvQftKt/p/+LKUmHogUXvjKz+uPP+4+bGk0dU4rN5Pv6MqAMp3MdXf8QRD6xYlFg PbQtNAuI0MlfhByssCHsPahh2whceB7TtAH6cYePouCUlFVYZM17ZZg6OG299CaxD0Ir CAtYECOBtJqv4EfgAN/u2VXQinOUVEhUW2ZPx3vGTLh5MiX5PYCw/greFp2Uhejm+EG6 Laog== 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-type :content-transfer-encoding; bh=kBQHXCMtmr9ItNY+wwJbJrl9LFBldj+iUv1FjsMYOEU=; b=LY3VML1yzIVRBsiLlopkLESENukuyQP8Q3IMwx3/IO7/GERTj43LmmvokLQfu2Fg4+ OWAJ03Pu6D2zAZPtvQec8TwmOhovmSA1FUG6Nue+X0PS03cdR1jDVtxuVuJXFjXvSm4m 2kM1k93pnZnPM4oCUH1EI6dSDE9yKPw3CgKnX/mFm5vnl9OyGciJa950aQAZhXaholtK zZXrWi/ljXBFKtiWSJE3NQkwPciFeqe3ek+4BqieIi5plZlttvuY/aQ1CeV85x9AdB0e DSnKxQC0uezvHBJHN0/ADWiB1CO6IVs+/96WO616YNQ2HOO6VCqbCCtxq0XOWMJAXGWS TLFQ== X-Gm-Message-State: AG10YOQTAgW87y5rfCbRuBfxIpaLQxQCK1uWoTKvD/ebHePtHuBSX0EoHjwDaE4PL5jzDg== X-Received: by 10.194.188.100 with SMTP id fz4mr24092380wjc.126.1453197575174; Tue, 19 Jan 2016 01:59:35 -0800 (PST) Received: from [192.168.2.7] ([79.97.184.64]) by smtp.googlemail.com with ESMTPSA id l2sm27711056wjf.15.2016.01.19.01.59.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jan 2016 01:59:34 -0800 (PST) To: William Denniss References: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> <569CDE25.90908@gmail.com> From: Sergey Beryozkin Message-ID: <569E08F6.4040600@gmail.com> Date: Tue, 19 Jan 2016 09:59:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 09:59:38 -0000 Hi William Thanks for the advice. FYI we are also on the way to supporting the incremental authorization of scopes - thanks for highlighting the importance of this process on this list... Cheers, Sergey On 19/01/16 03:10, William Denniss wrote: > Agree with Justin, this is pretty common. We support it for re-auth as > well as incremental auth (where the user has already approved scope "a" > and is presented with a request for scopes "a b", they will only need to > approve scope "b"). In fact if you don't do this, then incremental auth > isn't really viable. > > Regarding security: don't do this for non-confidential clients where you > can't verify the identity of the app by the redirect (e.g. a localhost > redirect to an installed app). > > On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin > wrote: > > Hi Justin, thanks for the advice, > > Cheers, Sergey > > On 18/01/16 11:47, Justin Richer wrote: > > Yes, this is common practice. Give the user the option to > remember the > decision. This is known as "trust on first use", or tofu. Our > server, > MITREid Connect, implements this as do many others. > > > > -- Justin > > / Sent from my phone / > > > -------- Original message -------- > From: Sergey Beryozkin > > Date: 1/18/2016 5:59 AM (GMT-05:00) > To: oauth@ietf.org > Subject: [OAUTH-WG] Can the repeated authorization of scopes be > avoided ? > > Hi All > > The question relates to the process of showing the authorization > code/implicit flow consent screen to a user. > > > I'm discussing with my colleagues the possibility of avoiding > asking the > same user whose session has expired and who is re-authenticating > with AS > which scopes should be approved. > > For example, suppose the OAuth2 client redirects a user with the > requested scope 'a'. The user signs in to AS and is shown a consent > screen asking to approve the 'a' scope. The user approves 'a' > and the > flow continues. > > Some time later, when the user's session has expired, the user is > redirected to AS with the same 'a' scope. > > Would it be a good idea, at this point, not to show the user the > consent > screen asking to approve the 'a' scope again ? For example, AS can > persist the fact that a given user has already approved 'a' for > a given > client earlier, so when the user re-authenticates, AS will use > this info > and will avoid showing the consent screen. > > That seems to make sense, but I'm wondering, can there be some > security > implications associated with it, any recommendations/advices > will be welcome > > 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 Tue Jan 19 03:03:47 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32FB1B2AAC for ; Tue, 19 Jan 2016 03:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNQR2cqWjx4b for ; Tue, 19 Jan 2016 03:03:36 -0800 (PST) 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 E8A991B2AB4 for ; Tue, 19 Jan 2016 03:03:35 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id n5so105753156wmn.0 for ; Tue, 19 Jan 2016 03:03:35 -0800 (PST) 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-type:content-transfer-encoding; bh=dndxkkr6iwpIJAofjN9onz5g64mMlzctHW13i8QJbBk=; b=H3gBq7Uk0DpbMHuqEd9on1AzpIiZCcEiuNa8YjMjUjQItXgaQkwpWdeTZZPCymERpI 2aQuTKGU27dSeEi4j1d5WMnpQf53nUZkX2kD7bBvEVR2W8Db4MhkWhKDLkq36m0oKK2J Qrbmw+IfzmWUwbqwWHsV2XLozapuZw4IjV8+YKsD+rn8+vC2Sh6stouIxcK5DO0wBtzE qcExRplvYljbPrNpzRXoXm1l8zEZhMElsageGQX+k95pFq9ZIKMetbpyMnYcF/xzmuef c+4ISu754pzZS+bmIMQfb0/vzQ6rNsVc2ApUCZiXZVA1EaQX6gB0T8TIp3S3qhBYHNwV +caA== 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-type :content-transfer-encoding; bh=dndxkkr6iwpIJAofjN9onz5g64mMlzctHW13i8QJbBk=; b=N4Z59yWV4AhUVRJs+TT4KdM7mLPljjJCSGLKZVhFOe99ixpDr9/9ORbPNGlojnDWxH 741PU66zh6pNnLJpsd6wO4gvEJNWH9XVOksd0amwsqnEg1YJ+TN2kcYi6QohkHtjd2V8 D4xLKZ8r1cJNqD7Y61oK7NekETMyTfoywMN59VdXvsbccu6662zCuch/itnpXcNT/1PC suQqTTBvNuTU1frxBVRJCqDr8FPoUNLj70Tma/IXyVOjIyosy+oAZMsqQNe+hnTVmZEP ExQfj3GvxUyzbi3DqoowXZCc6Ff2Cl9Im2qRjk8+GKh18XwEq5WdcVbD5c2zzBB4abIL nJ9Q== X-Gm-Message-State: AG10YORRnYoNEU+Hn2wfmydQZXcfKkhfVb88uxbjUffHuhYxl71Dpps3I/3d5WNTRfm4xA== X-Received: by 10.28.11.77 with SMTP id 74mr19388875wml.36.1453201414517; Tue, 19 Jan 2016 03:03:34 -0800 (PST) Received: from [192.168.2.7] ([79.97.184.64]) by smtp.googlemail.com with ESMTPSA id gb9sm27984101wjb.26.2016.01.19.03.03.33 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jan 2016 03:03:33 -0800 (PST) To: Justin Richer References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> From: Sergey Beryozkin Message-ID: <569E1804.8010803@gmail.com> Date: Tue, 19 Jan 2016 11:03:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569D1631.4030705@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Question about RFC 7622 (Token Introspection) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:03:43 -0000 Hi Justin You mentioned a token expiry policy can be that this token will expire after a number of uses, in addition to a standard expiry time check. Is there a standard mechanism to report to AS the token is being used (for the purpose of accessing RS resources) ? I wonder if an actual token introspection request is sufficient to indicate to AS that the given token is being used right now to access RS - given that the actual client can now also introspect tokens without using them to invoke RS services. is it up to AS Introspection endpoint to figure out the identity of the caller, example, if it knows it is RS then it will increase the usage count, if a client - won't ? Thanks, Sergey On 18/01/16 16:43, Sergey Beryozkin wrote: > Hi Justin > > Sorry I did not copy to the list with my previous response... > > That sounds convincing, I was about to suggest that AS may opt not to > report the expiry time simply because it is an optional property, but I > guess that would be just an argument for the sake of the argument :-), > as I guess in practice AS will report the expiry time of the tokens that > actually expire... > > Many thanks, Sergey > > > > On 18/01/16 16:28, Justin Richer wrote: >> If the AS doesn't include the expiration then that means that the RS >> doesn't know anything about the token expiring or not. This can be >> caused by: >> >> 1) The token never expiring from a timestamp (could still get revoked >> or expire after a number of uses) >> 2) The RS not being allowed to know if the token expires >> >> Either way, the RS doesn't know anything about the token expiring or not >> and so should treat it as if it hasn't expired since that's all the AS >> has told it. An RS trying to second guess the AS response here is going >> to get into trouble. >> >> If the token expires "shortly" then there would be an expiration in the >> response, if the RS is allowed to know that. There's no interoperability >> issue here, still, and a special value wouldn't fix this. >> >> -- Justin >> >> On 1/18/2016 11:10 AM, Sergey Beryozkin wrote: >>> Hi >>> >>> If the only way for AS to indicate the token has expired is not to >>> report this value, while the other AS does not report the specific >>> expiry time simply because the expiry property is optional, then RS >>> working with both of those 2 AS has no way to understand if a given >>> token expires shortly or never expires at all. >>> >>> That is why I'm thinking having no special value indicating the token >>> does not expire is an interoperability issue (the communication >>> between RS and third-part AS servers) >>> >>> Thanks, Sergey >>> On 18/01/16 15:55, Justin Richer wrote: >>>> That's a problem for the RS to figure out in its logs system regardless >>>> of whether you choose a "special" value for non-expiration or not. I >>>> don't see how this changes interoperability. >>>> >>>> -- Justin >>>> >>>> On 1/16/2016 4:50 PM, Sergey Beryozkin wrote: >>>>> Hi Justin >>>>> This is reasonable and it works with the introspection protocol >>>>> because the text says 'active' means AS must've checked the token has >>>>> not expired, but even so, it is in a 'conflict' with the >>>>> interoperability concept. >>>>> Consider a simple case where RS wants to log "Client uses access token >>>>> with this ID, the token expiry time - this time/never" and some other >>>>> RS wants to block the requests with the token which will expire in >>>>> less then say 5/10 secs. >>>>> When this RS works with one AS - this AS thinks it should not report >>>>> the expiry time because it means omitting it indicates the token never >>>>> expires. The other AS does not report it because: it either does not >>>>> know how to rep a 'never expires' value. The next AS thinks it is not >>>>> needed to be reported at all. >>>>> What should RS do willing to do the above tasks around the expiry time >>>>> do :-) ? >>>>> >>>>> Thanks, Sergey >>>>> >>>>> On 16/01/16 16:14, Justin Richer wrote: >>>>>> All the values in the token introspection response are optional, >>>>>> except for “active”. If you don’t have anything to say about a >>>>>> particular aspect of the token, or can’t say it to the software >>>>>> that’s asking, then you generally leave it out of the response. >>>>>> >>>>>> — Justin >>>>>> >>>>>>> On Jan 16, 2016, at 11:02 AM, Vladimir Dzhuvinov >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 15/01/16 15:47, Sergey Beryozkin wrote: >>>>>>>> Hi John >>>>>>>> >>>>>>>> Thanks, looks like it was a last minute change because Introduction >>>>>>>> does not explain why would clients want to use the introspection >>>>>>>> endpoint to effectively 'unwrap' the opaque token representations. >>>>>>>> >>>>>>>> I have another question. How to report the expiry time in cases >>>>>>>> when >>>>>>>> the tokens do not expire ? I'm aware of some deployments where >>>>>>>> access >>>>>>>> tokens are only manually deleted and otherwise would not expire. >>>>>>>> >>>>>>>> Perhaps not reporting the expiry time is equivalent to the token >>>>>>>> never >>>>>>>> expiring ? Or may be reporting 0 or -1 works ? >>>>>>> >>>>>>> The core OAuth 2.0 spec seems to imply the former: >>>>>>> >>>>>>> http://tools.ietf.org/html/rfc6749#section-5.1 >>>>>>> >>>>>>> Using a zero or negative integer may not be a good idea, as >>>>>>> clients may >>>>>>> just take the value as it is and add it to the current system time, >>>>>>> concluding that the token has expired :) >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Vladimir >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, Sergey >>>>>>>> On 15/01/16 13:32, John Bradley wrote: >>>>>>>>> Some people wanted the client to be able to use introspection. >>>>>>>>> >>>>>>>>> The ability to pass a refresh token is a legacy of that. A RS >>>>>>>>> would never have a refresh token unless it is acting as a client. >>>>>>>>> That is correct. >>>>>>>>> >>>>>>>>> John B. >>>>>>>>> >>>>>>>>>> On Jan 15, 2016, at 5:34 AM, Sergey Beryozkin >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> I'm reviewing RFC 7622 as we are going ahead with implementing >>>>>>>>>> it. >>>>>>>>>> I have a question: >>>>>>>>>> >>>>>>>>>> 1. Token Hint in the introspection request. >>>>>>>>>> The spec mentions 'refresh_token' as one of the possible >>>>>>>>>> values. But >>>>>>>>>> a protected resource does not see a refresh token (ever ?), it is >>>>>>>>>> Access Token service which does. >>>>>>>>>> When would a protected resource use a 'refresh_token' hint when >>>>>>>>>> requesting an introspection response ? >>>>>>>>>> >>>>>>>>>> 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 >>>>>>> >>>>>>> -- >>>>>>> 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 >>>>>> >>>>> >>>>> >>>> >>> >> > > From nobody Tue Jan 19 03:39:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7551E1B2C74 for ; Tue, 19 Jan 2016 03:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTIKpy7L8Kh1 for ; Tue, 19 Jan 2016 03:39:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E98E1B2C70 for ; Tue, 19 Jan 2016 03:39:39 -0800 (PST) Received: from [192.168.10.141] ([82.142.85.169]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Me4Ly-1aUwXG2Hk6-00PvIU for ; Tue, 19 Jan 2016 12:39:36 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <569E2076.2090405@gmx.net> Date: Tue, 19 Jan 2016 12:39:34 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lfBkpM3SKnjShm9iRxNnaFjKduq8dr97n" X-Provags-ID: V03:K0:IMRaCCQyfyvWJXkzhtt2UwjigZ/XeJCuHdrycIMQxYlHPmVs1Dx iiXJLp1roZZMwpGrQoX4eKgpt5qqGatJxdmFBvWEDo6i59RwYTCOPawWE4N0F/dLSF5hpE2 ttD73ZHFTn2jFkVttZsoEf4bUsPUgFfJC0g+kLPJEk0DL565lHGLG3e9CdNIEIZA4Cnzr5C vLmonVTILxzM44Lm4hxKA== X-UI-Out-Filterresults: notjunk:1;V01:K0:MbOcK7VYWvY=:0hPJSHkFtOOFA0kTlLMhCT LJgto2DCkJPdn9ZqAFmSJ50EuczigKPWISNFsl3YP3D+zyRqHt+6d5mQzJPScby8fd84cwFZh Kd6liP6pVpQ+R8amXMJsqc645p6l/E3BH8oL0k+AG6/dN9xl68XKJ5IookoRZi4x9cZw/uTEo gbP0k5v1s15NIFXgHpn1mWFqmT20fpVTJ5pj6MfPg40SSrfLvH2M7Gz6Z06PwQ0kX4CJ/sfN+ rKtY5TabKryuk44lCIqV1Z1NaXBkR4CHck1SgiXQR9718hzVV+ztnPy0zqsYWbAhs83HCmtz/ bcyawhouaE85laNXbVR/Gjdw21N9cWNHmCdC7ka6KKtgmAcjDrWML2hhG/ZA3HxdGwjfDlpPX r2+elu9knAdUFjyMcTglLGbk5l/n19ayze/GxMQWt/+bM0TeJr8oVC2sSK1iMHzsTVGToFpmM N+yuWdYLzIeov+SuBBMIYWDEWy0iqlRooQb6RFBQmxRnPIY9J/soCWcBjvSo8j/1VF0dxqeZG clyElsdagsHEbw4kFKHAukBMTVmwcOEm761Tu7mQBjnfzmxHYgvNwUbouiGHdsIqGNyYTG3EV aU8PwLQ08ZKiEUHISZDQQ6rLHM/oFKhzjIvivFhRz5k8wcALFu2D3Bnd+0QtP5i8xebkUflPh PagxEC2q1ea/N0zB6A9sojNlrsLvxazb2anD45rVvKybk9Vqd9xiYDtNSUSCKRNQLB9AMfxrs hm6agwwObFJKA5igy4/dHmu4VzPLQPbRHZQg7qoeHprxRRPI1NsZ5hDvTT4= Archived-At: Subject: [OAUTH-WG] Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:39:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lfBkpM3SKnjShm9iRxNnaFjKduq8dr97n Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, we have submitted our new charter to the IESG (see http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and since some IESG members like to see an updated list of milestones as well. For this reason, based on a suggestion from Barry, we are also starting a call for adoption concurrently with the review of the charter text by the IESG. We will post separate mails on the individual documents. Your feedback is important! Please take the time to look at the documents and provide your feedback. Ciao Hannes & Derek --lfBkpM3SKnjShm9iRxNnaFjKduq8dr97n 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 iQEcBAEBCgAGBQJWniB2AAoJEGhJURNOOiAtDzcIAKYUIS9uhU6z2gUpiEkYfxvY LsY2VfbdjRDkLIIJSl9s5oXDGGWifFuq2rIfTR5IhAer5qxICksMJ8q2qjFPNTNd mL6zCKanuaN9EzoZulYUmnki3dHS29wcTmbf1vGmkjShu/XTf96QPuG8rD7wNUtJ bp5/h3im7yRiJ5CiuagtWkc/yi9AQoyOG4Mxu9lSFe4bAMIRfYNArOQ7VR8JCsCN KpYSDKNNbA3Z24t2YMNuqDmwWpbKK+ghGlKgOMcle71n6dP/PTUps53cW7Lw72B4 4VLnsSL9kGmfzFcWCwjXeOhGf41nx87gzfSWaewabJ3ynKtkFtVL2RMgUmfddSg= =4gGI -----END PGP SIGNATURE----- --lfBkpM3SKnjShm9iRxNnaFjKduq8dr97n-- From nobody Tue Jan 19 03:45:38 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F521B2C9C for ; Tue, 19 Jan 2016 03:45:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIq068H7OZGm for ; Tue, 19 Jan 2016 03:45:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630A01B2C91 for ; Tue, 19 Jan 2016 03:45:33 -0800 (PST) Received: from [192.168.10.141] ([82.142.85.169]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MSduu-1akpcF1a3Y-00RcAm for ; Tue, 19 Jan 2016 12:45:31 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <569E21DA.30002@gmx.net> Date: Tue, 19 Jan 2016 12:45:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KpnuaGWIJkFDPQ3hsROfdMSaRJWpo6sS6" X-Provags-ID: V03:K0:CSMyLyJS3samXTQbg7IMAmaoKUhxPN8qYzReOd9WPQWg4bbN6RZ f2eMedRqSb0EuEzkIrAcgYh9YUMPFdG7FuDR29lJTLbSHnA+hUipvv6YYMPLHQsj3Rbdu+D 89GzAHsiE80XHqCJBJdA3agqnjwU1rmYNCUiPtkW2cYnAqto0Ly/XZW9kTS3/RtlgofhIWn MUhoK1W/hYKz/MbLmwFiQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:poJBHBYV794=:79l2vXdB78NL2/LObPY2uR sJAl6vcyZ9rd4TDC2iJF4+yMD5g+LNzgSkn2zCwqEDpjVjraFgP5wrjsNJEN5MTWklqodaErf l6V3oxPQ0eqJ/4zxenEhF6/lre1EiNF1E/FGdyRgIwBNGV2p3RpRVfS6v8ImeCmA1y5E+YdyY ysjK//FHHUTzsEqcqWbWXE7Pnh+ZsgDu7RIC2OC3TwM++k6ssu0nCsknVUKc4/pxMC//1UoFX I9DmXBgWVTARto+dX2Oqv2tDjaAY/r1KJmFr+tOPsojEYXo+Uf+M8xxosQdVPolafpkRVZVfq /ZX9AgE5ZutUd618ftq0Opx0laIm954UdXXoTOrBWWutIR8Tg5qoP85wE3V7oHYoLs66HDC9c xiKnO0qBUzSdosQCZcBBsNBHl4ETjkKt3Ln/hLoAxEZDJhURoVMpE031NsltE5KjetE9G7ps3 Ju3Iu3T2OYgTBmEfU8wmTR5KsacN51Run5D06XoRVUELlD3GMJ0bRpbKviUfX7WyLNuVTU6kk 3BrGwulxV+mZwbHj0kO7eIIJzBDd7RJubCqv3wMnTRwaEGTZSHdwc3APCLSOEHPZRZ7Ewp1gJ rqImPdAgWzJBET0Yh4ud2URZIyWzoMxqwBo5duqorTmKehXhvVEVSBTmMSGKVAIa4P2OmOXgD vJ4Qfdkj4M6oDZ/k42EP8jWYo4bVvfReC6KGmgokvIXRSgTH1LV1FYkA/5rP7rI5tw6lrYj+2 mtnz/7LO8YkUsW6YumIaZwIFNytxmNVKk94+FozbshUnFMcUHmGCAitZpaY= Archived-At: Subject: [OAUTH-WG] Proof of Possession Tokens: Next Steps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:45:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KpnuaGWIJkFDPQ3hsROfdMSaRJWpo6sS6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, I wanted to drop a high level message about possible next steps for the PoP work. As you have seen from my status update, see http://www.ietf.org/mail-archive/web/oauth/current/msg15327.html, the PoP architecture document was already in IESG processing but I have had asked Kathleen to delay the publication given that we ran into scoping issues, as discussed on the list. See http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html The change of scope related to desire to not just binding a key to the access token but also to other parts of the OAuth system to avoid cases where an attacker can just obtain attack other parts of the system instead (for example, by obtaining an bearer-based refresh token to then obtain a new PoP access token). The recently discovered security problems tell us that we need to simplify our solutions a bit as well to ensure that we get the security analysed properly. More options means more time to analyse all the different options. What does this mean to simplify when I talk about expanding the scope in the earlier paragraph? I am suggesting to * to consider focusing on a public key-based only solution for the web/smart phone app space. (The ACE working group will have to develop a symmetric key-based version on their own, if desired.) * to extend the support of PoP token functionality throughout the entire solution. This means that we have to include support for a asymmetric version of PKCE into account (which had been discussed in the group already earlier already). * to define at least a TLS-based security security solution for the communication between the client and the resource server. * to rethink the work on the application layer security solution. The HTTP signing draft, which defines the application layer security solution for use between the client and the resource server, has expired and we will have to find new authors. I believe we got stuck a bit. Luckily new persons came along and volunteered to help, namely Fredrik Ljunggren and Jakob Schlyter. Nevertheless, the group will have to judge whether a newly developed application layer security solution is promising. My impression is that it is a very difficult to come up with a solution that satisfies the security requirements and, at the same time, also takes the deployment status of proxies and other middleware into account. * to make a decision about other extensions. Nat and Kepeng submitted the Sender Constrained JWT for OAuth2 2.0 document, see https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06 We asked the working group for feedback during IETF #93 and we couldn't get enough feedback at that time. Please give us feedback whether you are interested in exploring that solution direction as part of this process. Today, we don't have enough indication of interest for working on that solution direction. Before making any changes to the PoP document set we would like to hear your thoughts. Ciao Hannes --KpnuaGWIJkFDPQ3hsROfdMSaRJWpo6sS6 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 iQEcBAEBCgAGBQJWniHaAAoJEGhJURNOOiAth+UH/idof6gzNzIg+/LCAYW4Roty qEbRviO/weI+Zj3mg7HeMI6eCfl1KdPN7dfQZEDphbbpKyHuhfmoQnrz2vGrm9f1 p1i7oQQ/SJH69PEivqH0Y05eI3I4FTLwQUTctvSk7iFA6thAtRCTP03cw8+w0ggE TJJ2OFhn6vVpamFhwYYRQX0wnNV6Q0ZL+Ct7Kfz4Rjz7eU6VuB2wRu9c2A72WrXz k80VzkUq61XZ570cHQETyo2QFw+0CA/ms0RlOJbzda90uaOV8xj4hitSgRyrbd5e Yhvq7K0nMFTbu798AbLEKGgM6ZaaleQAjmZYg+s+e8yzE3kHODLAjqA3ncl6kF4= =1M7F -----END PGP SIGNATURE----- --KpnuaGWIJkFDPQ3hsROfdMSaRJWpo6sS6-- From nobody Tue Jan 19 03:47:05 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA06C1B2CA3 for ; Tue, 19 Jan 2016 03:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKumvEMHmgx1 for ; Tue, 19 Jan 2016 03:47:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9C21B2C9E for ; Tue, 19 Jan 2016 03:47:00 -0800 (PST) Received: from [192.168.10.141] ([82.142.85.169]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MIe0O-1aJItO3yTg-002Eb3 for ; Tue, 19 Jan 2016 12:46:59 +0100 From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 To: "oauth@ietf.org" Message-ID: <569E2231.1010107@gmx.net> Date: Tue, 19 Jan 2016 12:46:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8Kt7Ve6AQv8uF7F9JLBt2AINjJRTQ6jG5" X-Provags-ID: V03:K0:W3k5gTIYmmr/xnHGgTTDDB8180jE/C+jH/cgmW15cqrmfPnPCrv HB37ArUT5vshAdbmv83jl3WY8DRX6EKMO4glw8OL0TcfA2Yk7Y3fEoZqii8mQJEqLfjRCZ5 JqK5CHPV/8cS6XfGwc7INztBIS9Cm+v0/ps1RMTbNjhazi8Kd9yKHe08qDn7t8GeAP7g4zz mPMPvdxCTUC3SwXA0oHiA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Gxoib5GXkHA=:D3EIDBvG2yYsH1wOGPkRpV akYS0a/cw/C0TBR+rhz+8aXTFQmZhvTMYWqwBPpVLY+WwvVRZb32JQ3+q7p4lAPaeP1iZEzk5 q6qUAMG50Hjq49V+Y0BTnz4Pyxsl+purpenaLd+LHAeFBLPUpdBR4sSe+FKxTqhjojFiM2OBG TMIjBx35MI88/4HmgexnEKc9YtIM0yC1qUkVRzR7TwZfzuNaVO3vO2xdDFejlZSw49xTPsNt2 g5s1zbLGykOz3hE47FGwXy2DdD+u9f/q8oXi05SIG/wU+YKoce/fkHkenMBny4H1OdqjTtn35 h/797SaE1Sy5Gle4EOI0ux8fRs/6uUsAhZS18Ck3f0Z7Nh2bnH8uKSk2JUyv+iYyuRuH5P7IB x+bkV7FkrdKqAkinckVpohCaeWWgHN6mQ6HfI6OfKOUZNlyQxm80yDLlYRkAMxrV4QkuwaQZr FGepRFHuo2y2qUo0CBA+Ix9BGmgstg8KfS5I7WPJO20ycIfyk5q+07NzdK8XUN0XJDkGMocrC 7ryb1DkKKqpcLY376Qe7uzJX4LgFtC64hPOVHPyw/YBIBJmI+w2Fal8bqZCbEgfeohmoDWdR8 TwyIHWim/ysVNlAUKQYNfa0J++SGpU3XQRDLMBss77/4KGTa4h2pySfjifc5wXohMk7uQSpg7 3lLnqE2RRGsxuJwK5Ep4ohGiLph7b20JsAP/cjQYFsL9420vzXAhRPmJa4CfRblXrNELXwoBV o+lI0VgmkklSIZL8sRijkK9kmTRuaL+xyJAwVEOpwvFvPXngRfTPBkZ2m/8= Archived-At: Subject: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:47:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8Kt7Ve6AQv8uF7F9JLBt2AINjJRTQ6jG5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, this is the call for adoption of OAuth 2.0 for Native Apps, see http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ Please let us know by Feb 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Note: If you already stated your opinion at the IETF meeting in Yokohama then you don't need to re-state your opinion, if you want. The feedback at the Yokohama IETF meeting was the following: 16 persons for doing the work / 0 persons against / 2 persons need more info Ciao Hannes & Derek --8Kt7Ve6AQv8uF7F9JLBt2AINjJRTQ6jG5 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 iQEcBAEBCgAGBQJWniIxAAoJEGhJURNOOiAt++MH/ibeI/omdW6rUGPXwWNNKTtO sCP5iMEVN9FviC+ISiVyIAV8dIApeXgHtqsOH2kfXXOXc3NliXO7nQYd8xjCxryk oGPTiXKj/Ss8TisR8nNYssqBfkREOMTFHsfU2IztB8I/SjkVikUYsBSzr4G/Gpy2 5QG+uYs7bG8P+IN1xfrlhkdS3mi7FnITwo1+5K46+71B/qiNP+2JWTucUCb6wf7z 1NZlhAPEmmSXwHgcS0pS4eJx7GMyN6MdAsif4En6OfxOa88ShUlEXOPyOpFEDxzp XZ9yTeXa6ZpjVyjQMcxb83qzQixj5xWjs6xUhZ42d46xO6sZ3eMU4fys24hr0Ag= =C+vu -----END PGP SIGNATURE----- --8Kt7Ve6AQv8uF7F9JLBt2AINjJRTQ6jG5-- From nobody Tue Jan 19 03:47:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582A91B2CAE for ; Tue, 19 Jan 2016 03:47:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QCabird0_Uf for ; Tue, 19 Jan 2016 03:47:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C90F1B2CAA for ; Tue, 19 Jan 2016 03:47:47 -0800 (PST) Received: from [192.168.10.141] ([82.142.85.169]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Lubnw-1aCrrN1GqG-00zrZX for ; Tue, 19 Jan 2016 12:47:45 +0100 From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 To: "oauth@ietf.org" Message-ID: <569E2260.4080904@gmx.net> Date: Tue, 19 Jan 2016 12:47:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="33NG1bUkpMjkBkdnDOMi0DJv45pAtEjX0" X-Provags-ID: V03:K0:dfO+M0EnS1xBerp6UPk4tS90Pc2kuF43Ljq7zaeSw1vClH58Wvh pGiTLU+HzdTud4jrqu/rcLFh7TMOq04qaXqiaXIkFFYjcFGqQus3jke96i3avBsiUNX38iu wZbayWeP/J/DhdEPcfuLXJ1uw/cCyWOVGaiWy0c1JvdlThtVVX/OT1trD5Ui5qxPz/5pnoo qMUp/ziDl5YQLDgh7Caqg== X-UI-Out-Filterresults: notjunk:1;V01:K0:58TmxEtgkdc=:jr3yZ9+/VWaeau6Y6YQBBA P0FOIZZp+n1nYjbAB59ZNEcBtqHx5tFqvky8yyG8VNa/l4rIkWSXY5iCntTNH2bGw+3XXwm7r VEeTvoT+4qWo9+6FKOg/rwbb0RnA/cO81P/VRPlx3YYk8K2na/6uZfSy20eNqXdIuwJwbx+dt HvYEDqVDebaxxd0cLr9s5NCHSNmBzls2KLgYRL76iIhWfQ8j42z3ZOgbJwZGvLdtA+Jb+W6Io ij07IpbUidxQcSRzRcOUEhvWr2vHB5AvqzDMN1BQKJtaZuFpFeM5yuI4WaG/EPfvd7Od0OlvE ZnQholCmwjiV8/+CQa3wEzVGgdWZC9vHk5tkQZ22V8Iv5k5VdHa3E3XV8EaeiSqzYcB16Qy52 CboF8of+LYLslyfJC1UWNdTvk6pIww0poQGWY3/Q70nxtgDVvzOdqnDxHCgbnlN8t3LNsxalN WLh8+qMJdZBQ5cnn5q1RjMxU3iaxUqhbT9NIHUpuFiv+Y7ECmKimplGDtKznqrUPo3H91ff8C MnBvB53NR376vMvZSlMRRcq4Xt6EhapqKFIWnVb2oB/Iplz35ymOnJZa4VrSti8+xYibQ2tlW liclHefjmnBAyDcDE2qkgHV0UmjbrrNyuwh2yV77/0jKT8MR0rxS130ddPkmve/SBc6WsrAly 4FUUfVZocKklyNOyejjXqw3JA8fRvSZ/LjSFEL2KyA+3f6BNfC/eL1ox8eIysMQBnFZM8grn5 GwjkTIZq2P2hxEJJsOok2jMWcXSAUuC7x1QUa3tKxcGq85slWMrJv64j88Q= Archived-At: Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:47:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --33NG1bUkpMjkBkdnDOMi0DJv45pAtEjX0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, this is the call for adoption of OAuth 2.0 Security: OAuth Open Redirector, see https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02 Please let us know by Feb 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Note: At the IETF Yokohama we asked for generic feedback about doing security work in the OAuth working group and there was very positive feedback. However, for the adoption call we need to ask for individual documents. Hence, you need to state your view again. Ciao Hannes & Derek --33NG1bUkpMjkBkdnDOMi0DJv45pAtEjX0 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 iQEcBAEBCgAGBQJWniJgAAoJEGhJURNOOiAtjqMH+gLcldYCzYVjXo1o4xJDm/Zx t08/plm5WXfesC770wui5wWlkPPPtlyNmwTBKaAYO3Z7+wqX0qltVdwf8nHfnZ+M JEZ9+pwxvpjYVxWSSqhkXkfHgnVXU5mLfxe09QCWh1HOgR+BGi9xoKgTCzynit6F XNCKXwVt9kSxuGjCoDR39q6OBv9d5fnh4XAmdix2GK7Rpa4E0OgSG0PQXCHE/x5h hYioRAmu18XVQyL109n3SySZDQbsPfJL7RJUtZbthfK+fXnU1hh+UhMz7oHJZCHB 25CPrIguhA6/XFYIYtAzI2rNIanpqLaLhDvTbfodOiRNqH39Q5j2V5wJIIL3w5A= =vOwy -----END PGP SIGNATURE----- --33NG1bUkpMjkBkdnDOMi0DJv45pAtEjX0-- From nobody Tue Jan 19 03:48:12 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDC41B2CA9 for ; Tue, 19 Jan 2016 03:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKRyT42y_SZw for ; Tue, 19 Jan 2016 03:48:09 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E343D1B2CAA for ; Tue, 19 Jan 2016 03:48:08 -0800 (PST) Received: from [192.168.10.141] ([82.142.85.169]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MSq5p-1al6kk0Svd-00RtSJ for ; Tue, 19 Jan 2016 12:48:07 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <569E2276.5070407@gmx.net> Date: Tue, 19 Jan 2016 12:48:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FQsKXhauRHBs9Ttf9FgGVSOkCK2HHtG65" X-Provags-ID: V03:K0:Qf6Rxvx5jsBIizXqfY8lsYVWYY6MXgWN7zF8Z3WjEoxHUFadGwP e7Eik1o63CV5iPJ6mEmmSlrTvIvoAG3PJXbq+UsXYOtUoZDpz4MI8NtFGMi8b2Q2pC9/mN7 tJi9fqu6by/87TkmJJUoKUanLvP4xTZV4pwaPKfUDVhWkgeM4+U2Y9nEMFS+QJc9cY+RymJ 0CumKzNso6Ugds+UQP73w== X-UI-Out-Filterresults: notjunk:1;V01:K0:U8Oh2ermH+g=:yvNkq91TjILRp3FItq1gzj 9hV+hl9TH6kOfHBg4LAdZxC1wS3NTko3OgPixV5/jFmUdz0LV3Y2uNl3maQyhP5mGkIOztG4l ap25QJJTbIQT7qV1eP5W6jcwNCtjcuXrt9WzmjaRB80G+gB5j2pXcMZoVRxFTqjsosXUlzVs5 Ads7N4icp77MKI8+d7oQmKaoP22Js14uNC8lwGd8lpJbzeREIXwus2AX86Vot39X/uiZfIiUn zRCwYW3kxgniUQA5cYQFkQa0mL1upoCmIAn2xyTvzzGcE9hDzr3/+mhh+ThkaUKVVBNP1yLbW lhoZ8f5amp6sbPrmn16wwKti1ogzlElwXOJ60NhXsr9DG7Tho5rwa/SmxsN94RhrQDLzewgM/ B3Cdh8JZJWD0pucU84N8c+eWRcXLkQTBHe6wOpEnbXSp1Re4HCY4In2KDD5WAqKQQG2JIhu1k 28mcUKBAHDcCwQEKSpwWHOmrFLVOuPvHI06v+tsMOMoqUBlV+wiQdyDtpCxyLXCNBty1D6sxJ PPdIsK8gPdM2dFMZpF59AhYY6vmr7xNhMonLRJZ8lEu8as8SSLYHtUjXJFPFKKWREWyhUTNMR imhQM5a0voYPRnBuIhAwoaqJ/iDaneGaEM8isuIaIpOoCi6OHnc78iQTzAChf06sPn11gmuHb Y+/tH8cGhd6gD1SigAa7eSHA5YHuBXxHuOg2BPKLOq6C8h7KR1sf+bbKMqtSlw5Rw3AmwwwP1 n6ax+UU889+PPViSD5+p0ncXlAuCJ3WD/NTYVXMV5lPqDUgi9oSmlL5UKGM= Archived-At: Subject: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:48:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FQsKXhauRHBs9Ttf9FgGVSOkCK2HHtG65 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, this is the call for adoption of Authentication Method Reference Values, = see https://tools.ietf.org/html/draft-jones-oauth-amr-values-03 Please let us know by Feb 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Note: The feedback during the Yokohama meeting was inconclusive, namely 9 for / zero against / 6 persons need more information. You feedback will therefore be important to find out whether we should do this work in the OAuth working group. Ciao Hannes & Derek --FQsKXhauRHBs9Ttf9FgGVSOkCK2HHtG65 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 iQEcBAEBCgAGBQJWniJ2AAoJEGhJURNOOiAtcKQH/AzPcEtUtNpmWkhYdDvxRykj 4AgihUod/obwwasDQZTmQRQJhjNSFKQEoUpxEht3HmjI2QiMKbfr4uFZOQplgNZy HxhF6R9lCLUEi7zfOq9J3GiwxZyra1loGmkOW5jrQEEf/YgtU5BwVoFiuxh+j4uM cATGIab9DHdtuE3rmSYmrjZc1LUeVp6Mj8rjPS4qOJlSDBToKHGYskRMtvNnlOsU HZ4uOc5D5Rof7gjOLJB5KxxE9zDl+TIcES+6wkfV8iRkQGLJvukk2ktmGkWdZlAt ZmM9QOwf9VwnLuKXUCyCZuIs49d9KaC0I16/Eb+vR5j1n4+QAYfDZBAB9awfmrQ= =WQzh -----END PGP SIGNATURE----- --FQsKXhauRHBs9Ttf9FgGVSOkCK2HHtG65-- From nobody Tue Jan 19 03:48:32 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822BC1B2CAA for ; Tue, 19 Jan 2016 03:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMNHlVXBaWwp for ; Tue, 19 Jan 2016 03:48:30 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38891B2CA9 for ; Tue, 19 Jan 2016 03:48:29 -0800 (PST) Received: from [192.168.10.141] ([82.142.85.169]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LbuCq-1Zu6W00nWW-00jFZk for ; Tue, 19 Jan 2016 12:48:28 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <569E228B.1010309@gmx.net> Date: Tue, 19 Jan 2016 12:48:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TfDKn94XP8sBOm2Gdj1EmcWCeAariqm9O" X-Provags-ID: V03:K0:uueXb2Kh1f9GKqVt2Uqitc7h0Svm2gJd0dmDAM7ldC1Ckqy1ixM H4GKtMYZhEZWwYpBZLLEdMwGi8ykEbbH9/3DXW44lnQkzjAbzME4age82C9tm/SV+IbAgw/ gAujYvxaw/T2V2wLTQjkK2Gbn6hKtSnH8+Yqc6zjcXC4CfPgtdCC1Hdg0K387E/D5kovS6f LxdNU3F7Owv3okdlx9aCw== X-UI-Out-Filterresults: notjunk:1;V01:K0:LXUDU/wCtHE=:3v1MPF+v8+YMxGWKXZb38s veqQ1U5fwV/mx4p2px1TCOoTmhvgiqdX1KAMdnvyRtOPvA9zGUYx+E1FBUpfnc360RVs3qNzX BTJUJpOMCCtvDwvciYKO6+FV83A8xkcgKt6AHX2jQa+P70iMnZgqb/j9+YEkbC3BzE2UVuB16 mY7h5VyMVY5NSr+TXVtGzXafAUlBYp2ZHVnPsbFkNTnCgGafr0V4szsCM1cfP5DT3UkGmmd08 LN6PRuc2FfWX2JCYUjl6V0om71H6J7GeHgfjmL2G77mu25yY6OKSMMosGhvWGb2IcaYd54drk 4zicdgqo+7/2o9OM3h7QuazQbRSCDIzU7+5bzodABgjHoGRyZJtXeaw242MvoBFzJuD/5M2tk 7dACAG4zVhB0xMdfhqHv6HuFY8nCbFGac2ddGsISVh781Bpx/IlTk6kj8qq2zTsssjZOh0QFi VWJHpiymDZli2EQ1OeHUqfdBYVAcbWoN5gOlCB6NjTQKK9ZRs1ifDGJ1ofHmSMqhHbNJGIqv3 9ZvLuyS/qT46yTnJ9Sb4ZYZukDd7DI52C1bXhArcEogZPuuXBdlDQ4guTnXnXKTLp258PqNlo rTOZlbcHZtiSORcAYLHHa3tiAHm5D9T3lMAJkYuJDTHujmoGnyIo7jpfzzxNrzcZlZJc+Vrz8 jFcoFuRelW256JvZ3h3xPDgVNfTF8UKIOVw+ZjitDqqUm9zOXNaooxZdpAT3x+pHSRkZ6gDJq OfWs0xUvBZpE3oZXhNyHyaFQzU/iTLz2rnk/94lr3k/dxQ7qy+mqE8+//KA= Archived-At: Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Device Flow X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:48:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TfDKn94XP8sBOm2Gdj1EmcWCeAariqm9O Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, this is the call for adoption of OAuth 2.0 Device Flow, see https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00 Please let us know by Feb 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Note: If you already stated your opinion at the IETF meeting in Yokohama then you don't need to re-state your opinion, if you want. The feedback at the Yokohama IETF meeting was the following: 16 persons for doing the work / 0 persons against / 2 persons need more info Ciao Hannes & Derek --TfDKn94XP8sBOm2Gdj1EmcWCeAariqm9O 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 iQEcBAEBCgAGBQJWniKLAAoJEGhJURNOOiAtIFcH/AzpAFqYAgq89ncn7bJGCgTF aAUNT4Vkz5fDASxjNCX1oXm127THcG7YFnfbMlPCkPDj8Sdi7Bf403G6Nu6Q9coP J3u0Fc7OUyxiJx9flBrYYgif5m7hZwRVERUn0Jatc9gB3rK7BtaDR0vyaguETcF1 PSz/eAtL9479zdChtlWKROEk/+OjJ6xd3WSxjmi/yVUJxtefeM9Uw9DrUSko7emw LHOI4XUQY58MW+c+dBz/rFmdk6bntHb4dLMAy7VhyNK5ZT2nHfuUWj0L523sGO8n gbVL8pJonrdykjo0PXtlgf4bd2UdjRuRM8XtYlyOvWciT7lBv+Bomo6pOkDJnac= =m5/I -----END PGP SIGNATURE----- --TfDKn94XP8sBOm2Gdj1EmcWCeAariqm9O-- From nobody Tue Jan 19 03:48:48 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79041B2C9D for ; Tue, 19 Jan 2016 03:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zs8OBTd-Mrre for ; Tue, 19 Jan 2016 03:48:43 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0891B2CA9 for ; Tue, 19 Jan 2016 03:48:42 -0800 (PST) Received: from [192.168.10.141] ([82.142.85.169]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MHH6Z-1aPbNi09fX-00E3TX for ; Tue, 19 Jan 2016 12:48:41 +0100 From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 To: "oauth@ietf.org" Message-ID: <569E2298.3010508@gmx.net> Date: Tue, 19 Jan 2016 12:48:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jhlergb6DfgX01M4OUw4uaWMnM3kSlwKL" X-Provags-ID: V03:K0:UOK/elGt8PkVsw0b4CyqcXj8+u88nnd0xUimATSPtFo4bH15vil CvKeRIk0BFh5uyMjVb6Xc6IeiaN/eA2Zi1e0hVyq1mOzkObxUbym7FWy6Kb60iaxbGVHofN UfOGH9BKWg8ai+/08POmLIu3GGXthnKSkmqfJTTWbhCy/pwPW7WLi3nd24km866nw8cvv65 o1SV5KBoUpoFBW+m5RHCA== X-UI-Out-Filterresults: notjunk:1;V01:K0:jxQJKhxTg9Q=:yRwPRbEEnUyFS7H6Yna+C0 lUEFRJjAojtta5Mj1XOmNFn8EWKHNRyb8b6dtyZCib5Tk+1XPXJMa+b4bbvzW/QXJUblXP68U 0U/v8VMt53/1pWWMcxVnML7ejgUeCkPnx8DTUj+RTuSuTvhYqQW5CPhpk6UGuZPRFFwMRr70C FUPjfru/2x1w9Sfx2kIBngLv8fqEZcYf062ek+B1IJNMNAzvmY2xnWpFoIpb7buMzfm/JkvDm GFhOIEA/vb3M/aCtr+JenU/ws201RhUrk52sv05qQkYfx8kq3rK66OFSi4blUnqA6p+LDEyXX Qp3fJ7QoUxow9oGXvcoq0vEVOxFjl+c3lhbjE2lXfV9Ghcr0IrDlFN9pKEgOkwKlj76W5bF5c 7OfyGIgIjCQw/BW9/wxufqxtrDR4g6Kym2qhkMx3Fypk8EVcrUi3BoMGcR/Pp6C8E7FuYz9xz 1cI0LcWMKCeb7ieyGqcR6g6P7YRfexXrfbzxcol2J5/xricEhA+E74z0SjfQYROja9wcARvBo hlAHVsSshiiK4tq497617qqRqixk03horx0s0r2AT4Ar2gCNwzFhu+z1077IZ1IjVRVl4Fgjk kxkPAZsv91fHX1V8FLUv8GoAa/YPWiaEgdTNek46X3cJQonXT4sp+rGfdb9LknswSeOPkMYNM kylCqfseCfvNC1Wo8J3ZKfu5pZM6PhYSnHFEGYmCiZVrdIzmbEZ9tI9AntHs7byYIsTbVKNG6 R0gh/3FtbIfPbkTHjw4f0ERRsqZZ+OArIsTMtZqx7+soWYr7O9Pmw6DPkKY= Archived-At: Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:48:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jhlergb6DfgX01M4OUw4uaWMnM3kSlwKL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, this is the call for adoption of OAuth 2.0 Discovery, see https://tools.ietf.org/html/draft-jones-oauth-discovery-00 Please let us know by Feb 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Note: If you already stated your opinion at the IETF meeting in Yokohama then you don't need to re-state your opinion, if you want. The feedback at the Yokohama IETF meeting was the following: 19 for / zero against / 4 persons need more information. Ciao Hannes & Derek --jhlergb6DfgX01M4OUw4uaWMnM3kSlwKL 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 iQEcBAEBCgAGBQJWniKYAAoJEGhJURNOOiAtcA4H/15hsJtWcb19DyJgJBZV45Nw z++RnULFqESG72xC3quT4TOlD51OxlyLE5B5PNUIpjou0KBfMw1ncYbwG9KGT8OL V3dzt0qzse+XvMtjvCIoreEaoXqiDQv+sJ1Yx3bkD0gJqS5h5Y8R12HddjsYtHLi /0XkN9mvC0jkAdg+F2OwzckxVTeL3qv+HUUOkmVBBaaEtyi39VxN2i+XpVDvwcy4 W1kuNT7omqCIoEyBCmWQ1NbpP0G8is0VSIloPAXWaKeETFCPlQTR9NOSPLS7+gOg nsdmqukTrbD9V7RW/QunyFzKaGLxczAXQPzb4IWizQCmc0LcJDUOzfnzL2lhWMk= =mlu9 -----END PGP SIGNATURE----- --jhlergb6DfgX01M4OUw4uaWMnM3kSlwKL-- From nobody Tue Jan 19 03:49:59 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AA51B2C7C for ; Tue, 19 Jan 2016 03:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trjYx8lEZU4q for ; Tue, 19 Jan 2016 03:49:57 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B2B51B2C78 for ; Tue, 19 Jan 2016 03:49:56 -0800 (PST) Received: from [192.168.10.141] ([82.142.85.169]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MQ2Wx-1aGpxx3YNH-005IAz for ; Tue, 19 Jan 2016 12:49:54 +0100 From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 To: "oauth@ietf.org" Message-ID: <569E22E1.5010402@gmx.net> Date: Tue, 19 Jan 2016 12:49:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="A46MXO0oN94BcaJJS7JirBrFThhQ6onON" X-Provags-ID: V03:K0:QoWFcDdpn36R/lriqL77yMSQfVL8CtI5jzJltWQXT4aiqM/b6Lj OysrRph2VdEH1ebhZwpAs/uSKNF+HAzxY806hy941XeKjJ9HNHhfxjkkh5LaiTDSOLYoO2e NATwqMlkdjQoc5VM3+JWgaglSSR+/w0Hz9NIee1GlhpptNsq8A24RBG2AZqCgmIYXhmj4DN l1vNj1vHQA3zHykBMmmTw== X-UI-Out-Filterresults: notjunk:1;V01:K0:7JoLwzR0/To=:e4MNORRhVE4ZVkDHsYgEK0 v9S1bcriaEO35nsIC69sVoksFpncjzrgkQr0J+NpE4L0E70o+7VP/HnTeq6yEz1onsLuJqLlN 8QsDtkuXrDLxfYoJ/eQbDTH2n2+5oIb7yy60ovr4akQhtbkUHE+cpcWi/llf2OwixsG8mGZt2 6aO+sBJarjMo7fyuKOXaqxz2PZkeElUepkidDTf0EVMynqQD7A5RBxTEbp66WETIkpSxQmqp7 yv7x9jXA4aPrEP+AEzdWoSFHwBC4mUAGETcx9eLrc+eKORM/de2bH3HR0GVjty7zdyn3Bn+yt 0WnZjI7lUA3JdWc0a7LRelkwfcTr2SpFjv/6WbDga7h6aOavd3MF9Y2gWy5ogOp/Um1owzTu0 Ik+4yv6dNJmTVHygJIAZwdr2erebbe8sRtFleneTCNnx0Fzl4vWx5dX4K3xiaiCHc/UlSMc4v Qq0uOtuyqYR+KdaAK7mBlkeTyiq5QWSHNvjkmaXDkWeDs9BWnaj3FCmtKBz4mK6IbJ0Cn4XyJ Lb8HTtwph6gR3q/nnI03CREI4L2qKD68R/YO/cG3MbGWbTIJkcPLEMsvGG8tG/Swcp8GRe1qe 553Le/esXaZ21uFwTY2mYQ/dGjItPWV0L1azAabuoXubJF32nnv2LHIsYsvHqTeg1ZF6/aUJa 7Y7fXeUk2SKOdDBjoa1KTr0UDI/y4/HSF8XlNMjJnPk2RIk3ZPxfWn7Gck2yLvNsPX/bioP43 DUPbK3DbpmCwD5cmQR0hdcf5WzluDCX+XE4LvekMoCpnIuGyfzG3r3wHp1o= Archived-At: Subject: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:49:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A46MXO0oN94BcaJJS7JirBrFThhQ6onON Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 Please let us know by Feb 9th whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Note: This call is related to the announcement made on the list earlier this month, see http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More time for analysis is provided due to the complexity of the topic. Ciao Hannes & Derek --A46MXO0oN94BcaJJS7JirBrFThhQ6onON 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 iQEcBAEBCgAGBQJWniLhAAoJEGhJURNOOiAtnogIAJfIg8pczjenCBzZ/ZbvOJvU mD+hjwTb+p2ZAZtfMm4lgmE8E715MHVeBkt61RuDcT/KHEVXx9RmXvdgvmsYXw9s t+/yaRLcsuhxTqfZokkMegYf0fNNan4yQg5/xdv7BV7BvQgKHe+rwd8DJp0+3yaX bDtCN7UZPgF3WJFupPctkjMsy+QV3RTYKvXKci3xKcEFnHbkzm8kuUvTkKIXlZCO enJma9MiIj+Ge1D1IdaXMSoAVGCWBg+mhT5/E7EEJ09+xP+78TTa1laXKnkt9T9L fW5GL18u9FUVSnPq0cxICG/BEIvki3W1/qgJCvmombkCmHgv80KXjQzXw1g9FZU= =EITY -----END PGP SIGNATURE----- --A46MXO0oN94BcaJJS7JirBrFThhQ6onON-- From nobody Tue Jan 19 03:50:14 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7AE1B2C78 for ; Tue, 19 Jan 2016 03:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8AaAf8u61-Q for ; Tue, 19 Jan 2016 03:50:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D43D1B2CA9 for ; Tue, 19 Jan 2016 03:50:09 -0800 (PST) Received: from [192.168.10.141] ([82.142.85.169]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M82zV-1Zzznd1BB3-00vgOb for ; Tue, 19 Jan 2016 12:50:08 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <569E22EF.70304@gmx.net> Date: Tue, 19 Jan 2016 12:50:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BSf4Rg87XNqHgen8JOrgEQ0GQ3EW7kAuH" X-Provags-ID: V03:K0:XK6sEtZR3ljJ5HQr4iGrFw7EZC6A02kbMnHd3/LbgIMr8whe/E6 19ku1SHPsYvbIZDXbjdJXZ0wcR3SI68CSb4h35liy78nEgUyFGoxgGAZRqbkq+iusOpQRIG +pl4Ie8f9n5wFzDvRYadEdxAs7aY06Lwyxg53pEX3Jt6COafhDo+WlqLY6hhkCfiT2qJeV3 8VOlVgROQ4UBWIP0eAbfg== X-UI-Out-Filterresults: notjunk:1;V01:K0:VlTRU9pNsNQ=:HORYARfugohp5zxJ8Xu4QE Wtmf5POUAZZeWTBXN8wZoqLXnLD+ZhaluNZkase+6Z9xHLFCaxApVMjws1j6iBDJLX+G1VEzz tbyGz9tLGBCLDb8aitr1p9u7h8OfMqdqUVfc/utmjfHyOUm2Lk+h+H13QUFgRP48tme87WTGE jESPomQRF37t2qouGJl6fckK8qReTCUy0KSQ6VQYNctk3MamjyodCoxGfoPAiDrhBk9fINgfl r0d0Zsm4FC4uvDT7OymHAk63egLWlMz0Pq0BtkLPAYDWr53BDA2s0cyVLGQSiFmS1GybwBdbu VPfQwubv+Q5hbRlDYBz5CXZl8gPhmZXRWkPtu6XRWcrEvp+AkiYAPu9WeL+RXbLbQyiPtN9ZU YOHqoczLpcC2Pp68orFJK+c4SaBIPUkTR2eO3ERgaKXHGnX1gd7ySfjBtyZ/GbyPqLZr2qPO4 xXiBY5FVjKLilcC7x+3eu9fdpXeqCenYBTeHcft8DeWP0hzfTO+AZV6D0D60ztQh+IAkiBHCB I6VhrgzOMPuO1Txx9bPh0N9ZjKx9U/WfRWlKyDqhLnh/vGtmHwRdRUCtwgLZPF0lnEYMJNA0C 0mp4kPisX8W+e93xYP9FS+ZacmKzRcyNbtuqyHVSmmWHirSsCOS6RS3Q5+MTuu3eD4ZO8rGz2 jD7w1gJRl+svPVZjyxagJuhfLtEJL3fSi3Z1/swocL2uhsJJdnhZWFLK7gYnsX5sHWOIgdF2c Eehu+Bevxd8HJAHwlM94zqJL1h7Pim53llkujcUE2+grmJhkDjULBBlw3Sk= Archived-At: Subject: [OAUTH-WG] Call for Adoption: Encoding claims in the OAuth 2 state parameter using a JWT X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 11:50:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BSf4Rg87XNqHgen8JOrgEQ0GQ3EW7kAuH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, this is the call for adoption of Encoding claims in the OAuth 2 state parameter using a JWT, see https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state-05 Please let us know by Feb 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Ciao Hannes & Derek --BSf4Rg87XNqHgen8JOrgEQ0GQ3EW7kAuH 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 iQEcBAEBCgAGBQJWniLvAAoJEGhJURNOOiAtFywIAILjSf0fes4ik6v4XteA+sCS IjXI18F8p8Zo/MAfawUMctALTg23odBUm0rCwl3gIF1mFhk3gyMlc7qIkYByUa7f w1BudmvYjEI+imn+onLJXxlYBhWcPORCBMVcN6MO5qHHPvqt0mPHSQUEX8z8bznf yDYNLHI7clvXESDbEJtMACD0oF9xbAKO/aSvXIav7NkRwSe5ygrpX5Is6bJ4AbkG qqStuEaJ4BarjSjkjh7Rj/fIri2pXUQ9k3bQVK268FpsR8yXQnx82up1BkYnnWnJ MYaAJFSoGxi5S6N0xvIIUULYfE1FFPGz/xWZUE2f9gvB4aroLoWs1lEaJ/nuIVU= =a4ud -----END PGP SIGNATURE----- --BSf4Rg87XNqHgen8JOrgEQ0GQ3EW7kAuH-- From nobody Tue Jan 19 04:04:51 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AEA1B2D04 for ; Tue, 19 Jan 2016 04:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIAAeEBZWcc9 for ; Tue, 19 Jan 2016 04:04:48 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37CC91B2D02 for ; Tue, 19 Jan 2016 04:04:48 -0800 (PST) Received: from [192.168.10.141] ([82.142.85.169]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M7Yhz-1ZyLOr1zKJ-00xKIp for ; Tue, 19 Jan 2016 13:04:46 +0100 To: "oauth@ietf.org" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <569E265D.2080703@gmx.net> Date: Tue, 19 Jan 2016 13:04:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NpTVna9SDUSWtll0sK1uhB9rwi7lAFjWe" X-Provags-ID: V03:K0:gsq5oI216dBnoxM6X0Xo6tArb0qyOGJaxApAmzFwpXxFmuhAJOL L+HOvnqr0oGwVri5zuY2ptqW7jNadQIygPxY66ZowSHUf2mmkJd3Os1kNQzeg0ebgIY/YYL n5Gl44a/rk/2E/dv5VJNseJ+gBJQlJnwm4ALRByaNuqDbi3TyhaLPa2yOK0DZmR9vpGQgTv wti3/YD+9njJJ9MfjHkKw== X-UI-Out-Filterresults: notjunk:1;V01:K0:CMXzHccpZUI=:Imbh0u3yHhrzSOpXeQNQ57 oglBhAb4zGcmxNPqy2bGiibxKddvM1F/D4sawUcpim2zOETqrrTfqEiS/oLjDDBeAmVcVAp0v nnjzeJU3gr/4A8n7ZjebcRzMps9SlxUl3nk1mNSZ9akl0ghJfXP1FYOJjFe9zEZVxRfYArFId B7oe+NBLn/1pX+q/UoIQ6xowj87p1+ZjlfJ3YYKV/ewyVp4thdVquP8OUKOhHJth4pHoLSIpD jtuLt32vzcZy45abyn2UpV2wO18lRRuNfBNj4e4JrGljqMXMFVATUsH7A1mLDoiA0AMca/2Xb JfVesWmjGOKWpQgpRiP3zq+3U+3Qm+mbUJQPmL/qY0cuLxy1MUVdTVf4bVGLF96g6jdCxHBgD LB8TVdJHDMFuUiAjFLnPvw9jQNiYTfpfai4K9uJ0jdoMkJl4D5y+ytZqsDs81wAK1ztj62FXj e2ooMvj//9eYJU3tA28QQ8Y5UNPHG/gJh+JOiQcABe8F6sT11cGDfTGtAwQcIJj2H/6jfFgxp jZM1EEZkV7jykpMM3gmmNMd+ZO/mHmY8yyn5G36yi7OPov1JJuXPHiyfyy1P+Zfl4BHGUIFtl DZF8/5TeoH1+ifAmvHOrW71UpxsbOBxrv+xTwI/aBeiBHHwZPibB0cY53lrM7JXmml+E6KAm1 il7fnsRaSclhDk76Xo5OK/QWLN83RZ7RS9n7HpeXyuk473BEXf4+jiy5E2HJ7p6oLN4LPc5pl JV55sEzecudQU/Yh/1kwIXTkPgG01AK7c0kzbv8d5Xs7TRYpF3JWU2J0sFQ= Archived-At: Subject: [OAUTH-WG] Call for Adoption: Stateless Client Identifier for OAuth 2 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 12:04:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NpTVna9SDUSWtll0sK1uhB9rwi7lAFjWe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, this is the call for adoption of Stateless Client Identifier for OAuth 2, see https://tools.ietf.org/html/draft-bradley-oauth-stateless-client-id-02 Please let us know by Feb 2nd whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Ciao Hannes & Derek --NpTVna9SDUSWtll0sK1uhB9rwi7lAFjWe 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 iQEcBAEBCgAGBQJWniZdAAoJEGhJURNOOiAtlQAH/iTmK9vruIew1oPNZdFPdrtL e5LXRsHIg4Sd3vTb+NSTb7/kdVcAkzYvoBYPFH3dLdAMX6XmdKID4hyY8/atBv/1 2yEHbX2Zm5o29wzmRHEBPlkqqPzTvimhsc7mjs7BnSVcZWqwtNbA69uD63awvGWs gexMy2k0rVdBxC6hC1GZ59mntH9I2qtvKvxzbo9zq/hR5953sTou6Yx6enxM5qCG Y5iQFGbKlqRYzzQGG3mWF5kegwseb9OSRqvY4xNViq3uHope4sdD9gEzVAaTezbP uoFo4JMMr9rWwZrz/fIVXBHfes6DQH/eM/gTWJHqDrHnCgadYeRuEeu2AkOoAas= =HaIa -----END PGP SIGNATURE----- --NpTVna9SDUSWtll0sK1uhB9rwi7lAFjWe-- From nobody Tue Jan 19 04:25:29 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 3DD0F1B2CC4; Tue, 19 Jan 2016 04:25:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160119122526.422.54934.idtracker@ietfa.amsl.com> Date: Tue, 19 Jan 2016 04:25:26 -0800 Archived-At: Cc: oauth-chairs@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Stephen Farrell's Yes on charter-ietf-oauth-04-00: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 12:25:26 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-oauth-04-00: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-oauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- FWIW, I was at the Yokohama OAuth meeting where this was discussed, and there was fairly clear consensus in the room to do this work and people willing to do it. I'm not sure if this really needs external review. I'd be fine if we just did it, but haven't checked if there's some reason to want to shoot it out to new-work. From nobody Tue Jan 19 04:33:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93AB1B2D77 for ; Tue, 19 Jan 2016 04:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQ6bc7XNcanQ for ; Tue, 19 Jan 2016 04:33:04 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::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 74C061B2D76 for ; Tue, 19 Jan 2016 04:33:04 -0800 (PST) Received: by mail-qg0-x22c.google.com with SMTP id b35so447519691qge.0 for ; Tue, 19 Jan 2016 04:33:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ZLFQIqwl8TT+JBrWyuhfInWCnPEdofW2O89zQ2eNFVo=; b=FVjuvUgv3Xm8BxVLj+PlG/PrDZHjY1i6XRmRzF5xqSWkrCP7RzSqSv2t2lhtD9Jp86 rRwCIK+laXcCtC1c5ElFQM1uXtCmT/vIY/tt/AYyFbA865Aso0/vFWddXtXp4CKKpLS3 nTUlIZCTpw2GiZDSiw679MsRykMmLGaIg5M8LrEfdfrTHb1SRBzyAb+wB4s5i4iUO7sI GTZugqq6rN0oi54j6a/2S4fayVYomqSxj2cCHjkHBQWdJnPRwQsrghPMTORoafSnGrhO npE2fQ2Fvz4QGeu/qm/453RIyx+3tuAG3iCQdXef+/fl3n3pDlZrZjFtzFM+DDkOLDyh y7mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ZLFQIqwl8TT+JBrWyuhfInWCnPEdofW2O89zQ2eNFVo=; b=S566YogeIFSSlEgLtWR6OewpuwXdLjr1H50NFVmzzviIFKRJtDjZbZyNNH8wwcxHWF EInfIdMlzIlOIptMSOfd4VnFz3/rQgGDJBDYW7fhoRKM1Z/0MJdvaOGpKMW6Ho2FNyl+ Mn7THhOKzs6jeaM7ZrRxHsY3XiUECZu4WRihRPNjYTFNG4CQNSf4s19MNw3OHpzgi8EG GpTV/dr/U+vW7StokfvsY/rpkX0jt5EQAQUH2PMIElaDFsKjkzdWpLHiVgQ3Hw7x8B6X pMZhCKvUmA9UnYqVY9IN7tVbec8S4tsc0c8scgar4GnrWE2VyywqDtGttV67CFUbeNaU 1QwQ== X-Gm-Message-State: ALoCoQlHy9gjcRxXx1eVBVQJ2U+++HF62I95KbgyYDVtkoASA1kG/Xnlb8/Jy+mcy+m1nUz4TTFw0GWnfNJKQsZB18D8rYGWtw== X-Received: by 10.140.158.4 with SMTP id e4mr39669437qhe.81.1453206783377; Tue, 19 Jan 2016 04:33:03 -0800 (PST) Received: from [192.168.1.37] ([191.115.68.227]) by smtp.gmail.com with ESMTPSA id 138sm11970647qho.48.2016.01.19.04.33.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Jan 2016 04:33:02 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_25B7AEDF-82C7-453A-AE42-596570A2C579"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Tue, 19 Jan 2016 09:32:41 -0300 Message-Id: <8E6EBF44-2057-4429-8347-1BA447C3F3DB@ve7jtb.com> References: To: William Denniss X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 12:33:07 -0000 --Apple-Mail=_25B7AEDF-82C7-453A-AE42-596570A2C579 Content-Type: multipart/alternative; boundary="Apple-Mail=_2598B616-E0E3-4E89-86E2-734AEE376491" --Apple-Mail=_2598B616-E0E3-4E89-86E2-734AEE376491 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Great news. If you have sent a PKCE challenge and no verifier that should be a = authentication failure as if the value were wrong. I don=E2=80=99t know if it needs a special error. Thanks for bringing it up. John B. > On Jan 19, 2016, at 2:46 AM, William Denniss = wrote: >=20 > This month we rolled out full PKCE (RFC7636) support on our OAuth = endpoints. >=20 > We'd previously implemented an earlier draft but were not conformant = to the final spec when it was published =E2=80=93 now we are. Both = "plain" and "S256" transforms are supported. As always, get the latest = endpoints from our discovery document: = https://accounts.google.com/.well-known/openid-configuration = >=20 > If you give it a spin, let me know how you go! The team monitors the = Stack Overflow google-oauth = tag too, for = any implementation questions. >=20 > I'm keen to know what we should be putting in our discovery doc to = declare PKCE support (see the thread "Advertise PKCE support in OAuth = 2.0 Discovery"), hope we can agree on that soon. >=20 > One implementation detail not covered in the spec: we error if you = send code_verifier to the token endpoint when exchanging a code that was = issued without a code_challenge being present. The assumption being that = if you are sending code_verifier on the token exchange, you are using = PKCE and should have sent code_challenge on the authorization request, = so something is amiss. >=20 > William >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_2598B616-E0E3-4E89-86E2-734AEE376491 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Great news.

If you have sent a PKCE challenge and no verifier that should = be a authentication failure as if the value were wrong.

I don=E2=80=99t know if = it needs a special error.

Thanks for bringing it up.

John B.

On = Jan 19, 2016, at 2:46 AM, William Denniss <wdenniss@google.com>= wrote:

This month we rolled out full PKCE (RFC7636) support on our = OAuth endpoints.

We'd previously implemented an earlier draft but were not = conformant to the final spec when it was published =E2=80=93 now we are. = Both "plain" and "S256" transforms are supported. As always, get the = latest endpoints from our discovery document: https://accounts.google.com/.well-known/openid-configuration

If you give = it a spin, let me know how you go! The team monitors the Stack = Overflow google-oauth tag too, for any = implementation questions.

I'm = keen to know what we should be putting in our discovery doc to declare = PKCE support (see the thread "Advertise PKCE support in OAuth 2.0 = Discovery"), hope we can agree on that soon.

One implementation detail not covered = in the spec: we error if you send code_verifier to the token = endpoint when exchanging a code that was issued without a code_challenge = being present. The assumption being that if you are sending = code_verifier on the token exchange, you are using PKCE and should have = sent code_challenge on the authorization request, so something is = amiss.

William




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

= --Apple-Mail=_2598B616-E0E3-4E89-86E2-734AEE376491-- --Apple-Mail=_25B7AEDF-82C7-453A-AE42-596570A2C579 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMTkxMjMyNDFaMCMGCSqGSIb3DQEJBDEWBBSs8KMrUnNen9O9gH1SUZ3e /6NHIzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQAiojcWf4cRhQ0qP8lBhgAfhWMzu+NrtGqQJeBcHtDzABEi6lkQvQX9 19Q59uY56a+vsEOmqOH0wtKK4t4wHRQiU5s/8RWDi9YpYRO00miikVUO02x/lLSvJciQIMIKEHQW LJcYmjGdBA9MMrJZGnFMj85zTjt2TGTyfU+b0//VQUUopPk1LcNzOFjU1QKezueZLx5hSrzQqOZw 9C7PzINQHtdKpGv0i3P9n8JFW/cOhsn2H0dp8DCjcI/W43S+RLWYKtJgQIVGRat/dZnmbq7wz0O2 i00+FYi1b6uBy2BfHcUlMBZsugt1ATZS52QJol5WwMYDgkLoq4nswC5QnCpyAAAAAAAA --Apple-Mail=_25B7AEDF-82C7-453A-AE42-596570A2C579-- From nobody Tue Jan 19 06:32:07 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6054D1B2F96 for ; Tue, 19 Jan 2016 06:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lvomG8IytuT for ; Tue, 19 Jan 2016 06:32:02 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::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 21C4E1B2F92 for ; Tue, 19 Jan 2016 06:32:02 -0800 (PST) Received: by mail-qg0-x22c.google.com with SMTP id e32so492928757qgf.3 for ; Tue, 19 Jan 2016 06:32:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=1kbjsoo3E8BHGep/zwh8Zr6fQOuSaylPookVQc/izV4=; b=Fv0/1CaVOkhf3qt2Pe6e+a4eAITE+POOhNEE1/yiWRWkpqi9SkKcmAJP1eWknMCaKG s3OqFbGe5H+l4y7Hc8HtzEKAIFqeT6u/uUwbACScm3mo3XV43J0QVwZ65z5A+CJ7SH0Q HGLUAhrLDBpEZ+hDut2yT++O7j4IjaYDYE+fAukuEm6WbqgH4xrkDj1nyp6NZGFyHmej 3VFMTNphUBn2NFgfXUQ2v+HPARu24bKT2tOlqeO7zqQkAqGTNYFS3/1g+IyKXMzWec9V WVnWvWibkx+boSrQGxfebyj6eIIoZRU0JiGb7T+CNiCWffUHC3+fBpcG5P7AdOQ6gBJ5 LOIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=1kbjsoo3E8BHGep/zwh8Zr6fQOuSaylPookVQc/izV4=; b=B96nUVvPAOrAGsH4EfNtc9YHoCaTa4pVy7ngv1Uq78JUmgWrEgkgVq8WuC2FFv4ib6 Ko/SQXhLzA7MZVNDptGB77bbnv3SaqOghqEyj0uWcRkOHbz9+PNSVnYIM+Gy7jrkZcQa hCrEIlFSqmtMckLOYkdl8HgXoRq/MiljTmd2vFLIUdUGuGeVB8KA1vGjw0CWjphL6nQi yBK7V/969jKguTa51JxVplG64REK7sike5dPtPoJgumvqv8ReXKlOY6oHKMDOWEq9Udi LIHmxiCxd9HOjSNiVFuhb1tsPzaPy2NrTms9Jg9tV3SFJepDCImSU3Sh9/DWvuzARakU 8AEg== X-Gm-Message-State: ALoCoQlc+ikv2jgRHFWAS1xTs4YN4v2NJw84IV4LpjydQOfW108tuqhhuCymL7EQ8TRwKytPWbkym6gU6f5WBgJLs+Oz5157KQ== X-Received: by 10.140.158.4 with SMTP id e4mr40494445qhe.81.1453213921198; Tue, 19 Jan 2016 06:32:01 -0800 (PST) MIME-Version: 1.0 References: <8E6EBF44-2057-4429-8347-1BA447C3F3DB@ve7jtb.com> In-Reply-To: <8E6EBF44-2057-4429-8347-1BA447C3F3DB@ve7jtb.com> From: Nat Sakimura Date: Tue, 19 Jan 2016 14:31:51 +0000 Message-ID: To: John Bradley , William Denniss Content-Type: multipart/alternative; boundary=001a113a09de8e49ea0529b0bbf2 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 14:32:04 -0000 --001a113a09de8e49ea0529b0bbf2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed. It should give out an error. It might have been easier for the developers to get a special error so that they can debug, but giving less information in general is better security-wise, so... Nat 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 21:33 John Bradley : > Great news. > > If you have sent a PKCE challenge and no verifier that should be a > authentication failure as if the value were wrong. > > I don=E2=80=99t know if it needs a special error. > > Thanks for bringing it up. > > John B. > > On Jan 19, 2016, at 2:46 AM, William Denniss wrote: > > This month we rolled out full PKCE (RFC7636) support on our OAuth > endpoints. > > We'd previously implemented an earlier draft but were not conformant to > the final spec when it was published =E2=80=93 now we are. Both "plain" a= nd "S256" > transforms are supported. As always, get the latest endpoints from our > discovery document: > https://accounts.google.com/.well-known/openid-configuration > > If you give it a spin, let me know how you go! The team monitors the Stac= k > Overflow google-oauth > tag too, for any > implementation questions. > > I'm keen to know what we should be putting in our discovery doc to declar= e > PKCE support (see the thread "Advertise PKCE support in OAuth 2.0 > Discovery"), hope we can agree on that soon. > > One implementation detail not covered in the spec: we error if you > send code_verifier to the token endpoint when exchanging a code that was > issued without a code_challenge being present. The assumption being that = if > you are sending code_verifier on the token exchange, you are using PKCE a= nd > should have sent code_challenge on the authorization request, so somethin= g > is amiss. > > William > > > > > _______________________________________________ > 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 > --001a113a09de8e49ea0529b0bbf2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed. It should give out an error.=C2=A0
It might ha= ve been easier for the developers to get a special error so that they can d= ebug, but giving less information in general is better security-wise, so...= =C2=A0

Nat

2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 21:33 Joh= n Bradley <ve7jtb@ve7jtb.com>= ;:
Great news.

If you have sent a PKCE challenge and no= verifier that should be a authentication failure as if the value were wron= g.

I don=E2=80=99t know if it needs a special erro= r.

Thanks for bringing it up.

=
John B.

<= blockquote type=3D"cite">
On Jan 19, 2016, at 2:46 AM, William Denniss = <wdenniss@googl= e.com> wrote:

This month we rolled out full PKCE = (RFC7636) support on our OAuth endpoints.

We'd= previously implemented an earlier draft but were not conformant to the fin= al spec when it was published =E2=80=93 now we are. Both "plain" = and "S256" transforms are supported. As always, get the latest en= dpoints from our discovery document:=C2=A0https://accounts.= google.com/.well-known/openid-configuration

If= you give it a spin, let me know how you go! The team monitors the Stack Ov= erflow=C2=A0google-oauth=C2=A0tag=C2=A0too, for any implement= ation questions.

I'm keen to know what we should be= putting in our discovery doc to declare PKCE support (see the thread "= ;Advertise PKCE support in OAuth 2.0 Discovery"), hope we can agree on= that soon.

One implementation detail not covered in the= spec: we error if you send=C2=A0code_verifier=C2=A0to the token endpoint w= hen exchanging a code that was issued without a code_challenge being presen= t. The assumption being that if you are sending code_verifier on the token = exchange, you are using PKCE and should have sent code_challenge on the aut= horization request, so something is amiss.

William=




_______________________________________________
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
--001a113a09de8e49ea0529b0bbf2-- From nobody Tue Jan 19 06:40:14 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211F51B2F53 for ; Tue, 19 Jan 2016 06:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5qNbqd-x_nU for ; Tue, 19 Jan 2016 06:40:11 -0800 (PST) Received: from mail-oi0-x261.google.com (mail-oi0-x261.google.com [IPv6:2607:f8b0:4003:c06::261]) (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 5E3BE1B2F66 for ; Tue, 19 Jan 2016 06:40:11 -0800 (PST) Received: by mail-oi0-x261.google.com with SMTP id j3so19004051oig.2 for ; Tue, 19 Jan 2016 06:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verisign-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:content-transfer-encoding:mime-version; bh=p8uWrjOpHmr4VKzTMdPssxpbgytA6mV3JZlOB/JwwKI=; b=fe/Mfb29HK1HfAhMg5J/uDhlA5SiBGne0qMROgdU6TjeYGA/Em9B00tpZ1JrG7O/6G ZeX8PSgFigadwfICR7s5onulVc1yqytFE8o1kf0xTJkhnaL04Vmjut03C8S1VCfjGp99 JSH35gVMeNo52ZFdYKnnYtF/o4kwXHaTO1oavDESz5YAfRtrltV4STV6AaXH+DpshSOZ Rm3ZkTjkNNufIA3YwCqHhxYQqcbVaCGEAkZZvnFO8Wy/0AMUCfq42/pIoOkopWcdZTCp fOgeG/30lQJLtZxxYn/4vH95G3S0m83sfT0stWoWapq5YqXLdjgIJlx8+Ndm0+UTcilW et5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:accept-language:content-language :content-type:content-transfer-encoding:mime-version; bh=p8uWrjOpHmr4VKzTMdPssxpbgytA6mV3JZlOB/JwwKI=; b=BzVRnyR4vFDKEbjUr9f3DQO/ko2SmWzPnArE7AZJ8vqkSgmEWaaj3wPWBKKJbUCdIL qNFBZFsMAlIYPgjEHl5LYMkLSabT0kEDoxIgg0aJPMmhLTMdtJOYLQqE/bQbK3dbij/a N3Cg3bx6Hbo9wvbhO/rly3mDox44ciyniiIk/p0fq1JtNoRLhn4w/X/xPdhTao1/65f9 ghfTe9K96qLs8gByLJPHmFeYxoF5hf/RXoHhgHzDPO32LGV9o4LBfv7TjrWLxiXxtMhn H9Uu1enTLIHwLpvWxGJgxKoNeOthwKTEE3OaM1Z7dCsDDve9z0/tliRogqiCTso7nvNf 0hwg== X-Gm-Message-State: ALoCoQmyGKfCH5rLXy9eILD9smnvNsVlM2DU+lPA4x5S/Drq6TVXu2IlF8Z2Ju1us1A77s+v+ABme5w17kUihjMj0UuGXpJP3yJy5kgWfLsQ0txJU5VJ8hA= X-Received: by 10.140.154.206 with SMTP id a197mr40672724qha.100.1453214410434; Tue, 19 Jan 2016 06:40:10 -0800 (PST) Received: from brn1lxmailout02.verisign.com (brn1lxmailout02.verisign.com. [72.13.63.42]) by smtp-relay.gmail.com with ESMTPS id u191sm4209405qka.2.2016.01.19.06.40.10 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 19 Jan 2016 06:40:10 -0800 (PST) X-Relaying-Domain: verisign.com Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout02.verisign.com (8.13.8/8.13.8) with ESMTP id u0JEeA1G026643 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Jan 2016 09:40:10 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Tue, 19 Jan 2016 09:40:09 -0500 From: "Hollenbeck, Scott" To: "'OAuth@ietf.org'" Thread-Topic: Cross-Area Review Request for RDAP Authentication Thread-Index: AdFMdFIjlomRE03AR0yFxWcnxij5bwGUrPpQ Date: Tue, 19 Jan 2016 14:40:08 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4A130B17@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F4A129732@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A129732@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Cross-Area Review Request for RDAP Authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 14:40:13 -0000 > -----Original Message----- > From: Hollenbeck, Scott > Sent: Monday, January 11, 2016 8:31 AM > To: OAuth@ietf.org > Subject: Cross-Area Review Request for RDAP Authentication >=20 > I'd like to ask folks who are more familiar with OAuth than I am to > please review an I-D I've written that describes an approach to using > OpenID Connect with the Registration Data Access Protocol (RDAP, a > product of the WEIRDS WG). Those of you who are familiar with WHOIS > will understand the motivation behind the development of RDAP and the > benefits of being able to authenticate clients. >=20 > The I-D can be found here: >=20 > https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/ >=20 > Note that RDAP does not depend on clients using web browsers. I have > some text in the document that describes how to use OpenID Connect with > non-browser clients and I'd like to ensure that it all makes sense. Can anyone help with this? Scott From nobody Tue Jan 19 07:19:13 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EEE1B304D for ; Tue, 19 Jan 2016 07:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, KHOP_DYNAMIC=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc68m48IQ-ak for ; Tue, 19 Jan 2016 07:19:08 -0800 (PST) Received: from mx0a-0019e102.pphosted.com (mx0a-0019e102.pphosted.com [67.231.149.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4EE51B304B for ; Tue, 19 Jan 2016 07:19:08 -0800 (PST) Received: from pps.filterd (m0074413.ppops.net [127.0.0.1]) by mx0a-0019e102.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u0JFEGwK001363 for ; Tue, 19 Jan 2016 09:19:08 -0600 Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) by mx0a-0019e102.pphosted.com with ESMTP id 20hf1ah1cv-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 19 Jan 2016 09:19:08 -0600 Received: by mail-yk0-f171.google.com with SMTP id v14so557467470ykd.3 for ; Tue, 19 Jan 2016 07:19:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=Wu1S1Te4BsvRT8MKPwVTA8mgU5/yD0dSChfaKQTPoY0=; b=GzEGBVSRmF+v5xq86/PKoJ0H+D+sjVEebj+hw53RhPK0tbaT+3bG8H/JC43FFn5smd v+0do/d1HSsG0NJRVD7nc1J0n3ebDUG6HcDtWKRUuWNoYJxScKbcKH4Ajqzp4nJEdIi/ jjRa+TScn7kTyExtk/i6C0Unn0ig4zaHk/Oy5t2nf4ucwpFjmW0f4lksThJ2Mazb6SMA mL6jIWw4Uki4eCXD1+omY25RfXA/EcyJFmUDr19/drkLZ76E09kvcqmzdt4FrR7snDWO 0CnQAnN6PkjwBhggpa3PZatb4VjaGSaBnnsBIgHU4UD01Io9eZAEHUPxlVZgF/717yaR tkGQ== X-Gm-Message-State: ALoCoQlHwWzoLBtjttev7mDtk7oGaiBlrOcpZgP0NkNi+h7eiqKxTx1yri76WEzxb1ya0pKSZLaMwvn3saSI6n6hE+ccPt+mLhXW17LroAaz7ftvpPgiNeBRqcU0YmYAxgDXa+EQSAfAqY0PzADv5TxFMKagXTeLMQ== X-Received: by 10.37.89.135 with SMTP id n129mr8183783ybb.102.1453216747178; Tue, 19 Jan 2016 07:19:07 -0800 (PST) X-Received: by 10.37.89.135 with SMTP id n129mr8183778ybb.102.1453216747052; Tue, 19 Jan 2016 07:19:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.196.6 with HTTP; Tue, 19 Jan 2016 07:18:47 -0800 (PST) From: Adam Lewis Date: Tue, 19 Jan 2016 09:18:47 -0600 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary=001a1140fd5afd91fd0529b163a6 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310008 definitions=main-1601190263 Archived-At: Subject: [OAUTH-WG] best practice for Native app + state param? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 15:19:09 -0000 --001a1140fd5afd91fd0529b163a6 Content-Type: text/plain; charset=UTF-8 Hi, I have not been able to find any usage for the state parameter in authorization requests for native apps. Further, the spec guidance of using a hash of the session cookie as the value of the state param doesn't apply for native apps. draft-wdenniss-oauth-native-apps is silent on the matter. Usage of state seems to be unique to clients conforming to the web app profile. Bottom line, looking to vet that it's safe to omit the state parameter in the authorization request for native apps, and that I'm not missing something critical. --001a1140fd5afd91fd0529b163a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have not been able to = find any usage for the state parameter in authorization requests for native= apps.=C2=A0 Further, the spec guidance of using a hash of the session cook= ie as the value of the state param doesn't apply for native apps.
=

draft-wdenniss-oauth-native-apps is silent on the matte= r.

Usage of state seems to be unique to clients co= nforming to the web app profile.

Bottom line, look= ing to vet that it's safe to omit the state parameter in the authorizat= ion request for native apps, and that I'm not missing something critica= l.
--001a1140fd5afd91fd0529b163a6-- From nobody Tue Jan 19 07:22:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816E91B305F for ; Tue, 19 Jan 2016 07:22:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.249 X-Spam-Level: X-Spam-Status: No, score=-0.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1HKekh1jomw for ; Tue, 19 Jan 2016 07:22:38 -0800 (PST) Received: from out4133-130.mail.aliyun.com (out4133-130.mail.aliyun.com [42.120.133.130]) by ietfa.amsl.com (Postfix) with ESMTP id 517AA1B305D for ; Tue, 19 Jan 2016 07:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1453216957; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=t06pq02AKleq4ZaG12p4Mk6dZoZTl1G5G8238f5HEv0=; b=SozsdQQEKwFwiJwBdDzsvGB28sD3qT9CplWKoKCy2ZzKO4ZhP0BoL+CVZZctzeiY/URFxkLPcEuwlgLq6C66YEhhsSRl3uDXXWSXug0ashr2a5bPlEWRSczUDAiuQOVjPKhtC8urCNkJRTAHf1ZSzBYCmpWip3Vw1rosktD7iss= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R661e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01l07382; MF=kepeng.lkp@alibaba-inc.com; NM=1; PH=DS; RN=2; SR=0; TI=SMTPD_----4SwrN3e_1453216944; Received: from 10.22.54.188(mailfrom:kepeng.lkp@alibaba-inc.com ip:42.120.73.208) by smtp.aliyun-inc.com(127.0.0.1); Tue, 19 Jan 2016 23:22:28 +0800 User-Agent: Microsoft-MacOutlook/14.4.8.150116 Date: Tue, 19 Jan 2016 23:22:22 +0800 From: "Kepeng Li" To: Hannes Tschofenig , "oauth@ietf.org" Message-ID: Thread-Topic: [OAUTH-WG] Proof of Possession Tokens: Next Steps References: <569E21DA.30002@gmx.net> In-Reply-To: <569E21DA.30002@gmx.net> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 15:22:40 -0000 > * to make a decision about other extensions. Nat and Kepeng submitted > the Sender Constrained JWT for OAuth2 2.0 document, see > https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06 > We asked the working group for feedback during IETF #93 and we couldn't > get enough feedback at that time. Please give us feedback whether you > are interested in exploring that solution direction as part of this > process. Today, we don't have enough indication of interest for working > on that solution direction. Yes, I am interested in this solution direction. Sender Constrained JWT is already indicated in PoP architecture document as one of the solutions. If we don=A1=AFt specify it in detail, the solution set is incomplete. And there will be interoperability issues when people implement it in different ways. Kind Regards Kepeng =D4=DA 19/1/16 7:45 pm=A3=AC "Hannes Tschofenig" =D0=B4=C8=EB: >Hi all, > >I wanted to drop a high level message about possible next steps for the >PoP work. > >As you have seen from my status update, see >http://www.ietf.org/mail-archive/web/oauth/current/msg15327.html, the >PoP architecture document was already in IESG processing but I have had >asked Kathleen to delay the publication given that we ran into scoping >issues, as discussed on the list. See >http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html > >The change of scope related to desire to not just binding a key to the >access token but also to other parts of the OAuth system to avoid cases >where an attacker can just obtain attack other parts of the system >instead (for example, by obtaining an bearer-based refresh token to then >obtain a new PoP access token). > >The recently discovered security problems tell us that we need to >simplify our solutions a bit as well to ensure that we get the security >analysed properly. More options means more time to analyse all the >different options. > >What does this mean to simplify when I talk about expanding the scope in >the earlier paragraph? > >I am suggesting to > >* to consider focusing on a public key-based only solution for the >web/smart phone app space. (The ACE working group will have to develop a >symmetric key-based version on their own, if desired.) > >* to extend the support of PoP token functionality throughout the entire >solution. This means that we have to include support for a asymmetric >version of PKCE into account (which had been discussed in the group >already earlier already). > >* to define at least a TLS-based security security solution for the >communication between the client and the resource server. > >* to rethink the work on the application layer security solution. The >HTTP signing draft, which defines the application layer security >solution for use between the client and the resource server, has expired >and we will have to find new authors. I believe we got stuck a bit. >Luckily new persons came along and volunteered to help, namely Fredrik >Ljunggren and Jakob Schlyter. Nevertheless, the group will have to judge >whether a newly developed application layer security solution is >promising. My impression is that it is a very difficult to come up with >a solution that satisfies the security requirements and, at the same >time, also takes the deployment status of proxies and other middleware >into account. > >* to make a decision about other extensions. Nat and Kepeng submitted >the Sender Constrained JWT for OAuth2 2.0 document, see >https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06 >We asked the working group for feedback during IETF #93 and we couldn't >get enough feedback at that time. Please give us feedback whether you >are interested in exploring that solution direction as part of this >process. Today, we don't have enough indication of interest for working >on that solution direction. > >Before making any changes to the PoP document set we would like to hear >your thoughts. > >Ciao >Hannes > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jan 19 08:03:04 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D4B1B310A for ; Tue, 19 Jan 2016 08:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XckyfhsBiqQ for ; Tue, 19 Jan 2016 08:02:57 -0800 (PST) Received: from p3plsmtpa12-08.prod.phx3.secureserver.net (p3plsmtpa12-08.prod.phx3.secureserver.net [68.178.252.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2201E1B3108 for ; Tue, 19 Jan 2016 08:02:57 -0800 (PST) Received: from [192.168.0.112] ([77.77.164.50]) by p3plsmtpa12-08.prod.phx3.secureserver.net with id 7s2v1s00615ZTut01s2v7E; Tue, 19 Jan 2016 09:02:56 -0700 To: oauth@ietf.org References: From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <569E5E2E.40204@connect2id.com> Date: Tue, 19 Jan 2016 18:02:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080206030604030505000400" Archived-At: Subject: Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 16:03:01 -0000 This is a cryptographically signed message in MIME format. --------------ms080206030604030505000400 Content-Type: multipart/alternative; boundary="------------040109020103080107090505" This is a multi-part message in MIME format. --------------040109020103080107090505 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is good news William! I hope more developers will become aware of PKCE through its adoption by Google. Right now there's virtually zero awareness about this option among devs. Coincidentally we also put support for PKCE in the Nimbus OAuth/OIDC SDK this week. Regarding errors we practice what Nat suggested - i.e. we don't detail the exact cause of the error, but in the "error_description" field we list all possible causes that a client dev should check - invalid code, redirect_uri mismatch, bad pkce challenge, e= tc. Cheers, Vladimir On 19/01/16 07:46, William Denniss wrote: > This month we rolled out full PKCE (RFC7636) support on our OAuth endpo= ints. > > We'd previously implemented an earlier draft but were not conformant to= the > final spec when it was published =96 now we are. Both "plain" and "S256= " > transforms are supported. As always, get the latest endpoints from our > discovery document: > https://accounts.google.com/.well-known/openid-configuration > > If you give it a spin, let me know how you go! The team monitors the St= ack > Overflow google-oauth > tag too, for a= ny > implementation questions. > > I'm keen to know what we should be putting in our discovery doc to decl= are > PKCE support (see the thread "Advertise PKCE support in OAuth 2.0 > Discovery"), hope we can agree on that soon. > > One implementation detail not covered in the spec: we error if you > send code_verifier to the token endpoint when exchanging a code that wa= s > issued without a code_challenge being present. The assumption being tha= t if > you are sending code_verifier on the token exchange, you are using PKCE= and > should have sent code_challenge on the authorization request, so someth= ing > is amiss. > > William > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --=20 Vladimir Dzhuvinov=20 --------------040109020103080107090505 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is good news William! I hope more developers will become aware of PKCE through its adoption by Google. Right now there's virtually zero awareness about this option among devs.

Coincidentally we also put support for PKCE in the Nimbus OAuth/OIDC SDK this week. Regarding errors we practice what Nat suggested - i.e. we don't detail the exact cause of the error, but in the "error_description" field we list all possible causes that a client dev should check - invalid code, redirect_uri mismatch, bad pkce challenge, etc.

Cheers,

Vladimir

On 19/01/16 07:46, William Denniss wrote:
This month we rolled out full PKCE (RFC7636) support=
 on our OAuth endpoints.

We'd previously implemented an earlier draft but were not conformant to t=
he
final spec when it was published =96 now we are. Both "plain" and "S256"
transforms are supported. As always, get the latest endpoints from our
discovery document:
https://accounts.google.com/.well-known/o=
penid-configuration

If you give it a spin, let me know how you go! The team monitors the Stac=
k
Overflow google-oauth
<http://stackoverflow.com/questions/tagged/g=
oogle-oauth> tag too, for any
implementation questions.

I'm keen to know what we should be putting in our discovery doc to declar=
e
PKCE support (see the thread "Advertise PKCE support in OAuth 2.0
Discovery"), hope we can agree on that soon.

One implementation detail not covered in the spec: we error if you
send code_verifier to the token endpoint when exchanging a code that was
issued without a code_challenge being present. The assumption being that =
if
you are sending code_verifier on the token exchange, you are using PKCE a=
nd
should have sent code_challenge on the authorization request, so somethin=
g
is amiss.

William




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


--=20
Vladimir Dzhuvinov
--------------040109020103080107090505-- --------------ms080206030604030505000400 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+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB /eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6 cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+ +Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAxMTkxNjAyNTRaMC8GCSqGSIb3DQEJBDEiBCAcs7d7HlhdfDp39HGY8aN14I9+vu05 Dsom4ODc1hLeojBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQB1QkuzZqiX dxu1AyIwK+N3CXYxqKz0T7eKrTLJHOUj28nhrJMY/9jMOuhATS2yw6V+nWGpSH18PKpeq5I+ DiHz3lzln/Th+w8Kd0tnyjSBACVbgGxWjqegqpw6KaQscGWrZP4GhosPTLNomFJr9/8qIyEq 2sLdm3gXslJ4Xbzw51CJQyfJ/Zyfsmzzqltm4ck1s7Hi/6T5eowyx0SgjMRhzKDCWCbMykut fX+oVfJhT0TlT9/Ax8Oj77bpLApa9ZV5CAftEw9gCpG8OpO3DugncBMwWxVUmulogj5Lxkdv RXH/r56BzAUoaFvTuayTFeTvW9jqRMC1UlS6b/vw4usDAAAAAAAA --------------ms080206030604030505000400-- From nobody Tue Jan 19 08:29:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DE91B31F8 for ; Tue, 19 Jan 2016 08:29:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMUgKY05OKG4 for ; Tue, 19 Jan 2016 08:29:12 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAB9B1B31F6 for ; Tue, 19 Jan 2016 08:29:11 -0800 (PST) X-AuditID: 1209190d-f79306d000006b70-6f-569e6456935d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id A6.F9.27504.6546E965; Tue, 19 Jan 2016 11:29:10 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u0JGT9Do031979; Tue, 19 Jan 2016 11:29:10 -0500 Received: from [192.168.128.48] (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 u0JGT76Z022618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Jan 2016 11:29:09 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Tue, 19 Jan 2016 11:29:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8D27A368-436A-4DBA-96B6-8CC76253F7AF@mit.edu> References: To: Lewis Adam-CAL022 X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrBuWMi/M4GKvlMXObT9ZLU6+fcXm wOSxZMlPJo8JE3+wBDBFcdmkpOZklqUW6dslcGW8+3CNrWA7T8WtGU1sDYyNXF2MnBwSAiYS z9d/YIewxSQu3FvP1sXIxSEksJhJ4vCZWcwQzkZGiWXLDrNDOLeZJN7tPgjWwiygLvFn3iVm EJtXQE/i1a3LrCC2sICzxLcf+5hAbDYBVYnpa1qAbA4OToFAiZ5lUiBhFqDwtvsf2UHCIGPa T7pATNSWWLbwNTNImFfASmL72RKQsJBAgMSvrkaw4SICFhJbX15hgrhZVmL370dMExgFZyG5 ZxaSe2YhmbqAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrpFebmaJXmpK6SZGcPBK8u5gfHdQ 6RCjAAejEg/vC8e5YUKsiWXFlbmHGCU5mJREeY0i5oUJ8SXlp1RmJBZnxBeV5qQWH2KU4GBW EuG9FweU401JrKxKLcqHSUlzsCiJ8+7qAJokkJ5YkpqdmlqQWgSTleHgUJLgvZ0E1ChYlJqe WpGWmVOCkGbi4AQZzgM0vASkhre4IDG3ODMdIn+KUVFKnPcSSEIAJJFRmgfXC0ouCW8Pm75i FAd6RZhXIBmoigeYmOC6XwENZgIa/NNjNsjgkkSElFQD47wduUqSESlPi04byQY3L2I7ZcJh d91Vvv2QflAEY/eN28wXCk4yyIhNdHi1oslf5MqT81/eabV8033mPvvUz1c5iv9OHFd8Pllt 1Rv+C1fT2J1nuIdne/Jm/X+z4JDqGWvrPS+nHPFg2/zx3PvDklbXnoZlLf/JPemCisC87rJ9 21ZzefrtqVJiKc5INNRiLipOBAAzpUiGCQMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] best practice for Native app + state param? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 16:29:14 -0000 I think there=E2=80=99s no advice because it=E2=80=99s not different: = you should still be using the state parameter. Just use a random value = with high enough entropy, which is also what most web applications do = (the advice in the spec is weird and I think a remnant of Bradley making = things too complicated in his advice). In a web app, it gets tied to the = session cookie back on the server, you don=E2=80=99t need any = particularly fancy binding beyond your usual session management. In a = native app, just store it in the application before you send it and look = it up on the way back to make sure it matches. Combine this with PKCE = and you=E2=80=99ve got a pretty solid set of protections for native = apps. =E2=80=94 Justin > On Jan 19, 2016, at 10:18 AM, Adam Lewis = wrote: >=20 > Hi, >=20 > I have not been able to find any usage for the state parameter in = authorization requests for native apps. Further, the spec guidance of = using a hash of the session cookie as the value of the state param = doesn't apply for native apps. >=20 > draft-wdenniss-oauth-native-apps is silent on the matter. >=20 > Usage of state seems to be unique to clients conforming to the web app = profile. >=20 > Bottom line, looking to vet that it's safe to omit the state parameter = in the authorization request for native apps, and that I'm not missing = something critical. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Tue Jan 19 08:34:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E971B321B for ; Tue, 19 Jan 2016 08:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lXK4umBaXml for ; Tue, 19 Jan 2016 08:34:25 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61BF1B31F9 for ; Tue, 19 Jan 2016 08:34:24 -0800 (PST) X-AuditID: 1209190f-f79d06d000004b20-65-569e658e10bb Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 76.F2.19232.E856E965; Tue, 19 Jan 2016 11:34:22 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u0JGYM2N002057; Tue, 19 Jan 2016 11:34:22 -0500 Received: from [192.168.128.48] (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 u0JGYK6W024669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Jan 2016 11:34:21 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F7CF0F71-B3F5-47CF-B4B5-863F64BEE713"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5.2 From: Justin Richer In-Reply-To: <569E21DA.30002@gmx.net> Date: Tue, 19 Jan 2016 11:34:18 -0500 Message-Id: <840D6473-8F4D-4843-9CFB-97E4AA1AC8CB@mit.edu> References: <569E21DA.30002@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMKsWRmVeSWpSXmKPExsUixG6nrtuXOi/M4MwFS4ulO++xWpx8+4rN gclj8ab9bB5LlvxkCmCK4rJJSc3JLEst0rdL4MrY0v2CseBtXMWkjYkNjJcCuhg5OSQETCR2 7T/HBGGLSVy4t56ti5GLQ0hgMZPEjQ9bGSGcjYwS2+ZPZ4FwbjNJXN29jBGkRVjATuLyo352 EJtXQE/i1a3LrCBFzAJTGCUePwFxOIDmSknM2C8AUsMmoCoxfU0L2DpOIPvDzPtsICUsQPaO HgsQk1lAXaL9pAvERCuJnX2nWEBsIQEViauX+sC2iggYSlyfOZ0V4mhZid2/HzFNYBScheSI WciOAEkwCyRJ7P/xkB3C1pZYtvA1M4StKbG/ezkLpriGROe3iVC98hLb386BiltKLJ55A6re VuJW3wImCNtO4tG0RawLGLlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zro5WaW6KWmlG5iBMUf pyT/DsZvB5UOMQpwMCrx8L5wnBsmxJpYVlyZe4hRkoNJSZTXKGJemBBfUn5KZUZicUZ8UWlO avEhRhWgXY82rL7AKMWSl5+XqiTCey8OqI43JbGyKrUoH6ZMmoNFSZx3VwfQVIH0xJLU7NTU gtQimKwMB4eSBK97ClCjYFFqempFWmZOCUKaiYPzEKMEBw/Q8IRkkOHFBYm5xZnpEPlTjIpS 4rwWIM0CIImM0jy4XlDaTHh72PQVozjQW8K8lSBVPMCUC9f9CmgwE9Dgnx6zQQaXJCKkpBoY MyZMXhNy9oyAUeSyCU7xn9K9GVTm8kws49377quHqsUTl1cBjsu79UUCZzgIbwv/MsXC4bjG winr2icfr/VfxDhj2uK/E/NNP2t6sMzuC3RxeRKpZKK4d8ME9Vz1/73yh/dwnrlxMfWSWsoh tqQPhZ/OzFkro/WmKuRG9sYVhndTuBYlH2KbocRSnJFoqMVcVJwIAKeU6fp2AwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 16:34:28 -0000 --Apple-Mail=_F7CF0F71-B3F5-47CF-B4B5-863F64BEE713 Content-Type: multipart/alternative; boundary="Apple-Mail=_D8B53893-D7A8-4001-910C-C29A0AC8E71C" --Apple-Mail=_D8B53893-D7A8-4001-910C-C29A0AC8E71C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Well that=E2=80=99s interesting: I was unaware I was being removed as = the author of the HTTP signing draft. This is especially surprising = after the presentation I gave at Yokohama about this topic. The draft = hasn=E2=80=99t been updated because there=E2=80=99s not really been any = discussion on it here in the group to drive an update, and I=E2=80=99m = not one to artificially publish a new draft with the same content and a = new date just to avoid the =E2=80=9Cexpired=E2=80=9D tag in the = repository. To see the direction I proposed that we go in at Yokohama, check my = slides here: https://www.ietf.org/proceedings/94/slides/slides-94-oauth-3.pdf = Again, I got no real feedback on this and there was no discussion on the = list. Even so, I=E2=80=99m implementing this in a Node.js application = anyway that I plan to post back to the group here when it=E2=80=99s = done. =E2=80=94 Justin > On Jan 19, 2016, at 6:45 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > I wanted to drop a high level message about possible next steps for = the > PoP work. >=20 > As you have seen from my status update, see > http://www.ietf.org/mail-archive/web/oauth/current/msg15327.html, the > PoP architecture document was already in IESG processing but I have = had > asked Kathleen to delay the publication given that we ran into scoping > issues, as discussed on the list. See > http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html >=20 > The change of scope related to desire to not just binding a key to the > access token but also to other parts of the OAuth system to avoid = cases > where an attacker can just obtain attack other parts of the system > instead (for example, by obtaining an bearer-based refresh token to = then > obtain a new PoP access token). >=20 > The recently discovered security problems tell us that we need to > simplify our solutions a bit as well to ensure that we get the = security > analysed properly. More options means more time to analyse all the > different options. >=20 > What does this mean to simplify when I talk about expanding the scope = in > the earlier paragraph? >=20 > I am suggesting to >=20 > * to consider focusing on a public key-based only solution for the > web/smart phone app space. (The ACE working group will have to develop = a > symmetric key-based version on their own, if desired.) >=20 > * to extend the support of PoP token functionality throughout the = entire > solution. This means that we have to include support for a asymmetric > version of PKCE into account (which had been discussed in the group > already earlier already). >=20 > * to define at least a TLS-based security security solution for the > communication between the client and the resource server. >=20 > * to rethink the work on the application layer security solution. The > HTTP signing draft, which defines the application layer security > solution for use between the client and the resource server, has = expired > and we will have to find new authors. I believe we got stuck a bit. > Luckily new persons came along and volunteered to help, namely Fredrik > Ljunggren and Jakob Schlyter. Nevertheless, the group will have to = judge > whether a newly developed application layer security solution is > promising. My impression is that it is a very difficult to come up = with > a solution that satisfies the security requirements and, at the same > time, also takes the deployment status of proxies and other middleware > into account. >=20 > * to make a decision about other extensions. Nat and Kepeng submitted > the Sender Constrained JWT for OAuth2 2.0 document, see > https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06 > We asked the working group for feedback during IETF #93 and we = couldn't > get enough feedback at that time. Please give us feedback whether you > are interested in exploring that solution direction as part of this > process. Today, we don't have enough indication of interest for = working > on that solution direction. >=20 > Before making any changes to the PoP document set we would like to = hear > your thoughts. >=20 > Ciao > Hannes >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_D8B53893-D7A8-4001-910C-C29A0AC8E71C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Well that=E2=80=99s interesting: I was unaware I was being = removed as the author of the HTTP signing draft. This is especially = surprising after the presentation I gave at Yokohama about this topic. = The draft hasn=E2=80=99t been updated because there=E2=80=99s not really = been any discussion on it here in the group to drive an update, and = I=E2=80=99m not one to artificially publish a new draft with the same = content and a new date just to avoid the =E2=80=9Cexpired=E2=80=9D tag = in the repository. 

To see the direction I proposed that we go in at Yokohama, = check my slides here:

https://www.ietf.org/proceedings/94/slides/slides-94-oauth-3.pd= f

Again, I = got no real feedback on this and there was no discussion on the list. = Even so, I=E2=80=99m implementing this in a Node.js application anyway = that I plan to post back to the group here when it=E2=80=99s = done. 

 =E2=80=94 Justin

On = Jan 19, 2016, at 6:45 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

I wanted to drop a high level message about = possible next steps for the
PoP work.

As you have seen from my status update, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15327.htm= l, the
PoP architecture document was already in IESG = processing but I have had
asked Kathleen to delay the = publication given that we ran into scoping
issues, as = discussed on the list. See
http://www.ietf.org/mail-archive/web/oauth/current/msg15177.htm= l

The change of scope related to desire = to not just binding a key to the
access token but also to = other parts of the OAuth system to avoid cases
where an = attacker can just obtain attack other parts of the system
instead (for example, by obtaining an bearer-based refresh = token to then
obtain a new PoP access token).

The recently discovered security problems tell = us that we need to
simplify our solutions a bit as well to = ensure that we get the security
analysed properly. More = options means more time to analyse all the
different = options.

What does this mean to simplify = when I talk about expanding the scope in
the earlier = paragraph?

I am suggesting to

* to consider focusing on a public key-based = only solution for the
web/smart phone app space. (The ACE = working group will have to develop a
symmetric key-based = version on their own, if desired.)

* to = extend the support of PoP token functionality throughout the entire
solution. This means that we have to include support for a = asymmetric
version of PKCE into account (which had been = discussed in the group
already earlier already).

* to define at least a TLS-based security = security solution for the
communication between the client = and the resource server.

* to rethink the = work on the application layer security solution. The
HTTP = signing draft, which defines the application layer security
solution for use between the client and the resource server, = has expired
and we will have to find new authors. I = believe we got stuck a bit.
Luckily new persons came along = and volunteered to help, namely Fredrik
Ljunggren and = Jakob Schlyter. Nevertheless, the group will have to judge
whether a newly developed application layer security solution = is
promising. My impression is that it is a very difficult = to come up with
a solution that satisfies the security = requirements and, at the same
time, also takes the = deployment status of proxies and other middleware
into = account.

* to make a decision about other = extensions. Nat and Kepeng submitted
the Sender = Constrained JWT for OAuth2 2.0 document, see
https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06We asked the working group for feedback during IETF #93 and = we couldn't
get enough feedback at that time. Please give = us feedback whether you
are interested in exploring that = solution direction as part of this
process. Today, we = don't have enough indication of interest for working
on = that solution direction.

Before making any = changes to the PoP document set we would like to hear
your = thoughts.

Ciao
Hannes

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

= --Apple-Mail=_D8B53893-D7A8-4001-910C-C29A0AC8E71C-- --Apple-Mail=_F7CF0F71-B3F5-47CF-B4B5-863F64BEE713 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWnmWLAAoJEDPAngkbd+w9Qf0H/0UA7bfcQwdzaLQ2KhrhqSRs XsinAagwA5vKlc9AxTogh72WAl3gKlDJauPtdy3L8D9gNLzwbfhJfcuBU61NYX1b Y/bQRXNKqWwcs9cpaKhEd1FwEBCeXi9a76212rLPj8AF+b9QGCRLpWJMYc611Xqx hSr1Ns7eQoFS8dZcC3PlcoTXPcgFr0wZjxiCTWXXuoqETXK3D0ajtToaf3g6h0uU DyMFpZqahy0RmNwHmCh90XrnEXIpWJUhsLNT8LAuJpPDFka/+fwdcY0kz9boQFym WHYifgEHFuHmcmiwsS9VGuW4anf/6wLQ9HTfewF0q9SUCAGrB2rWTHJmrxo9A4w= =EgSY -----END PGP SIGNATURE----- --Apple-Mail=_F7CF0F71-B3F5-47CF-B4B5-863F64BEE713-- From nobody Tue Jan 19 09:08:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BCC1B32B4 for ; Tue, 19 Jan 2016 09:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUeaXArDvUye for ; Tue, 19 Jan 2016 09:08:47 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 584FB1B32B0 for ; Tue, 19 Jan 2016 09:08:47 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id o124so188224961oia.3 for ; Tue, 19 Jan 2016 09:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nmLtHq4gPsOYvAZ9/bNOX7Qhi1WdXh4IJpWfXMSvu04=; b=N4ax7woSjlF+GJp3sFstxBQ4zb05QUjQJNm8ay5kFwQhdTQzec2GcCJxsoWGnM9z1t d5lo9buQO5pYiz1aAn6IHoMkwB1ztTLoFPgRjmzfgpvtGRk99g5jsckwU1pVq4xK2qeG 3t7xCTeW1oP/12R+LdkibZ4OBLKwgfMiLr1tl01V3x1/Ccl9k37zTiI0VDwQTIaqhpMv rZs7XlqoGFRZEJcLKnLIMY9BSqIJ1Tj4b/8H5B6bfQJSdJxDypkAhzMpntS5cW3Fn8BJ a1DlnsFZO2xYNh7r2xcp+xixMsa8BayZoB08RAOa45yvOxmBX0kq37ZYdElL03SVAJIT K2ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nmLtHq4gPsOYvAZ9/bNOX7Qhi1WdXh4IJpWfXMSvu04=; b=aO0JgISgKWDbaXvX16eD6WDrU4nVuZUkDsdkc2wOwug2TCvgInQp3lpYpZU3a0x8ri 68KkCdRHN2MEJ/ja+yGSMfVX1CyScF145pthuNDm7nk96OlfEF1/ws2ZXAGVxX89pU1i VlPlB8r9i2dAA93MczHYCKhJnaYR0MrHx9udSeZTJECCc6PgQ+FDXn3owyIJhZdP1fSB Z6tE5B4zB29OSHNI5wbWNKsNK1YvfCj1TkKawVPM5fn4Y0S1F/FX0PQJtWiJ6eYSt42s uW0p1jxRF3Lh751Kb2jBXxUAgdCLYmmDDU600PZW42gML8OBPLQwV5lNmwGquoLxkxiK EFRg== X-Gm-Message-State: ALoCoQkS6f47sCbyJfao405MfXGbv74bPOXbSMBt5N3+IhiJ9ySDVM55ndvnLQcpAyhK6dnF3l+UhLOpj8f84gjGyzZwhqvtW8oXS3KCs2rSHrC2EcI3JRA= X-Received: by 10.202.48.6 with SMTP id w6mr23418431oiw.97.1453223326606; Tue, 19 Jan 2016 09:08:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Tue, 19 Jan 2016 09:08:26 -0800 (PST) In-Reply-To: <8E6EBF44-2057-4429-8347-1BA447C3F3DB@ve7jtb.com> References: <8E6EBF44-2057-4429-8347-1BA447C3F3DB@ve7jtb.com> From: William Denniss Date: Tue, 19 Jan 2016 09:08:26 -0800 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a113cd98629ad9a0529b2ecc2 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 17:08:49 -0000 --001a113cd98629ad9a0529b2ecc2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 19, 2016 at 4:32 AM, John Bradley wrote: > Great news. > > If you have sent a PKCE challenge and no verifier that should be a > authentication failure as if the value were wrong. > I agree that case would always error. This is the opposite case, where there was no challenge on the authorization request, but there was the verifier on the token request. > I don=E2=80=99t know if it needs a special error. > > Thanks for bringing it up. > > John B. > > On Jan 19, 2016, at 2:46 AM, William Denniss wrote: > > This month we rolled out full PKCE (RFC7636) support on our OAuth > endpoints. > > We'd previously implemented an earlier draft but were not conformant to > the final spec when it was published =E2=80=93 now we are. Both "plain" a= nd "S256" > transforms are supported. As always, get the latest endpoints from our > discovery document: > https://accounts.google.com/.well-known/openid-configuration > > If you give it a spin, let me know how you go! The team monitors the Stac= k > Overflow google-oauth > tag too, for any > implementation questions. > > I'm keen to know what we should be putting in our discovery doc to declar= e > PKCE support (see the thread "Advertise PKCE support in OAuth 2.0 > Discovery"), hope we can agree on that soon. > > One implementation detail not covered in the spec: we error if you > send code_verifier to the token endpoint when exchanging a code that was > issued without a code_challenge being present. The assumption being that = if > you are sending code_verifier on the token exchange, you are using PKCE a= nd > should have sent code_challenge on the authorization request, so somethin= g > is amiss. > > William > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a113cd98629ad9a0529b2ecc2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 19, 2016 at 4:32 AM, John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:
Great news.

If you have sent a PKCE challeng= e and no verifier that should be a authentication failure as if the value w= ere wrong.

I agree that case wo= uld always error.=C2=A0

This is the opposite case,= where there was no challenge on the authorization request, but there was t= he verifier on the token request.

=C2=A0
I don= =E2=80=99t know if it needs a special error.

Thank= s for bringing it up.

John B.

<= blockquote type=3D"cite">
On Jan 19, 2016, at 2:= 46 AM, William Denniss <wdenniss@google.com> wrote:

=
This month we rolled out full PKCE (RFC7636) support= on our OAuth endpoints.

We'd previously imple= mented an earlier draft but were not conformant to the final spec when it w= as published =E2=80=93 now we are. Both "plain" and "S256&qu= ot; transforms are supported. As always, get the latest endpoints from our = discovery document:=C2=A0https://accounts.google.com/.well-= known/openid-configuration

If you give it a sp= in, let me know how you go! The team monitors the Stack Overflow=C2=A0google-oauth=C2=A0tag=C2=A0too, for any implementation questions.<= /div>

I'm keen to know what we should be putting in our d= iscovery doc to declare PKCE support (see the thread "Advertise PKCE s= upport in OAuth 2.0 Discovery"), hope we can agree on that soon.
<= br>
One implementation detail not covered in the spec: we error i= f you send=C2=A0code_verifier=C2=A0to the token endpoint when exchanging a = code that was issued without a code_challenge being present. The assumption= being that if you are sending code_verifier on the token exchange, you are= using PKCE and should have sent code_challenge on the authorization reques= t, so something is amiss.

William




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

--001a113cd98629ad9a0529b2ecc2-- From nobody Tue Jan 19 09:15:04 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23E61B32C9 for ; Tue, 19 Jan 2016 09:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id axdAlS6WUjge for ; Tue, 19 Jan 2016 09:15:01 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512241B32C8 for ; Tue, 19 Jan 2016 09:15:01 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id o124so188351952oia.3 for ; Tue, 19 Jan 2016 09:15:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C68L9vqwz5J3tm5fSQAog8ou2izQ28d5SJ9DZXmB18o=; b=gdTFa8652T6eYPoILY6HSBWy5l2CZWZLVcn9M2GbJeNMhEjQjdDk5C1m+zuFHSEXgB Sdd0aY1RqzHhKS2JGVxro+9zqVXjJaOev816QlTwDcCU5Sa/1oaXHq7WZ/7X1kohpv5D Yft4WV6fPau5PXaM9pQxxR2Sr6Z/LsTomDs2APH3Z/u6pv70+cWnClXQHbuf5kLnSn27 Zg6zJmbolA0BarCFqxdSi69tV/anqg0EDfrAc39AzJJMTjQo0tDNnD8cpvk1Hks0ol1/ /jq2PMi9xPtdC4aNt4I8tzyx9g0L8SSSVxF941dW7Pg/t1yuHwiC1FkL9kufItKrzb17 idjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=C68L9vqwz5J3tm5fSQAog8ou2izQ28d5SJ9DZXmB18o=; b=GgNgJulp76cDNHLm4ofugtbU7FA07JLz1FvG4EimUXXutn0JFZmNaJVNJS+A5XzNIJ J+MI03XfO6VL99Rmd+0kMWQGL28mtSURkT+UvBtlKpksVb5FV5mol+NKl41jpVyI0H35 KNkrvF8czgluNbpGVlccrKVzI1WssH/UcD3VDN/+hgkRutIhIV86O8w/iG/bOO+XMStb TU/Xb9DeTazLXRjBoUlftYcni31OiUYtl3LKtuuDCemE/Ua3DkaK1Q8GV8kjDEv1WjrZ dRV4t7IFbKJCA8L4qP5dOE7DxzeqHj0d5yqvsNSem+JCB2/lecYaDBEV56cbgp161WOO oHXg== X-Gm-Message-State: ALoCoQl74wJOgj6fnfy4HRT0n4lx9FLVz5sYyru+IpdEjq9vPanCg0AvX9lNh3Xzm8JJu6kxX4xXAcyhgkkD7Vd1AhzEroTRwpaMs3iEbrYRySr6PhDJLsM= X-Received: by 10.202.226.141 with SMTP id z135mr23120384oig.21.1453223700576; Tue, 19 Jan 2016 09:15:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Tue, 19 Jan 2016 09:14:40 -0800 (PST) In-Reply-To: <569E5E2E.40204@connect2id.com> References: <569E5E2E.40204@connect2id.com> From: William Denniss Date: Tue, 19 Jan 2016 09:14:40 -0800 Message-ID: To: Vladimir Dzhuvinov Content-Type: multipart/alternative; boundary=001a11408cf87412630529b302ae Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 17:15:03 -0000 --001a11408cf87412630529b302ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Awesome! Great to hear you've implemented it too :) I added client-side support this weekend into an iOS client that I'm writing, didn't take long at all. On Tue, Jan 19, 2016 at 8:02 AM, Vladimir Dzhuvinov wrote: > This is good news William! I hope more developers will become aware of > PKCE through its adoption by Google. Right now there's virtually zero > awareness about this option among devs. > > Coincidentally we also put support for PKCE in the Nimbus OAuth/OIDC SDK > this week. Regarding errors we practice what Nat suggested - i.e. we don'= t > detail the exact cause of the error, but in the "error_description" field > we list all possible causes that a client dev should check - invalid code= , > redirect_uri mismatch, bad pkce challenge, etc. > > Cheers, > > Vladimir > > On 19/01/16 07:46, William Denniss wrote: > > This month we rolled out full PKCE (RFC7636) support on our OAuth endpoin= ts. > > We'd previously implemented an earlier draft but were not conformant to t= he > final spec when it was published =E2=80=93 now we are. Both "plain" and "= S256" > transforms are supported. As always, get the latest endpoints from our > discovery document:https://accounts.google.com/.well-known/openid-configu= ration > > If you give it a spin, let me know how you go! The team monitors the Stac= k > Overflow google-oauth tag too, for = any > implementation questions. > > I'm keen to know what we should be putting in our discovery doc to declar= e > PKCE support (see the thread "Advertise PKCE support in OAuth 2.0 > Discovery"), hope we can agree on that soon. > > One implementation detail not covered in the spec: we error if you > send code_verifier to the token endpoint when exchanging a code that was > issued without a code_challenge being present. The assumption being that = if > you are sending code_verifier on the token exchange, you are using PKCE a= nd > should have sent code_challenge on the authorization request, so somethin= g > is amiss. > > William > > > > > _______________________________________________ > 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 > > --001a11408cf87412630529b302ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Awesome! Great to hear you've implemented it too :)
I added client-side support this weekend into an iOS clien= t that I'm writing, didn't take long at all.

On Tue, Jan 19, 2016 at 8:02 AM, V= ladimir Dzhuvinov <vladimir@connect2id.com> wrote:
=
=20 =20 =20
This is good news William! I hope more developers will become aware of PKCE through its adoption by Google. Right now there's virtually zero awareness about this option among devs.

Coincidentally we also put support for PKCE in the Nimbus OAuth/OIDC SDK this week. Regarding errors we practice what Nat suggested - i.e. we don't detail the exact cause of the error, but in the "error_description" field we list all possible causes that a = client dev should check - invalid code, redirect_uri mismatch, bad pkce challenge, etc.

Cheers,

Vladimir

On 19/01/16 07:46, William Denniss wrote:
This month we rolled out full PKCE (RFC7636) su=
pport on our OAuth endpoints.

We'd previously implemented an earlier draft but were not conformant to=
 the
final spec when it was published =E2=80=93 now we are. Both "plain&quo=
t; and "S256"
transforms are supported. As always, get the latest endpoints from our
discovery document:
https://accounts.google.com/.well-known/openid-configuratio=
n

If you give it a spin, let me know how you go! The team monitors the Stack
Overflow google-oauth
<http://stackoverflow.com/questions/tagged/google-oauth=
> tag too, for any
implementation questions.

I'm keen to know what we should be putting in our discovery doc to decl=
are
PKCE support (see the thread "Advertise PKCE support in OAuth 2.0
Discovery"), hope we can agree on that soon.

One implementation detail not covered in the spec: we error if you
send code_verifier to the token endpoint when exchanging a code that was
issued without a code_challenge being present. The assumption being that if
you are sending code_verifier on the token exchange, you are using PKCE and
should have sent code_challenge on the authorization request, so something
is amiss.

William




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


--=20
Vladimir Dzhuvinov

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


--001a11408cf87412630529b302ae-- From nobody Tue Jan 19 11:32:13 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77731B34E6 for ; Tue, 19 Jan 2016 11:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYybR2K5Kwup for ; Tue, 19 Jan 2016 11:32:09 -0800 (PST) Received: from omr-m001e.mx.aol.com (omr-m001e.mx.aol.com [204.29.186.1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBA91B34E2 for ; Tue, 19 Jan 2016 11:32:09 -0800 (PST) Received: from mtaout-mae01.mx.aol.com (mtaout-mae01.mx.aol.com [172.26.254.141]) by omr-m001e.mx.aol.com (Outbound Mail Relay) with ESMTP id 5430238000BD; Tue, 19 Jan 2016 14:32:08 -0500 (EST) Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mae01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id ED6E538000089; Tue, 19 Jan 2016 14:32:07 -0500 (EST) To: Lewis Adam-CAL022 References: <8D27A368-436A-4DBA-96B6-8CC76253F7AF@mit.edu> From: George Fletcher Organization: AOL LLC Message-ID: <569E8F37.9040508@aol.com> Date: Tue, 19 Jan 2016 14:32:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <8D27A368-436A-4DBA-96B6-8CC76253F7AF@mit.edu> Content-Type: multipart/alternative; boundary="------------090308090806070809010400" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453231928; bh=03Gv8pNf3e4rJPSIt7y7D1nSIRteMcsCGo51ZvEo+js=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=k55nslZkl//P1KHWxA+DChDrUwkLYiPM94OBzIW6M5//Zujn796oTHQyNfQePlHp2 C0ZTgDPuNnw/9gCkPbK3ynVsQLA58F/B78fLv61XDVKw4yhzH9hUVYjuDlkxe6RV3Z szavrIIU2Igc/3ZAM92PdZzwZy6SHFAFaU1L8xwM= x-aol-sid: 3039ac1afe8d569e8f373f79 X-AOL-IP: 10.172.102.124 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] best practice for Native app + state param? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2016 19:32:11 -0000 This is a multi-part message in MIME format. --------------090308090806070809010400 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit +1 to both using state and PKCE (especially when using system web controllers; e.g. safari-view-controller). On 1/19/16 11:29 AM, Justin Richer wrote: > I think there’s no advice because it’s not different: you should still be using the state parameter. Just use a random value with high enough entropy, which is also what most web applications do (the advice in the spec is weird and I think a remnant of Bradley making things too complicated in his advice). In a web app, it gets tied to the session cookie back on the server, you don’t need any particularly fancy binding beyond your usual session management. In a native app, just store it in the application before you send it and look it up on the way back to make sure it matches. Combine this with PKCE and you’ve got a pretty solid set of protections for native apps. > > — Justin > >> On Jan 19, 2016, at 10:18 AM, Adam Lewis wrote: >> >> Hi, >> >> I have not been able to find any usage for the state parameter in authorization requests for native apps. Further, the spec guidance of using a hash of the session cookie as the value of the state param doesn't apply for native apps. >> >> draft-wdenniss-oauth-native-apps is silent on the matter. >> >> Usage of state seems to be unique to clients conforming to the web app profile. >> >> Bottom line, looking to vet that it's safe to omit the state parameter in the authorization request for native apps, and that I'm not missing something critical. >> _______________________________________________ >> 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 -- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography --------------090308090806070809010400 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit +1 to both using state and PKCE (especially when using system web controllers; e.g. safari-view-controller).

On 1/19/16 11:29 AM, Justin Richer wrote:
I think there’s no advice because it’s not different: you should still be using the state parameter. Just use a random value with high enough entropy, which is also what most web applications do (the advice in the spec is weird and I think a remnant of Bradley making things too complicated in his advice). In a web app, it gets tied to the session cookie back on the server, you don’t need any particularly fancy binding beyond your usual session management. In a native app, just store it in the application before you send it and look it up on the way back to make sure it matches. Combine this with PKCE and you’ve got a pretty solid set of protections for native apps.

 — Justin


On Jan 19, 2016, at 10:18 AM, Adam Lewis <Adam.Lewis@motorolasolutions.com> wrote:

Hi,

I have not been able to find any usage for the state parameter in authorization requests for native apps.  Further, the spec guidance of using a hash of the session cookie as the value of the state param doesn't apply for native apps.

draft-wdenniss-oauth-native-apps is silent on the matter.

Usage of state seems to be unique to clients conforming to the web app profile.

Bottom line, looking to vet that it's safe to omit the state parameter in the authorization request for native apps, and that I'm not missing something critical.
_______________________________________________
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


-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography
--------------090308090806070809010400-- From nobody Tue Jan 19 19:02:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D8E1A036E for ; Tue, 19 Jan 2016 19:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnHIAZ11PsjM for ; Tue, 19 Jan 2016 19:02:29 -0800 (PST) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) (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 7A8281A036B for ; Tue, 19 Jan 2016 19:02:29 -0800 (PST) Received: by mail-qk0-f172.google.com with SMTP id s5so49539316qkd.0 for ; Tue, 19 Jan 2016 19:02:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=/U5YZ9r3Q6aZyLe+V3B1zyNhPiw+gpUuNvyqvaMB4xE=; b=d5CeGtD37h80nJZZKKDNqkJ5gyd4orByp+MlonMzlP4Q+45QiQz1B7cMe2nyzIGmOT 2bFNTAzQOvZMqxzl8/eGoNGKjfP9TK2I6zEiiSdxrxogJ7mWgp0lmx6l/aE8t1zcBAwv k/x2KI/wmZd9DEKOHrd09BfmlzAyMGA/jQZly+1IrUrUXh++diDpg0DdPKpBGNmWufUT TpKgMo52LzmwJxuGzMXxnunnUm+653sWKp1yFCJQig/i6fPA0uQadtc3zlZut78UYTfy ItbJgO8vAhzsmfkGCDo3zvq1YLi5Asu2rRASWuV5rYlfExGS7estvAmAaZjWEdOCZvtS AhFQ== X-Gm-Message-State: ALoCoQknxmX1jsxyDF0vGezeZh+ZzCr8QZbMe/zoLk2f/sPtXl7Q338Xe0VxYmwtRy3qUpSLCDTLGWjEtpNSAFlFYOmOB65i5A== X-Received: by 10.55.78.207 with SMTP id c198mr41862399qkb.34.1453258948579; Tue, 19 Jan 2016 19:02:28 -0800 (PST) MIME-Version: 1.0 References: <20160119094331.7895.68438.idtracker@ietfa.amsl.com> <047501d1529f$7c7b7b40$757271c0$@nri.co.jp> In-Reply-To: <047501d1529f$7c7b7b40$757271c0$@nri.co.jp> From: Nat Sakimura Date: Wed, 20 Jan 2016 03:02:19 +0000 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=001a114a7c9c65996d0529bb37fb Archived-At: Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 03:02:32 -0000 --001a114a7c9c65996d0529bb37fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable And, here is the list of remaining issues that needs discussion. #9: Section 3 - parameter name conflict with Proof-of-Posession. ... the Authorization Request Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience) as members ...' However, that will produce a parameter name conflict with the "aud" parameter from OAuth 2.0 Proof-of-Possession: Authorization Server to Client Key Distribution. Seems like draft-ietf-oauth-pop-key-distribution will need to change its parameter name (aud in JWT is pretty well established). And shouldn't draft-ietf-oauth-jwsreq register some of the JWT's Registered Claim Names (at least iss and aud but maybe exp and others) as authorization request OAuth parameters? (Brian Campbell) Need to settle on what is to be done before making changes. #8: Section 3, it is unclear whether the Request Object can be a JWE only or if a JWS is always used (Brian Campbell) I think we wanted always do JWS and then JWE, but I am not sure. Please discuss. #7: Section 8, second paragraph: Delete the security considerations paragraph about not using "alg":"none". Section 8, second paragraph: Delete the security considerations paragraph about not using "alg":"none". Using an Unsecured JWS is no worse than sending the parameters the usual way. (Mike Jones) Propose Reject. It is no worse, but it is better to sign. Thus, it is using "SHOULD" but not "MUST". 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 18:55 Nat Sakimura : > Hi. > > Took much longer than I anticipated but I finally applied the comments I > received during the WGLC. > > When broken down, there were 44 comments that needed to be dealt with. > > I have accepted most of them. There are a few discussion points, and a fe= w > rejects. > > I am now making the list of those, but as I am going into a meeting now, = it > will not be available before tomorrow. > > For a preview, you can go and see them in > https://bitbucket.org/Nat/oauth-jwsreq/issues?status=3Dnew&status=3Dopen. > There > are two sets of comments provided by Mike and Brian as of the time of thi= s > writing. They have unresolved comments. I have recorded my dispositions > there so if you are so inclined, please have a look. > > I will pull out those points as separate issues in the tracker so that th= ey > can be individually tracked. > > Cheers, > > Nat Sakimura > > -- > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Tuesday, January 19, 2016 6:44 PM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-07.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Web Authorization Protocol Working Grou= p > of the IETF. > > Title : OAuth 2.0 JWT Authorization Request > Authors : Nat Sakimura > John Bradley > Filename : draft-ietf-oauth-jwsreq-07.txt > Pages : 16 > Date : 2016-01-19 > > Abstract: > The authorization request in OAuth 2.0 [RFC6749] utilizes query > parameter serialization, which means that parameters are encoded in > the URI of the request. This document introduces the ability to send > request parameters in form of a JSON Web Token (JWT) instead, which > allows the request to be signed and encrypted. using JWT > serialization. The request is 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-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 > --001a114a7c9c65996d0529bb37fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And, here is the list of remaining issues that needs discu= ssion. =C2=A0

... the Authori= zation Request Object SHOULD contain the Claims "iss" (issuer) an= d "aud" (audience) as members ...'

However, that will produce a parameter name conflict with the = "aud" parameter from OAuth 2.0 Proof-of-Possession: Authorization= Server to Client Key Distribution.

Seems like draft-ietf-oauth-pop-key-distribution will need to ch= ange its parameter name (aud in JWT is pretty well established). And should= n't draft-ietf-oauth-jwsreq register some of the JWT's Registered C= laim Names (at least iss and aud but maybe exp and others) as authorization= request OAuth parameters?
(Brian Campbell)


Need to settl= e on what is to be done before making changes.=C2=A0

#8: Section 3, it is unclear whether the Request Object can be a JWE only = or if a JWS is always used

(Brian Campbell)=C2= =A0

I think we wanted always do JWS and then JWE, = but I am not sure. Please discuss.=C2=A0


Section 8, second paragraph: Delete the security considerations= paragraph about not using "alg":"none". Using an Unsec= ured JWS is no worse than sending the parameters the usual way.

(Mi= ke Jones)

Propose Reject. It is no worse, but it is better to = sign. Thus, it is using "SHOULD" but not "MUST".=C2=A0<= /p>




2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 18:55 Nat S= akimura <n-sakimura@nri.co.jp>:
Hi.

Took much longer than I anticipated but I finally applied the comments I received during the WGLC.

When broken down, there were 44 comments that needed to be dealt with.

I have accepted most of them. There are a few discussion points, and a few<= br> rejects.

I am now making the list of those, but as I am going into a meeting now, it=
will not be available before tomorrow.

For a preview, you can go and see them in
https://bitbucket.org/Na= t/oauth-jwsreq/issues?status=3Dnew&status=3Dopen. There
are two sets of comments provided by Mike and Brian as of the time of this<= br> writing. They have unresolved comments. I have recorded my dispositions
there so if you are so inclined, please have a look.

I will pull out those points as separate issues in the tracker so that they=
can be individually tracked.

Cheers,

Nat Sakimura

--
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=C2=A0 and delete this e-mail.


-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of
internet-draf= ts@ietf.org
Sent: Tuesday, January 19, 2016 6:44 PM
To: i-d-announce= @ietf.org
Cc: oauth@ietf.org<= br> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-07.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
=C2=A0This draft is a work item of the Web Authorization Protocol Working G= roup
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 JWT Authorization Request
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=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-jwsreq-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 16
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-01-19

Abstract:
=C2=A0 =C2=A0The authorization request in OAuth 2.0 [RFC6749] utilizes quer= y
=C2=A0 =C2=A0parameter serialization, which means that parameters are encod= ed in
=C2=A0 =C2=A0the URI of the request.=C2=A0 This document introduces the abi= lity to send
=C2=A0 =C2=A0request parameters in form of a JSON Web Token (JWT) instead, = which
=C2=A0 =C2=A0allows the request to be signed and encrypted.=C2=A0 using JWT=
=C2=A0 =C2=A0serialization.=C2=A0 The request is sent by value or by refere= nce.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-oauth-jwsreq/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-oauth-j= wsreq-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddr= aft-ietf-oauth-jwsreq-07


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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a114a7c9c65996d0529bb37fb-- From nobody Tue Jan 19 19:05:20 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016241A037A for ; Tue, 19 Jan 2016 19:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrKBJbBzW-jm for ; Tue, 19 Jan 2016 19:05:17 -0800 (PST) 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 57A3B1A036E for ; Tue, 19 Jan 2016 19:05:17 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id s5so49557758qkd.0 for ; Tue, 19 Jan 2016 19:05:17 -0800 (PST) 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 :content-type; bh=BlkM6x17jEhuvzZ7vEBJQ6GxROcqB3SQ5xWq+D2ObRs=; b=RDx6CHCT8KIaOzNikM4MQhLideVyk7rAJ+2ndz90X57HbEgZkr1x7RSoQ4zQJ7qbtT WZmowmcO1em/FFUQ+H9HA3KHQy7y8fGagAA590uwKdYNRolGoXZqSSexg1AfBiJX688J gl+IdHlWmu+GIlivMUMudIp8QMxkfd1yZhIhe11v0nfTzzY9GmW14KjhEuGdBZfHbZqf NDGI3nlZRq4rpbuPOqESeawUILpruUVTu4JxILVYT7sorBRbVEKL6sFG1gnVYMmyColR Yk6modujf4zssb+bS79ehviuW8RsphobQkpDBxZSnfXIyg1xX0akcf3x52hVWMiJDsKt PZYg== 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:content-type; bh=BlkM6x17jEhuvzZ7vEBJQ6GxROcqB3SQ5xWq+D2ObRs=; b=lzac5BPaUhE4BkSss9ah5Qk4AS7N5KXU0pIBaMfItB6bYeej5oMP/5wqEzE5agqaCe 7JhxsvJOd7iMbu4Olf/iKtt6DmEp9eFkvYCCd6HzqvkbN4vaQh66iD1F227vyMPGUnje Wagdg+WSOYGtOMRo70bpVzoWcq+tPrK4dy/b6YD0LCGnuuWwBPIKQgjomAfxA8DpTYk6 M2sUu73Miz0CRavY8x/VHMszz9RvkXVbeetp0SqcqmKex0afcZGIEHalN4ztdHi9oS7N wwXuKhkWCCngggyjkpCl1YMr/6X2kP7u1eO2pk7k6e/j71zvmS/7uMMOHj7PePXFiNOf RjlQ== X-Gm-Message-State: ALoCoQnRukpvKzzNv/8jIVv04zrurzqe6cfImeooivc9LZFzqrDpCoC+V2lv0kCMYqzJMVc9hmqPbEa8/LbvyqU9akuoYxaliA== X-Received: by 10.55.71.135 with SMTP id u129mr43354533qka.26.1453259116402; Tue, 19 Jan 2016 19:05:16 -0800 (PST) MIME-Version: 1.0 References: <569E2076.2090405@gmx.net> In-Reply-To: <569E2076.2090405@gmx.net> From: Nat Sakimura Date: Wed, 20 Jan 2016 03:05:07 +0000 Message-ID: To: Hannes Tschofenig , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a114a7d20665f250529bb41e6 Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 03:05:19 -0000 --001a114a7d20665f250529bb41e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Hannes. I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, wh= ich was discussed in Yokohama, and was largely in agreement if my recollection is correct. Why is it not in the call for adoption? 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig : > Hi all, > > we have submitted our new charter to the IESG (see > http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and > since some IESG members like to see an updated list of milestones as > well. For this reason, based on a suggestion from Barry, we are also > starting a call for adoption concurrently with the review of the charter > text by the IESG. > > We will post separate mails on the individual documents. Your feedback > is important! Please take the time to look at the documents and provide > your feedback. > > Ciao > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a114a7d20665f250529bb41e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Hannes.=C2=A0

I did not find=C2= =A0htt= ps://tools.ietf.org/html/draft-sakimura-oauth-meta-05,=C2=A0which was d= iscussed in Yokohama, and was largely in agreement if my recollection is co= rrect. Why is it not in the call for adoption?=C2=A0



2016=E5= =B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:
Hi all,

we have submitted our new charter to the IESG (see
http://www.ietf.org/mail-archive/web= /oauth/current/msg15379.html) and
since some IESG members like to see an updated list of milestones as
well. For this reason, based on a suggestion from Barry, we are also
starting a call for adoption concurrently with the review of the charter text by the IESG.

We will post separate mails on the individual documents. Your feedback
is important! Please take the time to look at the documents and provide
your feedback.

Ciao
Hannes & Derek

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a114a7d20665f250529bb41e6-- From nobody Tue Jan 19 19:30:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769BC1A064C for ; Tue, 19 Jan 2016 19:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHUT2pNBXExa for ; Tue, 19 Jan 2016 19:30:12 -0800 (PST) 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 208221A1A30 for ; Tue, 19 Jan 2016 19:30:12 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id o6so31727117qkc.2 for ; Tue, 19 Jan 2016 19:30:12 -0800 (PST) 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 :content-type; bh=/PJPAnVFG2pWmhYEdWg6D79X/691Aq5/2mgHApIECYQ=; b=lqIIcJ3n+vAZugCYtvj/SZ1zk5vxtmx/TId6Eo8GRCJdw796LkPJ/etCaykpRWyo2U NpJJYeXyB0BzQAZKAmxvsgf/mKNKaB/dVU4yZU4DXBrQyE/xX8Gt8Ay058hJCF65oJ7s GYI1v6R9qIGOBrFf99Lf0WAKJGpM6gZCUzUD5K2SMAsL7J5JoSVxJJ59YBnC6ECbc4Ez hFqvuglcbg+Cvw/9/d1Lu4ZMF3TRedR2BEOprrIo7L74s/wglM9h9p7Pjalu1szkisJy YHaTQRpXgXqx1LkoJ2QMaIk3Y8N3YgbJGqhY6CX5DqVbfy+oWuPNXyAlw5tLXq2Uhe8w 6flw== 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:content-type; bh=/PJPAnVFG2pWmhYEdWg6D79X/691Aq5/2mgHApIECYQ=; b=jZl9Sruf+e5DJqfWRzbbw9fTsPJ6gFIs2b3W30PKs+/71X0gcyv4WqU7wom6lmQK3U LS0h2PjKuP+rOL+BQ+DL3y714X4krortQi/NpUNkRvWCgYRkGJUKaoja/shv89mOdkSe sAboL/JIlAAJNJPfpQIQPREqe5X7q38/J7UPKcFgaZ0vhyi61n9zB7pmo0fSVnkvMWL2 ZIuPBWFapirIzvklHh8Eyr2MSStOLf+Tl9GylWe059JKsmRsZPpJBt3EF2MMOi3lXkyR RlgGA+i59rkTgXy3mbPpWDOnzntxlB40o0FCO1ulTwVbuoRqYz8IiOkqY7PepK9F3WPA 7KVg== X-Gm-Message-State: ALoCoQnecTNp63cdxJahsr4W5gW7GnwhPv4XYAdo7qGAQB+8iUTqC9BAJvvk2sKxMDKne/nNbT/bKFxtp61FtQU2kuANfHdBNw== X-Received: by 10.55.20.211 with SMTP id 80mr42207761qku.67.1453260611223; Tue, 19 Jan 2016 19:30:11 -0800 (PST) MIME-Version: 1.0 References: <569E2076.2090405@gmx.net> In-Reply-To: From: Nat Sakimura Date: Wed, 20 Jan 2016 03:30:01 +0000 Message-ID: To: Hannes Tschofenig , "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a114495467f87b60529bb9ab7 Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 03:30:14 -0000 --001a114495467f87b60529bb9ab7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just to give more context, at IETF 94, I have done a presentation on discovery. According to the minutes, (f) Discovery (Nat) Nat explains his document as an example of the work that has to be done in the area of discovery, which is a topic that has been ident= ified as necessary for interoperability since many years but so far = there was not time to work on it. Mike, John and Nat are working on = a new document that describes additional discovery-relevant componen= ts. Poll: 19 for / zero against / 4 persons need more information. The document discussed there was https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a simple (only 1-page!) but a very powerful document that nudges towards HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-up attack without introducing the concept of issuer which is not in RFC6749. It is also good for selecting different endpoints depending on the user authentication and authorization results and more privacy sensitive than pre-announced Discovery document. It also allows you to find to which protected resource endpoint you can use the access token against. In the last sentence of the minutes, it talks about "a new document that describes additional discovery-relevant components". This is https://tools.ietf.org/html/draft-jones-oauth-discovery-00. It went for the call for adoption. However, it is only a half of the story. I believe https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was discussed at IETF 94 and had support there should be adopted as well. Nat Sakimura 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura : > Thanks Hannes. > > I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, = which > was discussed in Yokohama, and was largely in agreement if my recollectio= n > is correct. Why is it not in the call for adoption? > > > > 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig : > >> Hi all, >> >> we have submitted our new charter to the IESG (see >> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and >> since some IESG members like to see an updated list of milestones as >> well. For this reason, based on a suggestion from Barry, we are also >> starting a call for adoption concurrently with the review of the charter >> text by the IESG. >> >> We will post separate mails on the individual documents. Your feedback >> is important! Please take the time to look at the documents and provide >> your feedback. >> >> Ciao >> Hannes & Derek >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --001a114495467f87b60529bb9ab7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to give more context, at IETF 94, I have done a prese= ntation on discovery.=C2=A0

According to the minutes,=C2= =A0

    (f) Discovery (Nat=
)
         =20
             Nat explains his document as an example of the work that has t=
o be done
             in the area of discovery, which is a topic that has been ident=
ified
             as necessary for interoperability since many years but so far =
there
             was not time to work on it. Mike, John and Nat are working on =
a new
             document that describes additional discovery-relevant componen=
ts.
         =20
             Poll: 19 for / zero against / 4 persons need more information.=

The document discussed = there was https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a= simple (only 1-page!) but a very powerful document that nudges towards HAT= EOAS which is at the core of RESTful-ness. It also mitigates the Mix-up att= ack without introducing the concept of issuer which is not in RFC6749. It i= s also good for selecting different endpoints depending on the user authent= ication and authorization results and more privacy sensitive than pre-annou= nced Discovery document. It also allows you to find to which protected reso= urce endpoint you can use the access token against.=C2=A0

In the last sentence of the minutes, it talks about "a new document= that describes additional discovery-relevant components". This is=C2= =A0https://tools.ietf.org/html/draft-jones-oauth-disc= overy-00.=C2=A0 It went for the call fo= r adoption. However, it is only a half of the story. I believe=C2=A0= https://tools.ietf.org/html/draft-sakimura-oauth-meta-05=C2=A0that was discussed at IETF 94 and had support there=C2=A0should be = adopted as well.=C2=A0

Nat Sakimura




2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimu= ra <sakimura@gmail.com>:
Thanks Hannes.=C2=A0=

I did not find=C2=A0https://tools.ietf.org/= html/draft-sakimura-oauth-meta-05,=C2=A0which was discussed in Yokohama= , and was largely in agreement if my recollection is correct. Why is it not= in the call for adoption?=C2=A0


<= br>
2016=E5=B9=B41=E6=9C=8819=E6= =97=A5(=E7=81=AB) 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:
Hi all,<= br>
we have submitted our new charter to the IESG (see
http://www.ietf.org/mail-archive/web= /oauth/current/msg15379.html) and
since some IESG members like to see an updated list of milestones as
well. For this reason, based on a suggestion from Barry, we are also
starting a call for adoption concurrently with the review of the charter text by the IESG.

We will post separate mails on the individual documents. Your feedback
is important! Please take the time to look at the documents and provide
your feedback.

Ciao
Hannes & Derek

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a114495467f87b60529bb9ab7-- From nobody Tue Jan 19 20:37:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C081C1A1B84 for ; Tue, 19 Jan 2016 20:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJGbIUw4dV17 for ; Tue, 19 Jan 2016 20:37:40 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id A3ACC1A1B6A for ; Tue, 19 Jan 2016 20:37:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,319,1449493200"; d="scan'208";a="142839992" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 20 Jan 2016 15:37:35 +1100 X-IronPort-AV: E=McAfee;i="5700,7163,8049"; a="65744862" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcavi.tcif.telstra.com.au with ESMTP; 20 Jan 2016 15:37:35 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([2002:ac31:2854::ac31:2854]) with mapi; Wed, 20 Jan 2016 15:37:34 +1100 From: "Manger, James" To: Hannes Tschofenig , "oauth@ietf.org" Date: Wed, 20 Jan 2016 15:37:33 +1100 Thread-Topic: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values Thread-Index: AdFSr11PUssgD816QTiFUWwupJG0PQAhiH1g Message-ID: <255B9BB34FB7D647A506DC292726F6E13BB6958F55@WSMSG3153V.srv.dir.telstra.com> References: <569E2276.5070407@gmx.net> In-Reply-To: <569E2276.5070407@gmx.net> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 04:37:41 -0000 QWNjZXB0aW5nIGRyYWZ0LWpvbmVzLW9hdXRoLWFtci12YWx1ZXMtMDMgaXMgYWxtb3N0IG9rYXkg YXMgYSBzdGFydGluZyBwb2ludCBmb3Igd29yay4NCkkgd291bGQgbGlrZSB0byBzZWUgc2lnbmlm aWNhbnQgY2hhbmdlcyB0aG91Z2g6DQoNCiogVGhlICJhbXJfdmFsdWVzIiBwYXJhbWV0ZXIgc2hv dWxkIGJlIGRyb3BwZWQ7IGl0IGp1c3QgZW5jb3VyYWdlcyBicml0dGxlIGRlc2lnbnMgYXMgc2Vj dGlvbiA0ICJyZWxhdGlvbnNoaXAgdG8gYWNyIiBhbmQgc2VjdGlvbiA2ICJzZWN1cml0eSBjb25z aWRlcmF0aW9ucyIgYWxyZWFkeSB3YXJuIGFib3V0LiBUaGVyZSBpcyBubyBuZWVkIHRvIGVuYWJs ZSB0aGF0IGJyaXR0bGVuZXNzLiBJZiBzb21lb25lIHJlYWxseSB3YW50cyB0aGlzIGZ1bmN0aW9u YWxpdHkgdGhleSBjb3VsZCBwdXQgYW4gYW1yIHZhbHVlIGluIHRoZSAiYWNyX3ZhbHVlcyIgZmll bGQgYXMgYSBoYWNrLg0KDQoqIFRoZSBtb2RlbCBmb3IgYW1yX3ZhbHVlcyBpcyB3cm9uZyBhcyB3 ZWxsLiBGb3IgZXhhbXBsZSwgImFtciI6WyJwd2QiLCJvdHAiXSBjb3VsZCBiZSBhIGNvbW1vbiBy ZXNwb25zZSB0aGF0IHlvdSB3YW50LCBidXQgeW91IGNhbm5vdCBhc2sgZm9yIHRoYXQgd2l0aCBh bXJfdmFsdWVzIHNpbmNlIGFtcl92YWx1ZXM9InB3ZCBvdHAiIGFjdHVhbGx5IG1lYW5zIGp1c3Qg InB3ZCIsIG9yIGp1c3QgIm90cCIgaXMgb2theSAoYW5kIGp1c3QgInB3ZCIgaXMgeW91ciBwcmVm ZXJlbmNlKS4NCg0KKiBSZWdpc3RlcmluZyB2YWx1ZXMgb24gYSAiU3BlY2lmaWNhdGlvbiBSZXF1 aXJlZCIgYmFzaXMgaXMgb3Zlci10aGUtdG9wLiBUaGlzIGRvYyByZWdpc3RlcnMgOCBhbXIgdmFs dWVzIHdpdGgganVzdCBhIGZldyB3b3JkcyBhcyBlYWNoIHZhbHVlJ3MgInNwZWNpZmljYXRpb24i IChlZyAiZXllIjogcmV0aW5hIHNjYW4gYmlvbWV0cmljKS4gRWFjaCBvZiB0aGUgb3RoZXIgNyBh bXIgdmFsdWVzIGFyZSAic3BlY2lmaWVkIiBpbiBhIGZldyBsaW5lcyB3aXRoIGEgcmVmZXJlbmNl IChvciB0d28pLiBBICJGaXJzdCBDb21lIEZpcnN0IFNlcnZlZCIgYmFzaXMgaXMgcHJvYmFibHkg c3VmZmljaWVudCwgd2l0aCB0aGUgInNwZWNpZmljYXRpb24iIGp1c3QgdGhlIGRlc2NyaXB0aW9u IGluIHRoZSByZWdpc3RyeSAodGhhdCBjYW4gaW5jbHVkZSByZWZlcmVuY2VzKS4NCg0KLS0NCkph bWVzIE1hbmdlcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBb bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9m ZW5pZw0KU2VudDogVHVlc2RheSwgMTkgSmFudWFyeSAyMDE2IDEwOjQ4IFBNDQpUbzogb2F1dGhA aWV0Zi5vcmcNClN1YmplY3Q6IFtPQVVUSC1XR10gQ2FsbCBmb3IgQWRvcHRpb246IEF1dGhlbnRp Y2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgVmFsdWVzDQoNCkhpIGFsbCwNCg0KdGhpcyBpcyB0aGUg Y2FsbCBmb3IgYWRvcHRpb24gb2YgQXV0aGVudGljYXRpb24gTWV0aG9kIFJlZmVyZW5jZSBWYWx1 ZXMsIHNlZQ0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLWFt ci12YWx1ZXMtMDMNCg0KUGxlYXNlIGxldCB1cyBrbm93IGJ5IEZlYiAybmQgd2hldGhlciB5b3Ug YWNjZXB0IC8gb2JqZWN0IHRvIHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGFzIGEgc3Rh cnRpbmcgcG9pbnQgZm9yIHdvcmsgaW4gdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAuDQoNCk5vdGU6 IFRoZSBmZWVkYmFjayBkdXJpbmcgdGhlIFlva29oYW1hIG1lZXRpbmcgd2FzIGluY29uY2x1c2l2 ZSwgbmFtZWx5DQo5IGZvciAvIHplcm8gYWdhaW5zdCAvIDYgcGVyc29ucyBuZWVkIG1vcmUgaW5m b3JtYXRpb24uDQoNCllvdSBmZWVkYmFjayB3aWxsIHRoZXJlZm9yZSBiZSBpbXBvcnRhbnQgdG8g ZmluZCBvdXQgd2hldGhlciB3ZSBzaG91bGQgZG8gdGhpcyB3b3JrIGluIHRoZSBPQXV0aCB3b3Jr aW5nIGdyb3VwLg0KDQpDaWFvDQpIYW5uZXMgJiBEZXJlaw0KDQo= From nobody Tue Jan 19 21:19:35 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53231A21A9 for ; Tue, 19 Jan 2016 21:19:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.608 X-Spam-Level: X-Spam-Status: No, score=0.608 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1hKB212Rkcf for ; Tue, 19 Jan 2016 21:19:31 -0800 (PST) Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2521A21A8 for ; Tue, 19 Jan 2016 21:19:31 -0800 (PST) Received: from nriea05.index.or.jp (unknown [172.19.246.40]) by nrifs04.index.or.jp (Postfix) with SMTP id 01831472EDF; Wed, 20 Jan 2016 14:19:31 +0900 (JST) Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea05.index.or.jp (unknown) with ESMTP id u0K5JUwc013928; Wed, 20 Jan 2016 14:19:30 +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 u0K5JUu3043980; Wed, 20 Jan 2016 14:19:30 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u0K5JUGA043979; Wed, 20 Jan 2016 14:19:30 +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 u0K5JUSu043976; Wed, 20 Jan 2016 14:19:30 +0900 From: "Nat Sakimura" To: "'Kepeng Li'" , "'Hannes Tschofenig'" , References: <569E21DA.30002@gmx.net> In-Reply-To: Date: Wed, 20 Jan 2016 14:19:41 +0900 Message-ID: <060901d15342$2a5c1600$7f144200$@nri.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 thread-index: AQGxnaNyUw5Ns5n+891YCYVGabIsJAHI1+PunzUCByA= Content-Language: ja X-MailAdviser: 20141126 Archived-At: Subject: Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 05:19:33 -0000 Yes from me as well. It could be harmonized better with other PoP proposals, but the simplicity appeal of this approach is worth considering. -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. -----Original Message----- From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Kepeng Li Sent: Wednesday, January 20, 2016 12:22 AM To: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps > * to make a decision about other extensions. Nat and Kepeng submitted > the Sender Constrained JWT for OAuth2 2.0 document, see > https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06 > We asked the working group for feedback during IETF #93 and we > couldn't get enough feedback at that time. Please give us feedback > whether you are interested in exploring that solution direction as > part of this process. Today, we don't have enough indication of > interest for working on that solution direction. Yes, I am interested in this solution direction. Sender Constrained JWT is already indicated in PoP architecture document as one of the solutions. If we don$B!G(Bt specify it in detail, the solution set is incomplete. And there will be interoperability issues when people implement it in different ways. Kind Regards Kepeng $B:_(B 19/1/16 7:45 pm$B!$(B "Hannes Tschofenig" $BHi all, > >I wanted to drop a high level message about possible next steps for the >PoP work. > >As you have seen from my status update, see >http://www.ietf.org/mail-archive/web/oauth/current/msg15327.html, the >PoP architecture document was already in IESG processing but I have had >asked Kathleen to delay the publication given that we ran into scoping >issues, as discussed on the list. See >http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html > >The change of scope related to desire to not just binding a key to the >access token but also to other parts of the OAuth system to avoid cases >where an attacker can just obtain attack other parts of the system >instead (for example, by obtaining an bearer-based refresh token to >then obtain a new PoP access token). > >The recently discovered security problems tell us that we need to >simplify our solutions a bit as well to ensure that we get the security >analysed properly. More options means more time to analyse all the >different options. > >What does this mean to simplify when I talk about expanding the scope >in the earlier paragraph? > >I am suggesting to > >* to consider focusing on a public key-based only solution for the >web/smart phone app space. (The ACE working group will have to develop >a symmetric key-based version on their own, if desired.) > >* to extend the support of PoP token functionality throughout the >entire solution. This means that we have to include support for a >asymmetric version of PKCE into account (which had been discussed in >the group already earlier already). > >* to define at least a TLS-based security security solution for the >communication between the client and the resource server. > >* to rethink the work on the application layer security solution. The >HTTP signing draft, which defines the application layer security >solution for use between the client and the resource server, has >expired and we will have to find new authors. I believe we got stuck a bit. >Luckily new persons came along and volunteered to help, namely Fredrik >Ljunggren and Jakob Schlyter. Nevertheless, the group will have to >judge whether a newly developed application layer security solution is >promising. My impression is that it is a very difficult to come up with >a solution that satisfies the security requirements and, at the same >time, also takes the deployment status of proxies and other middleware >into account. > >* to make a decision about other extensions. Nat and Kepeng submitted >the Sender Constrained JWT for OAuth2 2.0 document, see >https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06 >We asked the working group for feedback during IETF #93 and we couldn't >get enough feedback at that time. Please give us feedback whether you >are interested in exploring that solution direction as part of this >process. Today, we don't have enough indication of interest for working >on that solution direction. > >Before making any changes to the PoP document set we would like to hear >your thoughts. > >Ciao >Hannes > >_______________________________________________ >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 Jan 19 21:21:08 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F641A21B3 for ; Tue, 19 Jan 2016 21:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgcaIkJiY7Qo for ; Tue, 19 Jan 2016 21:21:05 -0800 (PST) Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5AD1A21B1 for ; Tue, 19 Jan 2016 21:21:04 -0800 (PST) Received: from nriea02.index.or.jp (unknown [172.19.246.37]) by nrifs04.index.or.jp (Postfix) with SMTP id 52809472EDF; Wed, 20 Jan 2016 14:21:04 +0900 (JST) Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea02.index.or.jp (unknown) with ESMTP id u0K5L3M1016240; Wed, 20 Jan 2016 14:21:04 +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 u0K5L3pS001246; Wed, 20 Jan 2016 14:21:03 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u0K5L3Cn001245; Wed, 20 Jan 2016 14:21:03 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u0K5L3Wt001242; Wed, 20 Jan 2016 14:21:03 +0900 From: "Nat Sakimura" To: "'Justin Richer'" , "'Hannes Tschofenig'" References: <569E21DA.30002@gmx.net> <840D6473-8F4D-4843-9CFB-97E4AA1AC8CB@mit.edu> In-Reply-To: <840D6473-8F4D-4843-9CFB-97E4AA1AC8CB@mit.edu> Date: Wed, 20 Jan 2016 14:21:14 +0900 Message-ID: <060a01d15342$62231bb0$26695310$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_060B_01D1538D.D20D34B0" X-Mailer: Microsoft Outlook 15.0 thread-index: AQGxnaNyUw5Ns5n+891YCYVGabIsJAJS3kDknzCyINA= Content-Language: ja X-MailAdviser: 20141126 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 05:21:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_060B_01D1538D.D20D34B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Right. This came as a surprise to me as well.=20 Agreed that we need to get more input from HTTP2.0 community etc. but I = did not have any impression that Justin has resigned from the editor = especially after having seen his presentation in Yokohama.=20 =20 Nat Sakimura =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 Justin Richer Sent: Wednesday, January 20, 2016 1:34 AM To: Hannes Tschofenig Cc: Subject: Re: [OAUTH-WG] Proof of Possession Tokens: Next Steps =20 Well that=E2=80=99s interesting: I was unaware I was being removed as = the author of the HTTP signing draft. This is especially surprising = after the presentation I gave at Yokohama about this topic. The draft = hasn=E2=80=99t been updated because there=E2=80=99s not really been any = discussion on it here in the group to drive an update, and I=E2=80=99m = not one to artificially publish a new draft with the same content and a = new date just to avoid the =E2=80=9Cexpired=E2=80=9D tag in the = repository.=20 =20 To see the direction I proposed that we go in at Yokohama, check my = slides here: =20 https://www.ietf.org/proceedings/94/slides/slides-94-oauth-3.pdf =20 Again, I got no real feedback on this and there was no discussion on the = list. Even so, I=E2=80=99m implementing this in a Node.js application = anyway that I plan to post back to the group here when it=E2=80=99s = done.=20 =20 =E2=80=94 Justin =20 On Jan 19, 2016, at 6:45 AM, Hannes Tschofenig = > wrote: =20 Hi all, I wanted to drop a high level message about possible next steps for the PoP work. As you have seen from my status update, see http://www.ietf.org/mail-archive/web/oauth/current/msg15327.html, the PoP architecture document was already in IESG processing but I have had asked Kathleen to delay the publication given that we ran into scoping issues, as discussed on the list. See http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html The change of scope related to desire to not just binding a key to the access token but also to other parts of the OAuth system to avoid cases where an attacker can just obtain attack other parts of the system instead (for example, by obtaining an bearer-based refresh token to then obtain a new PoP access token). The recently discovered security problems tell us that we need to simplify our solutions a bit as well to ensure that we get the security analysed properly. More options means more time to analyse all the different options. What does this mean to simplify when I talk about expanding the scope in the earlier paragraph? I am suggesting to * to consider focusing on a public key-based only solution for the web/smart phone app space. (The ACE working group will have to develop a symmetric key-based version on their own, if desired.) * to extend the support of PoP token functionality throughout the entire solution. This means that we have to include support for a asymmetric version of PKCE into account (which had been discussed in the group already earlier already). * to define at least a TLS-based security security solution for the communication between the client and the resource server. * to rethink the work on the application layer security solution. The HTTP signing draft, which defines the application layer security solution for use between the client and the resource server, has expired and we will have to find new authors. I believe we got stuck a bit. Luckily new persons came along and volunteered to help, namely Fredrik Ljunggren and Jakob Schlyter. Nevertheless, the group will have to judge whether a newly developed application layer security solution is promising. My impression is that it is a very difficult to come up with a solution that satisfies the security requirements and, at the same time, also takes the deployment status of proxies and other middleware into account. * to make a decision about other extensions. Nat and Kepeng submitted the Sender Constrained JWT for OAuth2 2.0 document, see https://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06 We asked the working group for feedback during IETF #93 and we couldn't get enough feedback at that time. Please give us feedback whether you are interested in exploring that solution direction as part of this process. Today, we don't have enough indication of interest for working on that solution direction. Before making any changes to the PoP document set we would like to hear your thoughts. Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org =20 https://www.ietf.org/mailman/listinfo/oauth =20 ------=_NextPart_000_060B_01D1538D.D20D34B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

R= ight. This came as a surprise to me as well. =

A= greed that we need to get more input from HTTP2.0 community etc. but I = did not have any impression that Justin has resigned from the editor = especially after having seen his presentation in Yokohama. =

<= o:p> 

N= at Sakimura

<= 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=C2=A0 and delete this e-mail.

<= o:p> 

From:<= /b> OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of Justin = Richer
Sent: Wednesday, January 20, 2016 1:34 AM
To: = Hannes Tschofenig
Cc: = <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Proof of = Possession Tokens: Next Steps

 

Well that=E2=80=99s interesting: I = was unaware I was being removed as the author of the HTTP signing draft. = This is especially surprising after the presentation I gave at Yokohama = about this topic. The draft hasn=E2=80=99t been updated because = there=E2=80=99s not really been any discussion on it here in the group = to drive an update, and I=E2=80=99m not one to artificially publish a = new draft with the same content and a new date just to avoid the = =E2=80=9Cexpired=E2=80=9D tag in the = repository. 

 

To see the direction I proposed = that we go in at Yokohama, check my slides = here:

 

 

Again, I got no real feedback on = this and there was no discussion on the list. Even so, I=E2=80=99m = implementing this in a Node.js application anyway that I plan to post = back to the group here when it=E2=80=99s = done. 

 

 =E2=80=94 = Justin

 

On Jan 19, 2016, at 6:45 AM, Hannes = Tschofenig <hannes.tschofenig@gmx.net&g= t; wrote:

 

Hi all,

I wanted to drop a high level message about = possible next steps for the
PoP work.

As you have seen from my = status update, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15327.html, = the
PoP architecture document was already in IESG processing but I = have had
asked Kathleen to delay the publication given that we ran = into scoping
issues, as discussed on the list. See
http://www.ietf.org/mail-archive/web/oauth/current/msg15177.html
=
The change of scope related to desire to not just binding a key to = the
access token but also to other parts of the OAuth system to avoid = cases
where an attacker can just obtain attack other parts of the = system
instead (for example, by obtaining an bearer-based refresh = token to then
obtain a new PoP access token).

The recently = discovered security problems tell us that we need to
simplify our = solutions a bit as well to ensure that we get the security
analysed = properly. More options means more time to analyse all the
different = options.

What does this mean to simplify when I talk about = expanding the scope in
the earlier paragraph?

I am suggesting = to

* to consider focusing on a public key-based only solution for = the
web/smart phone app space. (The ACE working group will have to = develop a
symmetric key-based version on their own, if = desired.)

* to extend the support of PoP token functionality = throughout the entire
solution. This means that we have to include = support for a asymmetric
version of PKCE into account (which had been = discussed in the group
already earlier already).

* to define = at least a TLS-based security security solution for the
communication = between the client and the resource server.

* to rethink the work = on the application layer security solution. The
HTTP signing draft, = which defines the application layer security
solution for use between = the client and the resource server, has expired
and we will have to = find new authors. I believe we got stuck a bit.
Luckily new persons = came along and volunteered to help, namely Fredrik
Ljunggren and = Jakob Schlyter. Nevertheless, the group will have to judge
whether a = newly developed application layer security solution is
promising. My = impression is that it is a very difficult to come up with
a solution = that satisfies the security requirements and, at the same
time, also = takes the deployment status of proxies and other middleware
into = account.

* to make a decision about other extensions. Nat and = Kepeng submitted
the Sender Constrained JWT for OAuth2 2.0 document, = see
htt= ps://tools.ietf.org/html/draft-sakimura-oauth-rjwtprof-06
We = asked the working group for feedback during IETF #93 and we = couldn't
get enough feedback at that time. Please give us feedback = whether you
are interested in exploring that solution direction as = part of this
process. Today, we don't have enough indication of = interest for working
on that solution direction.

Before making = any changes to the PoP document set we would like to hear
your = thoughts.

Ciao
Hannes

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

 

------=_NextPart_000_060B_01D1538D.D20D34B0-- From nobody Tue Jan 19 22:39:22 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD7F1A7022 for ; Tue, 19 Jan 2016 22:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOcW0Ec46pf8 for ; Tue, 19 Jan 2016 22:39:19 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 880F71A7021 for ; Tue, 19 Jan 2016 22:39:19 -0800 (PST) Received: by mail-ob0-x236.google.com with SMTP id ba1so619183138obb.3 for ; Tue, 19 Jan 2016 22:39:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZNSUulAzETlcykFUbm4WlQSGv7mRCs+Fr7c/VGQPsZ0=; b=eJnfOc2yDf1lvCDe8Ttuc0FWNQSnPk34x0OGqjkxOjoh20XOmHlnVNlKjel7GPM7Hc RD/xxkQvv7Z5YMPBlFg8/UqH6UcwKi+Kh7d8VtNbmoTw5MTf2VMWXcbl3Pa+U8uD8FO6 /djWiMldQZZsfjqsADWxW+MdeHP/exf8FtBvoUX8uO/jsFOSsZeXdqxZE96d/krSS4bF ufvKYktpN/il5/XRBOxMQLGrQpriyo7onLbvwneMjrQ6x1MQGRHRbpDPDmR2RJJn1rX0 RJ2masmbHu5MZKukZc9ySmRMUjfB1hZ8cV+EtiohGwwGiyQWeWh/C5SrSNvDOGYn88sJ FhOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZNSUulAzETlcykFUbm4WlQSGv7mRCs+Fr7c/VGQPsZ0=; b=RRNoqz4MtPEH6wV8CRlOEJpq7MOzb1FIhRkHHYiE8mECSY/P1+YQqKGARVV4JoKk4u Mhh2cjWL8oHC8pJZnopjvbsCAgW8XBL+QV+yCdtPk07FiaLXWQharUnRuWb3XOgyjqyk gfhYUrHPz+83G37VdtkgeW08ew0pLQZ8Y8bK1kuuUjkdlVoqDFRJutA/9VByuSd5o+m8 DHXH72KZ5ROawsfp5KUQgcxOgGgCAdvofM/jL50YzDtSWfzVP+XMS3w/IdaNw53Q+kAW 6eGcedQna+LxZ6z569UprYt2BJUC9Ct5hr7tqidBJqpGsU+dqZ16zOa2785N4IGhrvX4 J8+g== X-Gm-Message-State: ALoCoQnQZ+kWq692IlCtu46ka87e7xdRUerCS1eKaGlknCyiUQRi5Hwlyo/oOGZa7UF6vCctW75E40RyNAA0sNQPuM0NuY6q4jT9Dht1uAo79ZgFfzGbMEg= X-Received: by 10.182.114.167 with SMTP id jh7mr26377088obb.70.1453271958780; Tue, 19 Jan 2016 22:39:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Tue, 19 Jan 2016 22:38:59 -0800 (PST) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BB6958F55@WSMSG3153V.srv.dir.telstra.com> References: <569E2276.5070407@gmx.net> <255B9BB34FB7D647A506DC292726F6E13BB6958F55@WSMSG3153V.srv.dir.telstra.com> From: William Denniss Date: Wed, 20 Jan 2016 14:38:59 +0800 Message-ID: To: "Manger, James" Content-Type: multipart/alternative; boundary=001a11c2e2e6ddbf7f0529be3e47 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 06:39:21 -0000 --001a11c2e2e6ddbf7f0529be3e47 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 20, 2016 at 12:37 PM, Manger, James < James.H.Manger@team.telstra.com> wrote: > Accepting draft-jones-oauth-amr-values-03 is almost okay as a starting > point for work. > +1 for adoption. > I would like to see significant changes though: > > * The "amr_values" parameter should be dropped; it just encourages brittle > designs as section 4 "relationship to acr" and section 6 "security > considerations" already warn about. There is no need to enable that > brittleness. If someone really wants this functionality they could put an > amr value in the "acr_values" field as a hack. > I agree that it seems to encourage brittle designs. Why would the OP want to use "otp" when it has U2F on file for the same user, for example? But come to think of it, is any use of "amr" non-brittle? I guess the broader ones like "user", "rba", "mca" and "mfa" are a little more future-proof. I'm very keen to hear some concrete use-cases for this parameter. * The model for amr_values is wrong as well. For example, > "amr":["pwd","otp"] could be a common response that you want, but you > cannot ask for that with amr_values since amr_values="pwd otp" actually > means just "pwd", or just "otp" is okay (and just "pwd" is your preference). > > * Registering values on a "Specification Required" basis is over-the-top. > This doc registers 8 amr values with just a few words as each value's > "specification" (eg "eye": retina scan biometric). Each of the other 7 amr > values are "specified" in a few lines with a reference (or two). A "First > Come First Served" basis is probably sufficient, with the "specification" > just the description in the registry (that can include references). > I agree, "Specification Required" does seem like a high bar. > -- > James Manger > > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Tuesday, 19 January 2016 10:48 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Call for Adoption: Authentication Method Reference > Values > > Hi all, > > this is the call for adoption of Authentication Method Reference Values, > see > https://tools.ietf.org/html/draft-jones-oauth-amr-values-03 > > Please let us know by Feb 2nd whether you accept / object to the adoption > of this document as a starting point for work in the OAuth working group. > > Note: The feedback during the Yokohama meeting was inconclusive, namely > 9 for / zero against / 6 persons need more information. > > You feedback will therefore be important to find out whether we should do > this work in the OAuth working group. > > Ciao > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c2e2e6ddbf7f0529be3e47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jan 20, 2016 at 12:37 PM, Manger, James <James.H.Manger@team.telstra.com> wrote:
=
Accepting draft-jones-oauth-amr-values-03 is almost okay as a starting poi= nt for work.

+1 for adoption.
=C2=A0
I would like to see significant changes though:

* The "amr_values" parameter should be dropped; it just encourage= s brittle designs as section 4 "relationship to acr" and section = 6 "security considerations" already warn about. There is no need = to enable that brittleness. If someone really wants this functionality they= could put an amr value in the "acr_values" field as a hack.
<= /blockquote>

I agree that it seems to encourage brittle = designs. Why would the OP want to use "otp" when it has U2F on fi= le for the same user, for example? But come to think of it, is any use of &= quot;amr" non-brittle?=C2=A0 I guess the broader ones like "user&= quot;, "rba", "mca" and "mfa" are a little mo= re future-proof.

I'm very keen to hear some co= ncrete use-cases for this parameter.

* The model for amr_values is wrong as well. For example, "amr":[= "pwd","otp"] could be a common response that you want, = but you cannot ask for that with amr_values since amr_values=3D"pwd ot= p" actually means just "pwd", or just "otp" is oka= y (and just "pwd" is your preference).

* Registering values on a "Specification Required" basis is over-= the-top. This doc registers 8 amr values with just a few words as each valu= e's "specification" (eg "eye": retina scan biometri= c). Each of the other 7 amr values are "specified" in a few lines= with a reference (or two). A "First Come First Served" basis is = probably sufficient, with the "specification" just the descriptio= n in the registry (that can include references).

<= /div>
I agree, "Specification Required" does seem like a high= bar.


--
James Manger


-----Original Message-----
From: OAuth [mailto:oauth-bounces= @ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, 19 January 2016 10:48 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for Adoption: Authentication Method Reference Valu= es

Hi all,

this is the call for adoption of Authentication Method Reference Values, se= e
https://tools.ietf.org/html/draft-jones-o= auth-amr-values-03

Please let us know by Feb 2nd whether you accept / object to the adoption o= f this document as a starting point for work in the OAuth working group.
Note: The feedback during the Yokohama meeting was inconclusive, namely
9 for / zero against / 6 persons need more information.

You feedback will therefore be important to find out whether we should do t= his work in the OAuth working group.

Ciao
Hannes & Derek

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

--001a11c2e2e6ddbf7f0529be3e47-- From nobody Tue Jan 19 22:39:55 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15881A7030 for ; Tue, 19 Jan 2016 22:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjcLVFk9rl0P for ; Tue, 19 Jan 2016 22:39:53 -0800 (PST) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 C76BB1A702F for ; Tue, 19 Jan 2016 22:39:53 -0800 (PST) Received: by mail-ob0-x22a.google.com with SMTP id py5so239296638obc.2 for ; Tue, 19 Jan 2016 22:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=1k2qcAkAtHDfR0aJMrTCEPMAS7uQg6oG/ebI/uFBr/g=; b=hWfJHI8bHMGK8ewgDzBBxamJESMZ+RHJboLDbKtlAGgOQCSZijWt8ieDi/wCwZ7B3E Yhp1Yig9IQryNds6BVkcI+7SrbD9WMpkhsmMa6m81zxvcyiNpUsbgIXGpWtUbeNLNt/8 Y4ik9CtXxQzzwGQldRtskeUKMylqkR7oh/AdkG7Udoj4zEzQnureiHnZpcwC2QSM6ln6 saNp1iw/0BSf5MlW7RwHdU7/IiFjWhTItRcwb0nEQzGyaeEatjRR5sMq+co05cs8GtT4 B7z0mMQwZHGwWwZbVhcGtrUHyJvsIX8QrZttrpboN57ra0ynpACuy6H0Oj6us8y29hoh 5AxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=1k2qcAkAtHDfR0aJMrTCEPMAS7uQg6oG/ebI/uFBr/g=; b=hCANIlwQNEtAbGqY/My6vXYx+3FQdHDuyY3QHzhsnDdGJez7EJm/g0NHoVdkGFhZAh XcPvTjG7Hru2bvCV1zihM8VGcGMxYZ1tsbPEQBcNovH+OSRUG5HnMtjMHSI2XVz68pBs SuLEIBbecMptgMqdNaTn0jRNaAml7Wa/lhYbLAK9W5627M0DU73L7y+eAJ82cuxyKpMz McoD9xaofuJzSAQpsJ9SWopkxXA2K+RuujEJLAbxh9+ejCGzJWi++EYnU82KH7rmlL0g 9UOW/0DsOK72vIhlzJpbS0V2TdcokaFPkYaMANTUZ7cyqCKgofuZjynF4fRcs+ENAXlR eGcw== X-Gm-Message-State: ALoCoQm5msZHD9/WTzAZMMZg4t2dlFcEAEbQUtddpSbxvHrRIktAxP9Owc7ESgT0WuEIpMZnL8nNLTJTNrhPSpIqwY8+cYY21UoPvCvPC22aR6xbmz7cuiE= X-Received: by 10.60.51.70 with SMTP id i6mr27406539oeo.3.1453271993125; Tue, 19 Jan 2016 22:39:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Tue, 19 Jan 2016 22:39:28 -0800 (PST) From: William Denniss Date: Wed, 20 Jan 2016 14:39:28 +0800 Message-ID: To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=001a11c301cce9e2090529be4094 Archived-At: Subject: [OAUTH-WG] FIDO acr values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 06:39:54 -0000 --001a11c301cce9e2090529be4094 Content-Type: text/plain; charset=UTF-8 I realised when reviewing https://tools.ietf.org/html/draft-jones-oauth-amr-values-03#page-5 that we have not represented FIDO's "u2f" and "uaf". Should we add those? --001a11c301cce9e2090529be4094 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I realised when reviewing=C2=A0https://tools.ietf.org/= html/draft-jones-oauth-amr-values-03#page-5 that we have not represente= d FIDO's "u2f" and "uaf". Should we add those? --001a11c301cce9e2090529be4094-- From nobody Wed Jan 20 01:51:21 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4E71ACD98 for ; Wed, 20 Jan 2016 01:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSfzgWINh8tY for ; Wed, 20 Jan 2016 01:51:13 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EBE31ACD95 for ; Wed, 20 Jan 2016 01:51:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4U2NKPm453KC0+2Xjd2jLS2BEe1x+HoRcjFdfISPlgc=; b=nr3JTL6ve5pwxXJTg/eOuBiYdle18ILZzghcYuTHvFnN/9cdpBzwzX4RpquCgm+xw6bXEGTZNnc5RSw1xCYMHSzZTBEiyiF+FBF6Cb+VIllV8It/H13Gwuf01+3few2P00PJGQ08Syi32awp/IIaM3MMugXKuX5+MmfyRxGB4qw= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.365.19; Wed, 20 Jan 2016 09:50:55 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0365.024; Wed, 20 Jan 2016 09:50:54 +0000 From: Anthony Nadalin To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps Thread-Index: AQHRUq8iYUfUsD4JqEqyJO5z+rZonp8EKk/g Date: Wed, 20 Jan 2016 09:50:54 +0000 Message-ID: References: <569E2231.1010107@gmx.net> In-Reply-To: <569E2231.1010107@gmx.net> 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: [118.163.65.13] x-ms-office365-filtering-correlation-id: 90c0d045-31fd-4537-bc6e-08d3217f30a0 x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:YVWl5ZOPDR6+lXceFF0mFmolMQP5eLfutnvENvKtZ3ZsAJ4ZA9B+flIVhXemd/Y/OQfbPhbjKH8Eo81Pa0MXo1JQZ+0rEGfJQxIaoEI/Kc7TX2mrS54NZddoJya5NRxmdfVU/YxiWchOuWkwu3jtkw==; 24:1b/gB/wIyvlySrOmphpdnxS1TDmyZouMSHV96kJO7+RhHWJ7FHGbTquT4mDDANpGZ8YS5lRMazJSZH5h8ErMQ1B6Jvv0rw3UEwkGWi82otM= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; x-forefront-prvs: 0827D7ACB9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51444003)(189002)(53754006)(377454003)(199003)(5001960100002)(107886002)(19580405001)(92566002)(5004730100002)(106116001)(2900100001)(105586002)(106356001)(15975445007)(8990500004)(2501003)(2906002)(99286002)(66066001)(10290500002)(2950100001)(77096005)(5008740100001)(10090500001)(50986999)(74316001)(76576001)(81156007)(97736004)(87936001)(19580395003)(76176999)(10400500002)(5005710100001)(86612001)(1096002)(54356999)(40100003)(5002640100001)(575784001)(1220700001)(3846002)(6116002)(586003)(122556002)(33656002)(5001770100001)(101416001)(5003600100002)(86362001)(102836003)(189998001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.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:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2016 09:50:54.6181 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234 Archived-At: Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 09:51:20 -0000 QWZ0ZXIgcmVhZGluZyB0aGlzIGRyYWZ0IEkgIHRoaW5rIHRoYXQgdGhpcyBtYXkgYmUgYmV0dGVy IG9mZiBhcyBhbiBleHBlcmltZW50YWwgZHJhZnQgYW5kIG5vdCBhIFdHIGRyYWZ0DQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KU2VudDogVHVlc2RheSwg SmFudWFyeSAxOSwgMjAxNiAzOjQ3IEFNDQpUbzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFtP QVVUSC1XR10gQ2FsbCBmb3IgYWRvcHRpb246IE9BdXRoIDIuMCBmb3IgTmF0aXZlIEFwcHMNCg0K SGkgYWxsLA0KDQp0aGlzIGlzIHRoZSBjYWxsIGZvciBhZG9wdGlvbiBvZiBPQXV0aCAyLjAgZm9y IE5hdGl2ZSBBcHBzLCBzZWUgaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmRhdGF0cmFja2VyLmlldGYub3JnJTJmZG9jJTJmZHJh ZnQtd2Rlbm5pc3Mtb2F1dGgtbmF0aXZlLWFwcHMlMmYmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0 MG1pY3Jvc29mdC5jb20lN2MyMTgwYTI4NjdhYzc0YTAzOWQ2MTA4ZDMyMGM2NDJjMiU3YzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1mVDdiSDViVDhJU25kV0dDYU5q JTJmNFhHckN6MXhGenIwY1FkV21HVWhrJTJmcyUzZA0KDQpQbGVhc2UgbGV0IHVzIGtub3cgYnkg RmViIDJuZCB3aGV0aGVyIHlvdSBhY2NlcHQgLyBvYmplY3QgdG8gdGhlIGFkb3B0aW9uIG9mIHRo aXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3Igd29yayBpbiB0aGUgT0F1dGggd29y a2luZyBncm91cC4NCg0KTm90ZTogSWYgeW91IGFscmVhZHkgc3RhdGVkIHlvdXIgb3BpbmlvbiBh dCB0aGUgSUVURiBtZWV0aW5nIGluIFlva29oYW1hIHRoZW4geW91IGRvbid0IG5lZWQgdG8gcmUt c3RhdGUgeW91ciBvcGluaW9uLCBpZiB5b3Ugd2FudC4NCg0KVGhlIGZlZWRiYWNrIGF0IHRoZSBZ b2tvaGFtYSBJRVRGIG1lZXRpbmcgd2FzIHRoZSBmb2xsb3dpbmc6IDE2IHBlcnNvbnMgZm9yIGRv aW5nIHRoZSB3b3JrIC8gMCBwZXJzb25zIGFnYWluc3QgLyAyIHBlcnNvbnMgbmVlZCBtb3JlIGlu Zm8NCg0KQ2lhbw0KSGFubmVzICYgRGVyZWsNCg0K From nobody Wed Jan 20 02:26:01 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7931B399F for ; Wed, 20 Jan 2016 02:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5i_UV2v86WZ for ; Wed, 20 Jan 2016 02:25:58 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0A61A700B for ; Wed, 20 Jan 2016 02:25:58 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id b14so21434163wmb.1 for ; Wed, 20 Jan 2016 02:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=mR+ivPhA8kkW+FrvTz7fimzNY4ljHDKQYxqOKqxd42c=; b=XL67XigN0E+wTfnq2jGuZmcdJJVF81AyKvVijV/zH+libmn5XNxzBEc0o4t9h0msqO Rg+Q3d6ycMrFZsymYkdrLbQxkaYo4Jk7evhEhHgvN5VdJmM7fqOgljX6MxpBH/YpLX9m U1jRd0NsZ5uFeT5dk99gKECYmIetAyojk/Q1iYS8XAWHVB5X5nWpOgngEFkfB0jN3p1M Phf0tIY4FXfD2PfaYSlGg2yQ9ekGCkeOh/G2uup0BJlIM7ySjiWNa/8WfB4yEF5Aqdrx RFvBSYKS9O2+D7E4FGnvf9DqKlCjofDCBTSVSdfN7VYGhNgXkqtUe7+7bE+DN3duTw1n snFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=mR+ivPhA8kkW+FrvTz7fimzNY4ljHDKQYxqOKqxd42c=; b=e6HLkv5xUfyPUtOPWtynHfbGxTJVKGlzAHN/oVDVT/ZKilHYNwfEjcBPKFn2VxR/9g 65qcdgXNqL47d788PQLZIfazdOJf9B4oNPhBMChzjQv1RUQ5MsNnPPB07bpXVcAre423 4H+CUXTrOxSscWXAjVaKrhCqYie16kUJjIV38tuBlNmfcT/DhwDhXMdehDqLU1WC6sec gsbNbd8Zem7FWT/2a1BYCi99+Lu3ZL2LIuTx2LEbWxeL3jrhMyugiAOp4NPzcddjhR/C +n74qEyv1sxPVIgcTPLeE0lFO2V7NMs0yc2lXvOZbirKADDsCaRJ4EVCK1eY4dMQB0W7 Lb6Q== X-Gm-Message-State: AG10YORFqdOnXp0Z3Sot6Lkn7HWxWvnpsQVB22MiudvjUNrmcPKb+KS1e7HVN4aSTUitnA== X-Received: by 10.28.232.208 with SMTP id f77mr3264018wmi.34.1453285557048; Wed, 20 Jan 2016 02:25:57 -0800 (PST) Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id x189sm1125894wmg.1.2016.01.20.02.25.55 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 02:25:55 -0800 (PST) References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> To: oauth@ietf.org From: Sergey Beryozkin Message-ID: <569F60B3.3030501@gmail.com> Date: Wed, 20 Jan 2016 10:25:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569E1804.8010803@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [OAUTH-WG] Status of draft-tschofenig-oauth-audience X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 10:26:00 -0000 Hi Given that the draft-tschofenig-oauth-audience [1] has expired, I'm wondering if it is still relevant. I know the token introspection response can provide the audience value(s), but the question is really how a client is associated with a a given audience in the first place. As such [1] may still make sense, for example, I can think of two options: 1. the client audiences are set out of band during the client registration time and all the tokens issued to that client will be restricted accordingly 2. the client is requesting a specific audience during the grant to token exchange as per [1] I guess 1. is how it is done in practice or is 2. is also a valid option ? Thanks, Sergey [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 From nobody Wed Jan 20 05:53:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E02F1A894A for ; Wed, 20 Jan 2016 05:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkiASVJJQdBT for ; Wed, 20 Jan 2016 05:53:41 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819321A8942 for ; Wed, 20 Jan 2016 05:53:41 -0800 (PST) X-AuditID: 1209190e-f79046d0000036c0-7a-569f9163451a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 99.FB.14016.3619F965; Wed, 20 Jan 2016 08:53:39 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u0KDrdME009293; Wed, 20 Jan 2016 08:53:39 -0500 Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u0KDraMi005261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 20 Jan 2016 08:53:38 -0500 To: Nat Sakimura , Hannes Tschofenig , "oauth@ietf.org" References: <569E2076.2090405@gmx.net> From: Justin Richer Message-ID: <569F915D.8020806@mit.edu> Date: Wed, 20 Jan 2016 08:53:33 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------030703070308030606070201" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IRYrdT102eOD/M4P0dE4ulO++xWpx8+4rN 4sytFYwOzB47Z91l91i8aT+bx5IlP5kCmKO4bFJSczLLUov07RK4MhYtb2QvmBpVcfTlQqYG xmOOXYycHBICJhIbdrSwQ9hiEhfurWcDsYUEFjNJtK4XgbA3Mkp86g3oYuQCsm8zSTTu62IG SQgLaErsv/uGBSQhItDJKLHv/x1WiKotjBKzm1ezglSxCahKTF/TwgRi8wqoSSzqOQXWzQIU //XlO5gtKhAjcbHzCFSNoMTJmU9YQGxOgUCJnqU9YHFmgTCJD596WScw8s9CUjYLSQrCNpPo 2trFCGHLSzRvnc0MYatJ3N52lR1ZfAEj2ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdY73czBK9 1JTSTYygcOeU5NvB+PWg0iFGAQ5GJR7eiNZ5YUKsiWXFlbmHGCU5mJREeVM65ocJ8SXlp1Rm JBZnxBeV5qQWH2KU4GBWEuHN7gXK8aYkVlalFuXDpKQ5WJTEeXd1zA0TEkhPLEnNTk0tSC2C ycpwcChJ8P7uB2oULEpNT61Iy8wpQUgzcXCCDOcBGn4epIa3uCAxtzgzHSJ/ilFRSpx3MUhC ACSRUZoH1wtKRwlvD5u+YhQHekWY128CUBUPMJXBdb8CGswENHivGdjgkkSElFQDY97Mp/PO blVL23S5qlvyX2pd4N8a7gSzX48fNj4Td7sumdR8+5r4Ga4zvR93L4k5KvOn3Fz49SMptSXl otdinbi3KpSVty+S0148Jz34oadsgqPEfv+iPdUckRvXTn/cMf9h7rf0lJj31SKJHIutbv4J Kb/FmPM5YE/KhlNtG/yO5cqFzfm5RomlOCPRUIu5qDgRAL4Tg28iAwAA Archived-At: Subject: Re: [OAUTH-WG] Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 13:53:44 -0000 This is a multi-part message in MIME format. --------------030703070308030606070201 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit +1 Inline discovery and pre-configured discovery (ie, .well-known) should at the very least be compatible and developed together. It's the pre-configured discovery document that's at the root of the mix-up attack in the first place. -- Justin On 1/19/2016 10:30 PM, Nat Sakimura wrote: > Just to give more context, at IETF 94, I have done a presentation on > discovery. > > According to the minutes, > > (f) Discovery (Nat) > > Nat explains his document as an example of the work that has to be done > in the area of discovery, which is a topic that has been identified > as necessary for interoperability since many years but so far there > was not time to work on it. Mike, John and Nat are working on a new > document that describes additional discovery-relevant components. > > Poll: 19 for / zero against / 4 persons need more information. > The document discussed there was > https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a > simple (only 1-page!) but a very powerful document that nudges towards > HATEOAS which is at the core of RESTful-ness. It also mitigates the > Mix-up attack without introducing the concept of issuer which is not > in RFC6749. It is also good for selecting different endpoints > depending on the user authentication and authorization results and > more privacy sensitive than pre-announced Discovery document. It also > allows you to find to which protected resource endpoint you can use > the access token against. > > In the last sentence of the minutes, it talks about "a new document > that describes additional discovery-relevant components". This is > https://tools.ietf.org/html/draft-jones-oauth-discovery-00. It went > for the call for adoption. However, it is only a half of the story. I > believe https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that > was discussed at IETF 94 and had support there should be adopted as well. > > Nat Sakimura > > > > > 2016å¹´1月20æ—¥(æ°´) 12:05 Nat Sakimura >: > > Thanks Hannes. > > I did not find > https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which > was discussed in Yokohama, and was largely in agreement if my > recollection is correct. Why is it not in the call for adoption? > > > > 2016å¹´1月19æ—¥(ç«) 20:39 Hannes Tschofenig > >: > > Hi all, > > we have submitted our new charter to the IESG (see > http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) > and > since some IESG members like to see an updated list of > milestones as > well. For this reason, based on a suggestion from Barry, we > are also > starting a call for adoption concurrently with the review of > the charter > text by the IESG. > > We will post separate mails on the individual documents. Your > feedback > is important! Please take the time to look at the documents > and provide > your feedback. > > Ciao > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030703070308030606070201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit +1

Inline discovery and pre-configured discovery (ie, .well-known) should at the very least be compatible and developed together. It's the pre-configured discovery document that's at the root of the mix-up attack in the first place.

 -- Justin

On 1/19/2016 10:30 PM, Nat Sakimura wrote:
Just to give more context, at IETF 94, I have done a presentation on discovery. 

According to the minutes, 

    (f) Discovery (Nat)
          
             Nat explains his document as an example of the work that has to be done
             in the area of discovery, which is a topic that has been identified
             as necessary for interoperability since many years but so far there
             was not time to work on it. Mike, John and Nat are working on a new
             document that describes additional discovery-relevant components.
          
             Poll: 19 for / zero against / 4 persons need more information.
The document discussed there was https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a simple (only 1-page!) but a very powerful document that nudges towards HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-up attack without introducing the concept of issuer which is not in RFC6749. It is also good for selecting different endpoints depending on the user authentication and authorization results and more privacy sensitive than pre-announced Discovery document. It also allows you to find to which protected resource endpoint you can use the access token against. 

In the last sentence of the minutes, it talks about "a new document that describes additional discovery-relevant components". This is https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went for the call for adoption. However, it is only a half of the story. I believe https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was discussed at IETF 94 and had support there should be adopted as well. 

Nat Sakimura




2016年1月20日(水) 12:05 Nat Sakimura <sakimura@gmail.com>:
Thanks Hannes. 

I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which was discussed in Yokohama, and was largely in agreement if my recollection is correct. Why is it not in the call for adoption? 



2016å¹´1月19æ—¥(ç«) 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:
Hi all,

we have submitted our new charter to the IESG (see
http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
since some IESG members like to see an updated list of milestones as
well. For this reason, based on a suggestion from Barry, we are also
starting a call for adoption concurrently with the review of the charter
text by the IESG.

We will post separate mails on the individual documents. Your feedback
is important! Please take the time to look at the documents and provide
your feedback.

Ciao
Hannes & Derek

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


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

--------------030703070308030606070201-- From nobody Wed Jan 20 06:27:52 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99251A8A11 for ; Wed, 20 Jan 2016 06:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngCv-0-VjjwQ for ; Wed, 20 Jan 2016 06:27:50 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFC641A8A10 for ; Wed, 20 Jan 2016 06:27:49 -0800 (PST) Received: from [192.168.10.141] ([82.142.85.169]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LmJsk-1Zm11F1DxC-00ZuLq; Wed, 20 Jan 2016 15:27:47 +0100 To: Sergey Beryozkin , oauth@ietf.org References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> <569F60B3.3030501@gmail.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <569F9955.9030001@gmx.net> Date: Wed, 20 Jan 2016 15:27:33 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569F60B3.3030501@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="UN2XxnqCVlOCPv1QIe17p7KV80QDaldU6" X-Provags-ID: V03:K0:nPob/93v5EFdbxbhOS4i/dfHcis7aL8kWjM4RR1IEs84TXz1h+W KcznUzOyibhXghgvFve8dSrtNkkIuNiYihGID3czbxbH5udVHknFdgF8zcKMctwa7zMEuaU alNCkl/MCFBQ0loxvaZpraF9ltpftJh1sDOKXV80AIFjD07yO5LqDwtQDiByZS/nC5Q1Iyv krJqnr409tpyZgF6xQbkg== X-UI-Out-Filterresults: notjunk:1;V01:K0:HCt8qecpbRo=:2UKXPiILPlJ6826rjxreWU ekUuFwpV62/1Qt2mTVkOcbUudIY2DYaP08N8HhlW0mCM0JeTlGrKyQ0JILbjuWwj9NNQynvvN h0vcplM36V2url42JtM94zvxUmN+kkCE3ZGuzO2IlnQ7k8rq/UMsFek/dGZSDV1Gsm6M5VJIF lbEuzJipj1iCFE7qbY4UG7h5rK/ovRypy92BjfnKRRJg9hUkOBR3zU81DUZ19LY2OeZPkYWXj haVV9Krj2uDjbK46/Pcjazg6dy6KxTccjF6776mpBWWTmXL8Ne8zqTi0+Vexio4+Txylf/2ir BrvHYc/AKTxaKgKnARe3DUGXMiAjWCRmzg7IAon77zmuVdPxBvmApCpJkiYmBlk3kqfbXGSfY Tz5OSJ5jlGJF6ljg27Ro4/EihPdW/EPyJ0owrbNw/6vZQMLL/rARNe/y2o1IGRC6XS6yo2RA5 94enbnNSHa9N/puwtqj9wjxxS9vmz0dKrtrtFZlY4YDLXbwNUR1hJv93YTJ+Y63gIpvX8QLXD x1UJFudKeIfGb1JWZNh2o0c4j+mA9dzpKEZ0DlfxdG97kC+AiMq7FYkK9B0E95lRNc/mveSq5 9nHpYFL1HBKizNVNaSZR24LFVZqw1pLwGS5kwjM+10GF596Ea08etjut2pFN3JGxuh/tKdQ0N /+JUI0VeZ4PRz7wpwaFlBmOurTbpBQt8gTfLXleiP5E8z090bS8bfxtrTY+WCSpc9Gx9ZVn8Y B4wvkq+7sHvdmJMfC8pfIJkcrPjc2AZvK4MfJnScRzuwtLD+4d3le9hLiIo= Archived-At: Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 14:27:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UN2XxnqCVlOCPv1QIe17p7KV80QDaldU6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Sergey, that's a good question. After this document was published the functionality had been integrated into the PoP solution document. Recently, I got feedback that the functionality should be more generic and it is independent of the PoP work. So, I guess it is a good time to discuss the needed functionality and where it should be included. Ciao Hannes On 01/20/2016 11:25 AM, Sergey Beryozkin wrote: > Hi >=20 > Given that the draft-tschofenig-oauth-audience [1] has expired, I'm > wondering if it is still relevant. >=20 > I know the token introspection response can provide the audience > value(s), but the question is really how a client is associated with a = a > given audience in the first place. As such [1] may still make sense, fo= r > example, I can think of two options: > 1. the client audiences are set out of band during the client > registration time and all the tokens issued to that client will be > restricted accordingly > 2. the client is requesting a specific audience during the grant to > token exchange as per [1] >=20 > I guess 1. is how it is done in practice or is 2. is also a valid optio= n ? >=20 >=20 > Thanks, Sergey >=20 >=20 > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --UN2XxnqCVlOCPv1QIe17p7KV80QDaldU6 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 iQEcBAEBCgAGBQJWn5lVAAoJEGhJURNOOiAtx4MH+wXxeb2SHph1xS0B/ZzcjPFf RsQttrPL2oVX7gV3CYEVWYrrqIWVexDqWFrAti257+juIaatwhMMCFxyIy3QdUMA oh/wMUQj5cqvrSW4D7+pJ6TFGXNsR/Ktj9Lzbsm8LWcpXZdVgibnoCARoYXTsCjq SRNudu3tC/o+vmMLZvYs5VcXvTtjjcWBqZEIw3aPZ/5hI+I6Q8jpRMJ8/PKm2rhL ffokp2lncxw/RgKYNS6mspAGtLddVNhZ1j1kf+N/wKEq5IJjBwTPurs5Yy3XF0eL EHh8oh7Y7zRIM7hTfP+K/BjRt5ttkv3PFPKzvWU6F+rRQK8pdLPEUrir5TZFiQY= =ggdV -----END PGP SIGNATURE----- --UN2XxnqCVlOCPv1QIe17p7KV80QDaldU6-- From nobody Wed Jan 20 07:24:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF4E1A8ADC for ; Wed, 20 Jan 2016 07:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dLbgINSF4HM for ; Wed, 20 Jan 2016 07:24:17 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0001A8A8F for ; Wed, 20 Jan 2016 07:24:16 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id w75so7083408oie.0 for ; Wed, 20 Jan 2016 07:24:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aS0oG8+IeC7019PmeXoEIrKZJkbhqYe+hVzLEzbFx3U=; b=T0FhGkVWIQMUnXW+nZduxQA6OSJ+WvyjLCx69ykmgTUrBaur7P943v11a2xg1AdGFB Go+40DxIaou5fNgFpbksUt6MkNLhDbhnpsmL8yvyyIaGX1pcniKbCMcx1YPKj1sGtGM9 wFfwbjaLJGhn2hWxZQ3uetaDXZb1Sq5CbhQkspRg4e4cAZx7Gw49eRB8iz5GwqLFRPTJ ojVZGX2X0YnFbIXqHaCbKaD2Ejn41P+n97zABgGL3jmFheuMld3e5I+m05Yr9mofjvjB YLEUyBE8TyVY8QRrlFVnhaHGZmHskNYCkfWvgrh0tTuhIrbEY1OAvcb6skkaCeiPVlDu /4Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aS0oG8+IeC7019PmeXoEIrKZJkbhqYe+hVzLEzbFx3U=; b=gjyftu8sLc4m1mh35eTAtb8aAiiceZ3/JWCP0OscpblMp5eD/eC/JFby2gvAS/Wi/P 657yoxHoLtRox/o3fpqcLvkcg2aQZV+OEtJ47OuW/iXss1quVr4ti2gLspFG1QBhQ+JF R7p6AKM5hEHhGqZMvg6uk0D1QnornncU/w9LPMZsbm0+yPdOg+SfXzh1LgQOW1898upU yXGFeiybmp3/ZdIYUkVn3XEusSYjEhAwExkTU/I/ikCyaOvEmj5+pbH1Fm3x8KHY8/zM Ke+ccvNxfU7lyNoTBS7eZeHFu0QiVSaHzDa0lsyjJEi14EneKvkkU66ghSpqvCK7tRql PXdg== X-Gm-Message-State: AG10YOS0fanwEn5CuIXjs6C7NZVbUVPuUqTGJClQW9CyhRmjWRGVOUlmV+F64bx6AwxF+9cpmDkS6ZbQigrnOnbA X-Received: by 10.202.179.70 with SMTP id c67mr1894751oif.12.1453303456288; Wed, 20 Jan 2016 07:24:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Wed, 20 Jan 2016 07:23:56 -0800 (PST) In-Reply-To: References: <569E2231.1010107@gmx.net> From: William Denniss Date: Wed, 20 Jan 2016 23:23:56 +0800 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=001a113cdf3843ada20529c594d3 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 15:24:18 -0000 --001a113cdf3843ada20529c594d3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Why is that Anthony? Do you have any concrete feedback? I felt like we had pretty good consensus at IETF94 to proceed with documenting this best practice. On Wed, Jan 20, 2016 at 5:50 PM, Anthony Nadalin wrote: > After reading this draft I think that this may be better off as an > experimental draft and not a WG draft > > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofeni= g > Sent: Tuesday, January 19, 2016 3:47 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps > > Hi all, > > this is the call for adoption of OAuth 2.0 for Native Apps, see > https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fdatatra= cker.ietf.org%2fdoc%2fdraft-wdenniss-oauth-native-apps%2f&data=3D01%7c01%7c= tonynad%40microsoft.com%7c2180a2867ac74a039d6108d320c642c2%7c72f988bf86f141= af91ab2d7cd011db47%7c1&sdata=3DfT7bH5bT8ISndWGCaNj%2f4XGrCz1xFzr0cQdWmGUhk%= 2fs%3d > > Please let us know by Feb 2nd whether you accept / object to the adoption > of this document as a starting point for work in the OAuth working group. > > Note: If you already stated your opinion at the IETF meeting in Yokohama > then you don't need to re-state your opinion, if you want. > > The feedback at the Yokohama IETF meeting was the following: 16 persons > for doing the work / 0 persons against / 2 persons need more info > > Ciao > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113cdf3843ada20529c594d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Why is that Anthony? Do you have any concrete feedback?
I felt like we had pretty good consensus at IETF94 to proc= eed with documenting this best practice.


On Wed, Jan 20, 2016 at 5= :50 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
After reading this draft I=C2=A0 think tha= t this may be better off as an experimental draft and not a WG draft

-----Original Message-----
From: OAuth [mailto:oauth-bounces= @ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, January 19, 2016 3:47 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps

Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see https://na01.safe= links.protection.outlook.com/?url=3Dhttp%3a%2f%2fdatatracker.ietf.org%2fdoc= %2fdraft-wdenniss-oauth-native-apps%2f&data=3D01%7c01%7ctonynad%40micro= soft.com%7c2180a2867ac74a039d6108d320c642c2%7c72f988bf86f141af91ab2d7cd011d= b47%7c1&sdata=3DfT7bH5bT8ISndWGCaNj%2f4XGrCz1xFzr0cQdWmGUhk%2fs%3d<= br>
Please let us know by Feb 2nd whether you accept / object to the adoption o= f this document as a starting point for work in the OAuth working group.
Note: If you already stated your opinion at the IETF meeting in Yokohama th= en you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 16 persons for= doing the work / 0 persons against / 2 persons need more info

Ciao
Hannes & Derek

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

--001a113cdf3843ada20529c594d3-- From nobody Wed Jan 20 07:35:46 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E8C1A8AE7 for ; Wed, 20 Jan 2016 07:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeSSazuWf780 for ; Wed, 20 Jan 2016 07:35:42 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D061A8F38 for ; Wed, 20 Jan 2016 07:35:42 -0800 (PST) X-AuditID: 1209190c-f79c96d00000038e-09-569fa94cdf60 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id D2.CF.00910.C49AF965; Wed, 20 Jan 2016 10:35:41 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u0KFZeer023054; Wed, 20 Jan 2016 10:35:40 -0500 Received: from [192.168.128.48] (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 u0KFZbkm007795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jan 2016 10:35:39 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Wed, 20 Jan 2016 10:35:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <811C9F95-A854-40D9-9E2E-493DC2941373@mit.edu> References: <569E2231.1010107@gmx.net> To: Anthony Nadalin X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IR4hTV1vVdOT/M4J2WxdKd91gtTr59xWax ae42Rgdmj8Wb9rN5LFnyk8mjdcdf9gDmKC6blNSczLLUIn27BK6M5glfGQv281es2W3QwPiX p4uRk0NCwERi/o/HLBC2mMSFe+vZuhi5OIQEFjNJfJo3F8rZyCjx82oLM4Rzm0li2/fDTCAt zALqEn/mXWIGsXkF9CRe3brMCmILC7hI3D25HyzOJqAqMX1NC1g9p0CixM7dM9lBbBag+Jam +UBxDqA58RKrN8ZDjNSWWLbwNdRIK4n1U3rAWoUEqiVuX9rJBmKLANWceL+SGeJqWYndvx8x TWAUnIXkollILpqFZOwCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuoZ6uZkleqkppZsYwQEt ybOD8c1BpUOMAhyMSjy8Ea3zwoRYE8uKK3MPMUpyMCmJ8srMnR8mxJeUn1KZkVicEV9UmpNa fIhRgoNZSYRXfClQjjclsbIqtSgfJiXNwaIkzrurY26YkEB6YklqdmpqQWoRTFaGg0NJgtd9 BVCjYFFqempFWmZOCUKaiYMTZDgP0HBHkBre4oLE3OLMdIj8KUZdjmm7H6xlEmLJy89LlRLn 5QApEgApyijNg5sDSkQJbw+bvmIUB3pLmHcxSBUPMInBTXoFtIQJaMleM7AlJYkIKakGRiEj ThHjtzmyDumOs2MaZ8+33LGz9bPKp46zhVlPZvC/EXxz8fMhfyb9q19/1d/YuU1u1fu8P3uD zp+v6ig9f3lbV+q017X6ou/O/FRo/xLn9CpGhWP3Cn2+J0UZjYlBcUrrf86d4Pn/h8ZH9vN7 FI2Oz13Ms5bp4Pbb7XHtqStOiR8xDBQtUVJiKc5INNRiLipOBABdAD0mHwMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 15:35:45 -0000 Tony, that doesn=E2=80=99t make sense. An experimental draft would still = be a WG draft, and even then this doesn=E2=80=99t match any of the = qualifications of =E2=80=9Cexperimental=E2=80=9D by IETF definition. = It=E2=80=99s arguable whether it be marked =E2=80=9Cinformational=E2=80=9D= or =E2=80=9Cstandard=E2=80=9D since it=E2=80=99s describing best = practices more than protocols, but =E2=80=9Cexperimental=E2=80=9D = doesn=E2=80=99t fit at all. =E2=80=94 Justin > On Jan 20, 2016, at 4:50 AM, Anthony Nadalin = wrote: >=20 > After reading this draft I think that this may be better off as an = experimental draft and not a WG draft >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes = Tschofenig > Sent: Tuesday, January 19, 2016 3:47 AM > To: oauth@ietf.org > Subject: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps >=20 > Hi all, >=20 > this is the call for adoption of OAuth 2.0 for Native Apps, see = https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3a%2f%2fdatatrac= ker.ietf.org%2fdoc%2fdraft-wdenniss-oauth-native-apps%2f&data=3D01%7c01%7c= tonynad%40microsoft.com%7c2180a2867ac74a039d6108d320c642c2%7c72f988bf86f14= 1af91ab2d7cd011db47%7c1&sdata=3DfT7bH5bT8ISndWGCaNj%2f4XGrCz1xFzr0cQdWmGUh= k%2fs%3d >=20 > Please let us know by Feb 2nd whether you accept / object to the = adoption of this document as a starting point for work in the OAuth = working group. >=20 > Note: If you already stated your opinion at the IETF meeting in = Yokohama then you don't need to re-state your opinion, if you want. >=20 > The feedback at the Yokohama IETF meeting was the following: 16 = persons for doing the work / 0 persons against / 2 persons need more = info >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Jan 20 07:40:29 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D0A1A8F4D for ; Wed, 20 Jan 2016 07:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9jUFMLR3VDx for ; Wed, 20 Jan 2016 07:40:26 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D31791A8F4C for ; Wed, 20 Jan 2016 07:40:25 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id 65so6458261pff.2 for ; Wed, 20 Jan 2016 07:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1nzV15/NMF16kLwjpJrzh6Ypzf4mueDGhzYxEDTly+4=; b=XVdmiUGuRBXM52DE8AAEGvOX5pyXIQ7s7y2FvvL0xsBHCpm1GYXhmIGdJNbMKCsT56 7PCW/+nmVuMhfl+lXCcW7sNmXkkMYlc3tL+qW8rSAfcSdhuwXw2vZR5f61hCfQojBn07 SUHTmVD8+FxyR+Y0GNY5BvagPkrhOs0vKn7sC9z8vQfC1fqoRtuybbJrPfyLEaVw1EzV GpTybMWgkt/kG8RxAbqrIyLi+uFZpHLu+yBYkwuVGYCUE2RLgFzcMra+/FZ5TOnUUh1l E0Bv80Lgl2zIxmHcuinz7vBQQHLRlKYt7pcfhF1uT/CihDgl9Ox18yBg9qoivNUSohcl zEfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1nzV15/NMF16kLwjpJrzh6Ypzf4mueDGhzYxEDTly+4=; b=V47czeoFb5fXYaG0vQHllJ9mpXgGe+4IPtddh1GoMCe+b0eQl/Wlr6soQqo7q///8b lc6NQ3qREHLJhGCwu4tCQeeIevPerX+c6+Iwc8msY9WsLOxjGkIhSlZ4MP6O9QYLexiS k0dx4xpb8PLvC9lbqlazHLSA7MV6yK88G6JzLY/Ql4E/mLS2DAgADwka1LJ7SUxkkVYb BLNgWquQLhYcKx/POwM29ZzNhSZlJepVpio3NNXZtQER1HiTyNcpmIVu+Fqfygez6dpO /Xq83Mzp0MAQNQaZ0jGQrHlzJ/XXn1CWqycUUd2Db0Uha5cyPV28EeIcA5WHC2jm9q/2 3WnA== X-Gm-Message-State: ALoCoQlObwlWmZHNLJv47+6CWQfl94581WWoKUgsju0OXcRf3dwm9LxxVEUrAeM0NISWtPVWwh5OLhqAy5SDYIbRRUTLvFPJBg== X-Received: by 10.98.71.73 with SMTP id u70mr53204827pfa.130.1453304425453; Wed, 20 Jan 2016 07:40:25 -0800 (PST) Received: from mail-pf0-f182.google.com (mail-pf0-f182.google.com. [209.85.192.182]) by smtp.gmail.com with ESMTPSA id c87sm49662209pfj.41.2016.01.20.07.40.23 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 07:40:23 -0800 (PST) Received: by mail-pf0-f182.google.com with SMTP id q63so6676662pfb.1 for ; Wed, 20 Jan 2016 07:40:23 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.98.18.2 with SMTP id a2mr53442158pfj.145.1453304423605; Wed, 20 Jan 2016 07:40:23 -0800 (PST) Received: by 10.66.50.69 with HTTP; Wed, 20 Jan 2016 07:40:23 -0800 (PST) In-Reply-To: <569E2231.1010107@gmx.net> References: <569E2231.1010107@gmx.net> Date: Wed, 20 Jan 2016 07:40:23 -0800 X-Gmail-Original-Message-ID: Message-ID: From: Aaron Parecki To: Hannes Tschofenig Content-Type: multipart/related; boundary=001a1145784aebf3850529c5cd5a Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 15:40:27 -0000 --001a1145784aebf3850529c5cd5a Content-Type: multipart/alternative; boundary=001a1145784aebf3820529c5cd59 --001a1145784aebf3820529c5cd59 Content-Type: text/plain; charset=UTF-8 The section on embedded web views doesn't mention the new iOS 9 SFSafariViewController which allows apps to display a system browser within the application. The new API doesn't give the calling application access to anything inside the browser, so it is acceptable for using with OAuth flows. I think it's important to mention this new capability for apps to leverage since it leads to a better user experience. I'm sure that can be addressed in the coming months if this document is just the starting point. I definitely agree that a document about native apps is necessary since the core leaves a lot of guessing room for an implementation. For reference, https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_26 And see the attached screenshot for an example of what it looks like. [image: Inline image 1] ---- Aaron Parecki aaronparecki.com @aaronpk On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > this is the call for adoption of OAuth 2.0 for Native Apps, see > http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ > > Please let us know by Feb 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Note: If you already stated your opinion at the IETF meeting in Yokohama > then you don't need to re-state your opinion, if you want. > > The feedback at the Yokohama IETF meeting was the following: 16 persons > for doing the work / 0 persons against / 2 persons need more info > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a1145784aebf3820529c5cd59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The section on embedded web views doesn't mention the = new iOS 9 SFSafariViewController which allows apps to display a system brow= ser within the application. The new API doesn't give the calling applic= ation access to anything inside the browser, so it is acceptable for using = with OAuth flows. I think it's important to mention this new capability= for apps to leverage since it leads to a better user experience.

<= /div>
I'm sure that can be addressed in the coming months if this d= ocument is just the starting point.

I definitely a= gree that a document about native apps is necessary since the core leaves a= lot of guessing room for an implementation.


And see the = attached screenshot for an example of what it looks like.

3D"Inline
=

----
Aaron Parecki

=

On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tsch= ofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see
http://datatracker.ietf.org/doc/dra= ft-wdenniss-oauth-native-apps/

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

Note: If you already stated your opinion at the IETF meeting in Yokohama then you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 16 persons
for doing the work / 0 persons against / 2 persons need more info

Ciao
Hannes & Derek


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


--001a1145784aebf3820529c5cd59-- --001a1145784aebf3850529c5cd5a Content-Type: image/png; name="embedded-oauth-view.png" Content-Disposition: inline; filename="embedded-oauth-view.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_1525facecd4c96ea iVBORw0KGgoAAAANSUhEUgAAAu4AAAU2CAIAAABFtaRRAAAAAXNSR0IArs4c6QAAQABJREFUeAHs nQeAXFXd9md2ZrZvdpNN7wkJKSSUJBBAAaVJkWYFReUDEUVR7AqIr4iCvqgo8FoQBREEQaUJKL2G ACGQAum9bOputpcp3+/OSW5ups/sbJmZ5xqXM+ee+rsz9z73f/7nHHdHR4crN49QKBTdcLfbTWTM U9GJsxtjqs5umSpNBERABERABLpJILvPxIiHXbYKT1BORI3RNIqioxQjAiIgAiIgAiIgArlCwGsa mkAN2T1JKovslH0YSKUjfdg8VS0CIiACIiACvUkg64/FrBfYfRp7pUz3C1IJIiACIiACIiACIpAZ ge6YSzTAlBlz5RIBERABERABEegXBCRl+sVlUCNEQAREQAREQAQyI6ABpsy4KZcIiIAIiIAI5ACB eAM3/dDlJWOasspkjE4ZRUAEREAEREAE+p6ApEzfXwO1QAREQAREQAREIGMCkjIZo1NGERABERAB ERCBview11cm3lha3zdQLRABERABERABERCB+AQyd/ttb29fvHgxfkNTp04dMGBA/Cp66syvfvWr X//619ddd91nP/vZnqojWbl+v//5559/4YUX3nrrrdWrV9fX1zc2NkJj4MCBkyZNOuKII0444YQP fvCDXm/mnJM1QedFIFUCO3fufO+99/jNTpkyZdiwYalmi0q3adOmZcuWTZ8+feTIkVEnFSECIpDz BO6///7f/OY3PNd6vyezZs366le/+slPfjKtqt0Z7MH0f//3f3fccQf3Mh7kpjLujNdee+1HP/rR 3rTuzJw5c8WKFccff/x///vftPqclcTr16+/7bbb7rnnnl27diUusLa29tOf/vRXvvKVcePGJU6p syKQGYGGhoavfe1rzz33HNnHjBnzyiuvRJTz1FNPffvb3+Y3a8fzm/3JT37y4Q9/2I5JJfCzn/3s D3/4w+bNm01i6rriiiu470Tn/f73v8+vIzrexHz84x//xS9+Ee8s8XfffffVV18dkaCsrIwXJ94Q qHHQoEHOs870t99++4c+9CHnWWf4sssue+KJJ0zM8uXLKdN5VmERKBwC8WYwPfDAAzzlecDxutL7 NN59990vf/nLl19+OXeJ1GtPT8rs2bOHG8G//vUvKqiqqjryyCOxNyxdutTc2k499dR//vOfPp8v 9eq7k/Kxxx7705/+dOWVVx533HHdKSfdvNhdfvrTn3KlOzs7U89bXFzMtbnqqquqq6tTz6WUIpCU AArm0ksvxVJiUo4fP94pWYj83//93x/84AcEnHcu89bxP//zP9/73veSVkECvu389v/2t785yzGF fP7zn8c+6vF4nOV84hOfeOSRR5wxzvBnPvMZBIczJiL8+9//HnEWEWl/HDp0KIrqtNNOs2Oc6Yl/ 6KGH7FPOwLZt2zCXdnV1mUjeQyoqKpwJFBaBwiHgvCE4e82TnV/6X//61xtvvNEZ3zth7kgXXnjh BRdc8MYbb6ReY3pS5qyzzsIEwnvMb3/7W25VRUWW13AwGPz73/+OpODVMOkdivTdsdzEQ596h7uZ ct68eRdddBEmGbucuXPnnnHGGcccc8zBBx+M0R4mAOGOuXLlytdee+3f//43f+3EPGbuvPNOEtsx CohAxgSQF9dcc80tt9zC78L+afAdw9hgl8ntgCFOHt4lJSXf+ta3eN/AEIv1GMMqadAfKCG+w3Z6 AgwcM3zM7cwZyU0N3UMtlZWV3GvmzJkzf/58Itva2vhFY2LhRcqZ/gMf+AA/lsGDB5988snOeBN+ //vfj/yKjrdjfve73xkpg/J43/veR3wgENi4cePrr79uamQY9+2337ZHuOz0pKRTvNjBwS7NDti9 MDFIGbpjn1VABAqWgH0DgUBpaSl3AH5iab2uZwsdr/3YC0wbUi8zDR8OnELQMRhdnn766dmzZ9t1 8PA+//zzx44di1EXM+8Xv/hF51k7WR4E6B2WFfuV7pxzzuFld8aMGaZrtkQDyIjwweDXd77zHR4M WPKNKWvdunU8SxCCqM48AKIu9C0BHMUYz6YNDPR885vfjGnG4NXKDAT/8pe/xHxiGowLF897DBvI btS2U8rwXf3xj39Msi996Uu4o5n0qB/MkNzs+G7zusZ3mHgUEvZnjMDEI6dIz1mTnr/bt2/nL4rn rrvusiMzCGBzRabYGVEzH/nIRxYtWsTN7oc//GFM0w6d+uMf/3j99dfbuUyAeASc85YdkUAfRUAE bAJ9omOoPbN699967A7ECxgbNc9gbk/RaY499lh8ZYjnhc95FvsE9xSe+uTCesENd+3atc4E2HIu vvhi7kpEMmbE0Duvg9w3TRrug5zF+Qj7OfdizELoJHNrpqJLLrnkySefdJZGmAJvuukm3FOOPvpo rESYvnmNc6YhARl5xSTS1HjUUUchL5xpYoaHDBli9AruL1iwaYCtY2KmN5H49Nx3330PP/wwuUwM r6oJ0uuUCKRIAIXBgxn/uDfffPOkk04yuWxJbT7y2yENkRhsncXyk+Qjp5AFzvh//OMfRHIY8W1O 4fVipAnWFKNjTPzZZ5+Njx5hNDqDy85y6urq+MhIkDOy+2FEG/cByqGFr776aswCOcV9I/qGiGhD CcXMokgREIGcJpCqVWb37t2YdukqNup4HeYW8/Wvf91psH3xxRfPO++8lpYWsvAWuGTJkmeffZYX Kcwb5557rimntbWVGyWaAAMyg/om0twHCWPE5iy3SyzDO3bsMGe5VRFYsGABp3gvdA6ZM5rzuc99 zgwAYVHHBI0HE2M6995777Rp00z2xDWaNDH/UhHeOegkXkwnTJhg0qCrMFY9+uijtGfDhg3opJqa GmxUSDeEF/d9M32JvC+//DKPE7wvnQ2OWZEiRSAVAnzT+Ckx1EtiIzWic6Gh+WVhL4lwCrHd1YcP H+7MdeKJJ+L9RgxGFzuen6H50WERsSNNgBcYo5b46X3sYx8zkfzk+ZURRv2bGH4XTU1NCBHzsTt/ baMvL0WYwTFEO0tDXeGjw70CaYW12HkKKxS9GD16NAPB/FqdpxQWARHohwR4/+eOhHmYn23i5hXx 2444YmZgpjHxzDE+6KCDSB8zDXMKDjvsMBKYs9hCuMlyU/vCF76wcOFCXIZRNpi4eVvCFs1HZyHc lTCVM3zDMBbzkgg4z2JIx1v2L3/5C4M177zzTry5zegtlBN6gmF7GkwV3JS5tTEBFWMS5mVnmaZG WoKvAL4FBJxn44W5WfMuaHQMHHiQHHLIIdzf//znP/N2y/2ajPwljOihMZwljSE2ceJEvAfs2328 KhQvAikSwIvc6JgE6flVoidsi6BJif6++eabTThimgBzlJACvADw4LeLtY0Z9vuAfcqO4XdnR2KL Nd95rDIYL0mDYJo8eTLjrriaMSfcTplBgKElkwsRw7B6RAm8POBeQ+04AjtPrVq1ipFxYrDI8pLj PKWwCIhA/ySAfsBMwG82afNiWGXMPSgiJzcCYmJ60kWktD9yO0OR4DrEEL4xejOOc/jhhzM0w72M Nznnax8tZoQezxI7uzNQXl6ODOJ2HLNtdkosN6zsglqy53miqxjcwSpOdZhwGG+yE1MjCilejXay 6IBxCKAizD9J54FjeKc9xjLEQ8XpTBBdsmJEIC0CEWNJqefFtsrbBenxb7NHpkx2rKfRM5ltmRI9 YGSPltpyh3JsExEDPbxIEGN+ufxq+D0+88wz//nPfzKe50kJpqkM3Ub/oGCCux4d5LWBNx/SmMQY g2kDrn4MWDM13UTqrwiIQP8nwAB60kam6itjplvzUpW0RDsBuofFZpjZ5Lzh8hZ1+umnk8ZoIzux uQHZHyMCeANEvFZGJDAfjZtOhDrhZmcsLtw9nbkS1+hMGTOMicjWMdj5WUXjpZdewh6D+wJ/CfPG bFvXqRrbTMxyFCkCWSFgq3w7EK9YlhLAkZZk2GyxHcZL5ozntcR85KvujCeMpdbE2Gn4aEsZdAxm EpxwsWXicothknoZ/eEnmbSdplgMSM3hAyMrI9S4uHFXMafirY3JGwsvP5RvG2YYhzLGUca1IwbU TFH6KwIi0G8JYHdI2rYYVpmYeczv375DxUwTL5J7EHMjudMRMGFSMn7vTM+7HfYbZ4wzbDumOCMj wpidqYJbGC4pEaeMo7EZI7NPJa7RThYvgKmJAjHCc9+84YYbKM1WbExWx/7EgY8z01Z5HcRFJuYy YvEKV7wI9BABxpV+9KMfUTjfWNxg+ZtKRSQzwzr8tec/m4z8ok3A+bLBr9uYQ5hHzTi3sZ3g44L3 GAvc8V6EYw22mZjztCPagwThiIjkIwopntkZvYWXDCoNDzl0GzcWVoswvkEYbKKLUowIiEB/JhDh 5xezqalKGeMBw3BJzFLiRTIqxLwnfAbjJchi/Jo1aygNZ0MMyDGLdS4GEzNBupHco7mfJlgvFQ/o W2+9lXlb3LJtoZNuLUovAtkiwPKd3/3udymNhz06hpVzUywZd13z++JlJiKX7fjidOnFS4wjunA8 3hATZi4k/mSpSJnoQvB0wfIaYXyNSMZqfkgZXuaYi84wtzHP4LjGWHNESn0UARHo5wRiTpqOaHN6 UobbFpOik/oSmzpQMDzmWYWFaZ+ssEIubNHcy5gBhO9IRDu6/9G8FFI+r2IxS4vnLBwzcSqReBXY OgbTN++7+Cxzr8efgPXBmMxlpmojZVIpTWlEoEcJYEH8xje+QRXomMcffxyvtZjVMUKKnx0jMmgR +2XIliks/Mhv2ZmRGPORWXvO+HhhfHLNqRTfi1iawazyQC5srnjYYO+JHueKqI7esRYDth96zao5 ZqxdJpkISvooAv2fAK57ZvWsxE1NVcrg9sE7DROCeGCjRWIWygsQGoX3HuYbkwCDBJOVcHPp5hpZ MeuKjkQqMbKDuZu7mNPWHZ0y6zG84NJNs9oNhaP2QIFzIjSkY7JOWwVmQIAZdmaIE63P19Wezxxd FNYOsyQdGxXhKW8SsBoCX2nCTO2OGNaxtwhg5MguDfOP2RAKX357ipM5axtHbU1j54oZ4H2At4KY pxJHYphByuCsw5wpUjLM9KlPfSpxFp0VARHoVwR4p0qxPam6/VIc8334i+9ehMeuqYmJ0Ljj4d9q +7UY35SIuce0jJkFKTYurWSM4Jil1s02Mc68W7duZWCeNWackVkMMxUrei8CYrDNZLEWFSUCmRFA hTDIghssOgZ7TGJrLR7rphbnnpRM1jOGENaFcs4mILFZp46VWpyLuDBRCNMOhz3l25TJAg32+rws 3JBZd1LMhS3H+N2zuANZWI7BueRVioUomQiIQE4QSEPKnHnmmSzpy82IpcTNK5fdQ6w1LPu2ZcsW 3sDw7DPxZkydNUPtBV2YiMDMBXvfOzt76gH0in2YXPZHAsafkRdBfHRMPGloFWvs0HizxF/qdaWe Erv3gw8+6HzTJcyqqcSnXohSikBPEMDjlYWdzG+QnyfDrwwzRRzOyUQ88vnt0BLWy7bbgwgwmx4w XszAE9qIpZhYeZJVbUxepJJzsRaMkcaLnzQs7IRdFj2BsmHDBPOGgztwT+8CS3uMPcb0Agh2dxQQ gYIiwI806RENJHrRpug0PRGTWb2pDjCZFmNw5v0MocCEauZaMwjN/YKbFIZcEowbN459AOw7GlsQ 8Djn1skqDvj3MdjE3CKGfiihh4acUFpY0RlXQ1dxr8SCzRbBrJ+BKeiUU06h3p7gbsrkfRfbO17A zNViOJ8wMT1XnUoWgRQJICbs2YL8Ts1PNSIvq2zj+GUiUTnMWObXGuHey1w8Vqfkt4w3WMQYE28v ERP0GO3FfGuEDpZaDmeN+MwxPTt6SRhnmqyE2bGSJaaQcdhHI8a5slK+ChGBvCSAOxpjL8zStdff 781uUi+12ytCpVh1GlYZSmRdGUbQr776auzJeO2xjgvLq3BzrKqqYmYEI0ejRo2yK2bsnHF0hrpZ RoJBH25nDABxK3SmsRNnKwB6xBPrimIexz+AJnHfxFqDqLI1VrbqiigHazbvnWgm/torykSk0UcR 6P8EWP0lQsfQZn7j/JyxquKRZncBuyOOLBh+og2QGGOw3bIkgZ3YBHBYYe4SVUTE98RHXq6wCjOX m43YeqJ8lSkCeUkAhzleA1hDBCtA7x/US+2JpyhGY3czYYFYrE/R5xLHsDgEBg98XTF+MFXbeYOL yMi8J97kpkyZYt78jPk6Ik3WPzIPE1M2k4lQXVkvPGaBvdOvmFUrUgR6jQBjTGgR7J1mMlHSiYG8 85CYOwAvGJhGkk4+6rWOqCIRKBACGTzfmbbC+Aar5Pc+IiYZYOV1+t6l0obMpUwqpSdN09OP/wwu YdI2x0vQ032JV6/iRUAEREAERCAegd58DsZrQ0/Hewuhkz0NUeWLgAiIgAiIgAj0FYH0fGX6qpWq VwREQAREQAREQARiEpCUiYlFkSIgAiIgAiIgArlBIHIytnH46LVRp1QqyhUflFT64vxS5Eq/nG1W WAREQAREQAT6ikC852Zsq0y81H3VetUrAiIgAiIgAiIgAjEJxJYyMZMqUgREQAREQAREQAT6G4G4 UgbDjGwz/e1qqT0iIAIiIAIiIAIRBCJ9ZXD4yCcF09N9Sdc/JoK+PoqACIiACIhAvyUQ7xna3559 ca0y/ZasGiYCIiACIiACIiACNgFJGRuFAiIgAiIgAiIgArlHQFIm966ZWiwCIiACIiACImATiPSV 4YRzDCxXxsns/vRywPBxEuvlBqg6ERABERABEehlAk5t0JtPQGddzjbIKtPLXwBVJwIiIAIiIAIi kE0CkjLZpKmyREAEREAEREAEepmApEwvA1d1IiACIiACIiAC2SQQw1cmm8X3ZFnOMTNnPc7xs3hp 4qV3xqcSTqX8VMpRGhEQAREQARFIl4CeQYaYrDLpfnOUXgREQAREQAREoB8R6EdWGac1pTuEpFK7 Q095RUAEREAE+j8BPemc1yjLUqarq8vv9wcCgQwopytlMqjC2XM7nG69dkYC3WlDd+p1tkHhgiTg Lsheq9MikHUCbq+3yOv1+ny+rBetAnuNgLu9vT2isniP2MSP7c7Ozo6OjqAr8zusx51eXuRSRMtz 62O6/c2t3qm1IiACIpBDBEKhYGlpaXFxcf9vc+JncXbbH08POGvpzfY463W2LQtWGbrR0tIWCAVd 6Bj+ZHx40szZnbrSrKpHkqfb3x5phAoVAREQARFwud1FHR2djCqUlZU5n5FCkxMEumuVCeuYlgD2 kR4TFh5PetaaeNwZ9Yp3qk/is9WvPmm8KhUBERCBPCXgrqws729qpj9YPuJd7v7Qtu7OYArbY3pQ x8Rjp3gREAEREAER6AECoba2th4oVkX2IIFuDTDhH2ONK/WYPaYH+90DRcvK0gNQVaQIiIAI9DaB QCDI0y0n/GZ6G02s+uJZsHrTWtMtqwx+vtIxsa6s4kRABERABHKYQPSEmBzuTAE0PXOrDPOuuzNf qfts+5vvS/d7pBJEQAREQAT6AwG8gHnGaYZ2f7gWqbShCNNQxJFKNtLg6S2TTIqslEwEREAERCC3 CFjPOB05QiBzqwzr4Dm9Q7pvI3GWliP01EwREAEREIH8JOD3F5AfKBaNpFexN31fkjYmIoE3unGp dIlSyJhiyogq9VEEREAEREAE+j2BApIy/f5aJGlgt9x+k5St0yIgAiIgAiIgAiLQwwQkZXoYsIoX AREQAREQARHoSQL9VMrgeZP0X09iUdkiIAIiIAK5QeDEEz/4+uuv50Zb1cqeIdBPpUzPdFalikAa BJqamtauXbNtW10wqCHzNLgpqQj0MoFFixadeeYZV1zxlR07dvRy1aqunxDIfA8mbvTMvLe7kd0Z TN0vzW5YrwVSmYGVi/3qNYD9qqLt27e9+eYb69evq6qqmj37yGnTpqfYPFbWevPN1xcvXlRdXTNn zpEHHzwlxYzdSdYnlXanwcorAlkkMGzYYFNadXX1d7/7/c997iKvN/PJuXbDiopC/Pztj9kNpDtp JnqCTu+3p6fbkG6PnAyzcL3TrV7pRaD/E9hjHQ20E8ne0FCvxbL6/yVTC0WAH+1VV33vb3+794Yb bjzyyKP6OZD/rnTvaI09Bbqy2FVbHhpeGZpU28870V+aF0PKOJWXU/VENzm7NobslhbdWsWIQOoE BlrHoIaGhgEDqgcNqrUX/WQ5pV27dhJPTG1tLWdTL1MpRUAEuk+AJ9RLL704f/78RYveXrlyVV3d 1ogysYmeddaZn/zk+ddcc+2QIUMizvafjze85H11Y2wpYzdyeKXrxAnBS2YH3jc2ZEf2dMCpAXq6 rmyVH0PKZKtolSMCSQmgCZ555ul//OPBxYsXNzc3DRgwYObMQz/ykY+eeOJJNTU1SbP3XILBg4cc f/wJM2ceVlpaOmjQILsipMzKlSu5h1ZVDeC1T1LGJqOACPQCgYcffoh///73Y4nr4mF8331/e+KJ x6+++geMNyVO3J/P1jW77l1cxL+TJgRvOdM/cVDvCZr+jCW6bXkoZZw+K7L0RF/y/hOzbNmym2/+ 5aOPPsIC4eXlFYgGlM1TT/33+eefO+uss6+88htTpvSGo0k8IDSJf/HOKl4ERKA3CeC4dscdd9x5 55+sbYxTO/BUmzVrVmpp+zLVWVOCc0bu1yjBkGtdg3vJdve7291t+/ZOeGZt0XF3FP/t453Hj9+f si8b3c/qzkMp088IqzmxCTDX4O6773rkkYdnzJjxhS988dRTP4RJBmfbf/3rn3/5ixXP8A1qZvDg vQ59sUtRrAiIQAEQWLJk8c03/4rXHtPXkSNHfvCDJ86de/TMmTPHjRs3ceL4CAZYVX/wg2sZY0rs IxGRq68+njYp+Pk5MaZJMnXyzS3uyx/1Lt5ujUPtanN99L7iRZd3jBjQVy3tv/WmIWUivhN8dNo/ TBf71goS3Z7omN65FH3LoXf62M1a3njj9Xnz5h1++BHf/vZ3uCuZ0oYOHXbZZV8aO3bcTTf976uv vvq+973/9NPP6GZFzuwMD7W1tWF8Lisry8ocB2fhicOdnZ1Uza+Gqm3Pm8RZun8Wb2Uq9Xg8VFpU tH++YcYl0wtmSxUXF5eUlETcEBKXSUZepk3GxCkjzmKxowvBYKC8vNznK444y8dwk+ijF6sePY1O oJhcJ4A9xtYxfOs+/enPnH/++fG8evldM6LEPCZmM/Xnjkf4o9gfnT8rfrJHjQ69emnXdc97fvGq B2tNU6fr6md8fzqvqz93rXfa5gRFjWlImd5pn2opEAIbNqzn34UXfib6loSCQeXce+9fuYVlhQZP u3Xr1i5fvmznzp3t7W2UyaN9zJixM2bMRDxx6u23FzY27jn00MMPO+xw88hvbm5+5523V61aUVs7 mMhhw4aT5r33lpIXfcBfPHtefvnF1157lTBPaNJMnz6DcMSBeNq0aSPvlFu3bjEZ0TH4ER9yyIyJ EydGPJu3bdv2zjsLSUnbDjvsCOxSEaXxcffu3TRsw4Z1w4ePoFL+RqdhIRx8Ial08+ZNKA8SVFRU DBkydOrUaZScrobjJsviOitWLN+yZQu9phfcRBAWo0aNnj79EMjEE0lkpBlgJzsTwchI1ZWVlWTB 8j9y5KiIjEwZAzKXY/ToMXQNOACn3paWFroAZBrPNRo+fDgfkTiAxcGzrq7O77euCOpq/PgJ+FrR Uz7qyBsCjCsZewyu+F/5yle/8pUr4nWNmwlzl/gOxEuQi/HFXtf1JwdqSkNXP2M9r/Gb+fxs97HJ vIB3tbqW73SPqgqNG5hJpzftcW1udHuKXFMGh6pK0iuhrsm1pt59cG1ocC+Oz0vKpHeRlDpbBHg+ cfBg44gok5GmAQOqTIKIUxl8ZH4m+mD58uXmgWdK4EU//GzefMQRs3mVR9+0traieOzyUQPYEYis qGhHjvBU5knMRzsBMaQ3WXisGplinzUBzr799ls8bqnOPkVKHu1Mg0KyzJo12+k4HAj4UR7UggEj FIphcKYQ4js6rDS0mYbZxdoB2kKNdBmAdmQY5lqEBXqLGz1CxD6VOEBLli9/b9Gid9Aidkr6ToEA RGsij5AX0ReRjrz33ruLF7/jbAagcIfiWL9+PWIOKelsSTBoITXdR0qiVJYuXWKvT8ip1atX8ZfH FWv2LFmyiG4aoWYaFm7qMgYuWc7noIMm2a1VIKcJ4OSLfwxdQEAn0DG5NaKUwRW5Ym7gjws8axus kaavP+mb9/nOmGbWZ9cU3Trfs2hb0abGvZXUlLoOHRY6Z2rg8qMC0btfr9rlPvp2y9j5gfHBf1zg 7wq4fvOa544FRavr90+tGlvt+sax/svmxMju7Mh/Vhb9/k3PwrqirftuFaMHuA4fHrz6eP8RDk8g Z5YshiVlsghTRaVBgMeh/ZSKmY2zpIl5KvVIXvRZ6W7lyhUUhUmAuUjDh4/k8Yl1YevWrSwYw7MW MZG0HuTO2LFjS0qK/f7Ali2b0SLYALArGFeeoiJPtHWE9q9Zs9ooAMwJmH/IznN98+bN6Bge6jyY eSQfeuhhFJ56jxKnpNLVq61KeeQPpcphI+zOgoIHP9KKqpFQ2KUSF8VZxMFbb72JYkAz0ciamoH4 KKBaOjo6gbBz5w4SLF26lO4fccQsgNgFIt0WLlxARtoDdl6m4VNRUdnW1gr2+vrd6DAS8HH27COj ZRBq7913lwIZvKNGjaHk3bt3UaPRN3zEHXv16pU82zDDYOMhQGKEGvWSEuy1tbW01m6PAjlKgJ8t UoavGe1nXCmePeaSSz7f/0eUunkJsM3ccIr//Ad8lPNOnfv1ze6jxxxwe+zwu6591osQOSDW5Wpo d7243v3ieu9jy4v+eE7XqAOH3Ri0ag6/wbX53Q1trvP+5oueH75hj+vKJ7wPLvU8dEFn5f5f+f4O IYB+8Iz311FVI6c2NRb9d3XxT07yX3F0jPeu/UV0O5RXUsZ4qPSVf0y3r4UKyDIB7oMbwwcBnpcM 2UybNs0e0+G5vnQpc8AXM86VtGKex8gR/iEReK7z4MRdZMKEiVOmTI2Xt6mpkX+jRo2eNWvOqFGj eNyalK2tLe+88zajPxRF1cOGDUMSxSsk3XhTKcNJRx01d+rU6QzK7Ku0FWHx7rtL6PWmTRsYo0nF brFx4wbsLvQX3YMFZcaMQ/FHMQWihxCICxe+hUJiGA6/BOeCyBhUyIiOoSVoNUxBdkuQKZhzzIge 3WcwiFGqiG6iWtAr5CKvbbZBAi5Y8Dp/V61aSXqEGjIItyozSkVdxCO86uvrt+M9vm2bpEwE1Vz8 yPoxZt41Ghr/mHhd+OlPb4x3Kp/iz50WHFnl2hK2eby8vujoMfvFgT/gOvmu4jc2773JjKtxzRkZ nD4kuHGPGzPJojo3+ua5dUVzfl/y8uc7D4ozo/tb/7HWuSnzut4/LjhtcKi6NLRqd9Gza4u2NVsU X97g/tnL3h+ftG9K1T6ygaDrtLuLX9mwt+q5o0NHjQqOrQ4t2+l+cV3Ryt3uzoDr2//1MifrF6dF 5t1XRib/5a5u31TJn1dSJhMeypO/BHhBx1mEV3+ei4yq8DB2OmfwVEbc8HvgsRpzeKj7YFiei4fx 6NGjnUVhUTjooMkYhNatW4eRhsN5tvthRAOVIjucnUUQYDjBeRYVhbcNWEaMwGCTaCgb0w5SBmWA jGMw6PDDZxGwm0cYGccY3FtvLSDlrl27eHWGMwkaGxvJyChSOONMhp+cLcFVCO2CPFqw4A2sLKTE rIIRxS7ZBJCJJLN1DJE8zHbtmkhFqLGysvIpU6aNGzfevpdRxfjxE3bu3EmDueJYfSIK1MdcJMA6 eKbZzAyIdqrLxR51s82TBwW3NFn++69v5u9+KXPHWx6jYxAUV58QYExn36uTVeETK4r+30M+zDP1 7a7vP+X9+yct37KI47m17mDI/cEJodvO7HKsXhOob3Nd9ojvkeVWpZh8Pj/LH+F885e3PUbHMJJ1 8+ld58/cPzKOtea65703vWIZihh7Yojq4MERNqOIVmT+MQuTGjKvXDlFoCcJ8GAz28thhMDy4Xyg mmp51uJhGj02lK1GUThWmejSGOfC85d4vF6cbjTRKTOIoadUGt1ZJA6nMGZQ5o4dWC62Jy4cyxP/ SIPUoECnjjEZqQIxwVgVQof1DDEymXhsIvwjPGKE1ZTolqA/iKcxpLETm7zmLwoGYxUOU85IcmFa q6iwPKuQPhy2jjHJ6GB5uTUxDWHa3t6BncaZXeFcJLBo0dum2cy7zsX2Z73Nk2v3SoHtLXutIFSx p911/Qt7XzN+dbr/mhMO0DEkOP3g4LMXdXrDT3tEyYvr9ue1W8hI00EDQw9d0HXQga8VA8tcvz+7 C5nC0RFwvbLxAM3Q0um6bl/Vd5xzgI4hvc/jwopz0RGW5PIHXT94dv+7kFVcVo/uFB0DR1bbpsLy k8C4cdbTnREK/v7qV7+85ZbfRPfTeXb9+k3RCVKJQSjwj5S1tUNqa2OvT0M8B7aBVApMK41x6Yg5 75rHLeNceJ9gYMCwkVaxiROjGzAF4QIZMxk9pb8MvvCkN/4HMZOZSNpGMsIWoDgFMogTPY7jzBgP O0qOg8lK4cTWNXIemIuwuzhjTBhuxq8Ii1ppaQxfH9QM2PnyhB2xgtEqKrpMxfRnAuxLYJrH+jG9 386gq9894ybtkzK7HWbHP7zp2RGekMC40iWz9ptqnMSmDw1dMDN49zuWEPnpi97jx8cwzNx4aqDU csWJPFAzHz8kcPsCy6Vv9W5K2P+SQKRx8mWVvzOn7I93FnHdif6/L/G0dLkeXla0vt4VYdRxpuxO uDtSJka92fJT6c11WbJVV7b6HgNrfkXx9LI7xFOHw/4YEUh8NiJx9EeexJgKkA084cwjMDoNUoPH H2cZ8og+252YkhLreRuvhLCa8WW90vCzvDTCXGG3gSaZMSBb5NmnIgKMuzFGQzLIkItiIxLE+2hn pIOAjankyEsLOUuxfBkQc1xo0ttlUqnzox1vB8heVBT7MUMD7GQK5DoBXLlNF1gHL9f7kpX2Dy7b +/XGS9cucPG2vZaSLx3pxxAS7/jq0f6737F+yHb6iJTHjomtRUg2ceDeelfv3l8v8Qu37q36nClx 759DKlyHDg/NC+82tXJ30biBcWuJaE9aH/e2I608SiwCOUHAGDyYN8S/BA3m6W4e8AnSZHAqnp7I oKjUs4StErHmGISLMPKCv5ZNpqMzwRAMp80YTWJBFt0wtKMpGYmYmCpnaS0ltLVZppnoohQjAiIQ QQDnWRNTXbJfsuNaayIPGbI/MiIjH6cODhn9z6rBu/cvK7E34eByV4JlYEZU7S259UBrzspde6tG rLR2uuL9O7h2r3xZta+p0c3rZsz+N6FuFpRb2bNliYnX63gWmp6uN157CjOeV3c6juUjgJN9/COc IO4rRfx8/fEMtorEEso+m0DH0DE7WbpGjnB6666H16HT8TAall2FtVaOTCnRgBTjcuHHtnbtGkiw EBFu4BkgYVb/Bz94AhlxJH/ttdczKKGHsji+/1YNER/jVbq6fq/1YdA+8wwpWRvGpB9Xk0jKYLAZ NcC1cY+VFgkyt/yAxJWJXvdcxs/G1OL8a0uTo/6QMP++PBFGnX3RWfivrDJZgKgi+ieB0tISvCWw EyTwR+EhyllS9M8uRLcq8VMfU0oCCweijZ4ymsO4j4ETXb6JYehnHz3LgBMvWXS8ZeAK72lARcbV JjqNiaHYri4LuzUOF38kLl52xRcCgcmTJ5lusmhCZv21M9pFZVZOP8llS4cJ+0Z8WAyG3QzMMazy AHUS3eZhFXsTbGrcq36i06QeQ9WNadwbrIK3NGWh3pgtTGKVSXDfZAFUh/dPzMJjR/a0xaL3LR/x ehS7/4rtLQJh15BSpuYyS4gj5qJwrPLCkeB73luNterhzcy8nKE5WIsvZtWWsoivLcKyLO7dJZzV GspBOgAnZvkmkmbgV0saM7EZXZKiuwwZzZgUwMlFR+J5KXGW9pgxr3guNQlaqFOFQICZ/P/973/p 6fz5r7E3ZAZdJqPJRVEZZO8/WfhlMV2IvQhMk96/b+OCmjJXhc+FUy3HjhY3i8EkaLM972nkvgGj BImTnqoudZX7XGbI6cZT/IntOqY0W4ElLTxeAnOHjD6bRMpEZ1CMCOQKgYrwwcOYFWaZVzx+/ITo lnOKDQSi41OJyboAQi6YhzrP+HiWpLAqc8xeOLChDBsxBZ3FV5gfdOAZ6xML7bCoDIGkUsakKSuz pAwFMqvdzJ22SnEcCEGmuzc3NzNNmsXuzDIwxjBDO8PV7Yq5IxKrv3CW1pJFJhkHUQUPIDB37lzz +bnnnn3jjdfTXVqGLGQ0JdhFHVBBTn34xSseYwXB5eX48fsHzZnWxPq/dGX9Hrc9xSm6Z7wcbd63 m4E9qTs6WeoxjCBPGhRatM2q+pjRwbkHrj6cejlZSakBpgMwYl/J4N8BRTg+YB+K+Oc4qWCPE2Bd E7NmDBsFrFmzhqXbIqpknTpG4nmsRsQn/mjmzvj9XQnmXiUuId5ZDCFmjjGL9rLEXLRUQh+gvGh2 vBKIZ9NHVsuNTsBqK5wwK74wuZrDmQZVgQWFv3YkEsSoEFQgai9mZ5lN/fzzz7744vOs7YvLi8lL LjN5m+kntCS6FyTbunWzaSSztSNaYjdAARE47rjjzzzzw3Dgq3vfffelC4QsZCQXhVBUutl7NH3E 7yLiY3TV7O/4q3l7pydddHjA6RYzed/qve9u32uzic5OzIpd7kD4NzqwNJGHb8y88SJtSbR4ex9r iT6uPh4gxYtA9wnwuj9mzBielNwmVqxY9tJLL7CNAeMalMxfRMzzzz/Hw5hkDHOkWB2GE+bd4IKD Swp2heyu1UtLsFJQOJKFhtkzUU3bqBEfxtWrVya+6zGJesmSRcuWvYc0sTtFf5cuXcxG00SynN2o UaOdOx9hdXnuuWfuuuvPTz31H1adMbmqq6tZ4o+/iJilS5eQ3bi22GWy7cCyZcvY/ZGRu4EDB9lr B7PjEjs8VFUNwLZERjaVdC6mjFpauXIFHgzhjOXsPBBv0Rq7IgUKlgCjCeeccy52Pgjcc8/dt956 S+ooSEwW0pOdQuINTKReYB+mbO+ydkEyQzmsVsdKLc7GHDJ07xvIb9/wJJjhcMv8vUpoxrBEg1DO kpOGDxmyt+r7l8SfBZ60lGwkSPUOno26VIYI9DYBhkUOPngqT000B49e/nFfQ7jwlOUJzWjOzJmH +XzeRYsWxbQ6xGwuT24EB6MqCAve+dhmMmzAGBK9WFzM7AkicSthlwNMIFgs2FsAMxIf2RSSuzD7 e7N3EiNHPPhRCca4El0US89VVVUyivTqqy+vXr2Kxf4rKiopZ/PmjSzvSx8patSo0Sy2a+dFGHEW 5YTcwbjCOsSsiGccXFAk5ELEQA9bPTstIG5YhBdpQvM4kE0UOH78BKaH2AUSgAkthA/NnjfvFfZ3 pFKG+xiuomOYeYxvMkKTlJTgzKuwCDgJoEIWLFjw+9//li/qrbday2nG21TSmQsdQ2Ij+i+66GIK cZ7NrfCCze6LH/KypZFp9rUf8EfMmmZDgN+85mVTgjX17rvf8ZjVdSP6yNShv76zV2187zjrPmAS 2IGI9Cl+/OKRgd/M97Ilwkvr3Q8uLfrYIfvNunYJGxtc591XvLPVqvGRT3Uybds+lUHA+SLnbLyk TAYwlSVnCGBCYeslnr4LFrzBU5l2I2I4CKBj2Kjo8MOPWBXenjD1LvE452GM2YMfFS4f/MPOMXv2 kd2XMrSBEbFJkyazRyPqgWEmTBr8s9uGrJk2bRodiSdlkGXTph2CUYetkYx0s/MSoMvsMXnYYYfb FhTn2egwom3WrNm4CC9ZsgQVgsAyo0J2ShTPxIkH4VDptPFwlvIBgmpEzaBaWEw5Yj1lWsIWTuyB FbE7gV2yAiJgE7jkkkv44j366COMBV9//XVr165la8l4fjNvvPE640rYY8wz76yzzia7XVSuBDCu MFlpyTY32xuxexGr/pvjyFEhhEtELwaVu6463s+WjcR/+TEvuyZ9/dgD0rywrujCB31d4UJOmxQ8 +aBuiQln7VT9nff5r3rGqvpLj/o6/F2fPmxfW8Pp2IryjL8Wm5Vvjh8X7KaOcVYdEZaUOQBIZrOf 4s1gio7PrPwDmqgPaRJgvGb8+AlsJIRJAwWA8mCMA+sF9gAcNTibZnkunr48p6uqqpYvX97c3GT8 S5zvB+kW6ExPe6ZPP4QxmrfffgsDBnYUcxZL0MSJE9ntiPlBCBlnlogwJUydOg27Edtk0l8zzIQh ijEgsk+aNMneG9xkpOWIM7x3kT4YscaMGWdMMuYs5cyaNQcJhSipq8Oa0maeEKQhEpnIMqwRBZqM 2GDmzDlq6NDh7723hAajrkw8g2gYlthGm4uS+rieyau/hUmArb6uvPLr9B01w9fvr3/9y7PPPs0G k2zMxIYGZiFgFp5h1JL5Svj5Gv8Y0qNjyEj2fsjNecdgG6Ob9/nB0FSEBjtas+FRxPHhg4N3ntfl iXXHwjrCto6Lt1veMN9/2kv4yFFBBpI2NFg7Y7+2ca+XTFWx62enRpUbUU2aH788N4Ap6L2dbuaE X/Kw788LQ3NHB/GhWbbD/caWore2uNvC9zAcdH5+6gHjYmnWkyS521h6k6SKdXpPU3P/nIwdq7E9 GxctWeLVJykTj0wfxiMa3nzzDR75s2fPQaM4bzFJW8VQC2qD5zrmn6SJ003AiA+GGX6hmDcYVOJv WiWgsTDttLQ007wBA6oTZycxB3136piI6kjAJtiYZ9AuAwZUxVQwEVnMR9jSDjKiYyorqxJUETO7 IkUAAox+3nHHHXfe+SdjVU3MhG8740rYY7qlY4pc1VXW9qU9cfBb++CffK+Gl/NPWv5Bg1zff3/X pw5lW7G4aZmq/Z3/etkiO16Ko0eH/nweu14fcH7FTvfM26yNl8bXuJZ/be8CNeZ1xZmOwaML/2El O3tKMHpj7eYO19ee8N2zKG7jhla4Hvt0d4eWnO0xYee9WlaZaD5pxxiBkrqgSbsCZciUAE9ffpZ8 480RXQxyAU8aFAlWBIZFSBadJkEMAyUcCRJ05xTyCLtRxiVgnsF0xJFKCSTmSJySBHgBcyROFn02 rKUwZh2w03V0MsWIQAICiJLrrvvx7NmzH374oX//+7EEKZmvhHNMTvvHsFQMWxex5N2xY4InTQx+ cELIU5RkVKii2HXbh/2MH90y38sEafxXzFHicbGX5LlTA996XyBs0UnvFpeAs32qssR1x7ldJ00s uuMtL9PCm/ct2UeCcdUhzDZMuRqQaB0ru6TMA7LKZM4uImcqUkZWmQhoPfoRd9c333x9+fJljM4w ss7wSnR1a9euwY2G4ZVhw4bNnn1kt97hoktXjAiIQLYJ8HLy0ksvzp8/f9Git9k620z0w8ls8uRJ uG3NnTuXedfpvpPEbmMPW2ViVxonNtpSEifh3mj2oF6+q2jUgNCU2pDXYalJhUy6dTlbwnoOq+vd 7KWADmPGeG2MHe6dybsVdvZFUqZbKJ2ZJWWcNPpJ+J13FjJ4hOkF5xjcXSdOPMgeCSIS7xAS4MmB vQEXYFxccXTtJy1XM0RABPqYQC5LmXjonI//eGm6I2XildkT8c6+SMpkjbCkTNZQZq8gfDveeutN ZhsZRxBGkZhnhJrBC7WxcQ9DS+ZHe9BBk/BRZR5y9mpWSSIgAjlOQFKmf19Ap5SRr0z/vlZqXfcI 4CnCsBFL6KJmWFyGxWA4nEUy9jR58uQZM2ZWV9c44xUWAREQARHIFQKyymTtSskqkzWUPVAQfjMs bcJ6MEyfZoMjDDNol9raWuYhM/O5BypUkSIgAjlOQFaZ/n0BnVYZSZmsXStJmayhVEEiIAIi0OcE +pOUccLoji+L8/HvLNMZ7k75znJ6OuzsS5Lplwma4sn+lK4EtemUCIiACIiACPQeAT3jeo91t2vK 3FeGtSLMQqLptiFfJyTna7/Svb5KLwIiIAJ5QKBH13JM1/LhtEB0h2269Xanrp7O6+xL5lYZLTre 09dJ5YuACIiACPQVAT3j+op8BvVmLmVY5LQo2fqDGTRIWURABERABESgbwnwdOu5hbwz6BoWCPvI IHveZ8lcyoAm8a4uec9OHRQBERABEchLAnq65dZl7ZaUYUarJ+Y2nbnFQK0VAREQAREQgX0EeK7Z y4Lvi9N/+zWBbkkZelZRUeZx7O/Qr/uqxomACIiACIhAQgI80XiuJUyik/2OQHelDG7VLAYv20y/ u7BqkAiIgAiIQJoEeJbxRMvWdKE0K1fyzAlkvkReRJ1sztfR0REMarWZCDD6KAIiIAIi0N8J4OeL f4zGlfr7dYrTvhhSJhVBiit1zAK7urr8fj/rzcRLEDOXIkVABNIiEHTpnSEtYEosArEJsA4e68cw 77pfzVeK3VbFxieQZSkTvyKdEQEREAEREAEREIHsE+iur0z2W6QSRUAEREAEREAERCBlApIyKaNS QhEQAREQAREQgf5HIMYeTHJz6X+XSS0SAREQAREQARGITUBWmdhcFCsCIiACIiACIpATBCRlcuIy qZEiIAIiIAIiIAKxCUjKxOaiWBEQAREQAREQgZwgICmTE5dJjRQBERABERABEYhNQFImNhfFioAI iIAIiIAI5AQBSZmcuExqpAiIgAiIgAiIQGwCkjKxuShWBERABERABEQgJwjEWFcmJ9pNI517RWkt nFy5amqnCIiACIiACCQmEP1Mdz7xo/PmsJSJ7oxiREAEREAEREAEcoVAtGSJ13KTMp6g0QBTPG6K FwEREAEREAERyAECssrkwEVSE0VABERABERABCKsOLaRpoiQ/UGYREAEREAEREAERCC3CGiAKbeu l1orAiIgAiIgAiJwwNQfSRl9IURABERABERABHKYgHxlcvjiqekiIAIiIAIiUGgEor1i8kTK0LEI b6BCu7TqrwiIgAiIgAikTiBaECTO258fsnkiZRJfAJ0VAREQAREQARHIdQLx5Jf3kUceyfW+qf0i IAIiIAIiIAIFS8Dd0tJSsJ1Xx0VABERABERABHKdgGYw5foVVPtFQAREQAREoKAJSMoU9OVX50VA BERABEQg1wlIyuT6FVT7RUAEREAERKCgCUjKFPTlV+dFQAREQAREINcJSMrk+hVU+0VABERABESg oAlIyhT05VfnRUAEREAERCDXCUjK5PoVVPtFQAREQAREoKAJSMoU9OVX50VABERABEQg1wlIyuT6 FVT7RUAEREAERKCgCUjKFPTlV+dFQAREQAREINcJaDvJXL+Car8I9BcCHR0dS5Ys2bZt244dO3aG j127dvHf8ePHDxkyZHD4qK2t5b/Dhg0j0F/arXaIgAjkOAHtwZTjF1DNF4G+JoBYef311+fPn//2 22+jZlJsztixY48++ui5c+dOmzatqEjm4RSxKZkI9HcCoVAo3v7V8ZqeQZaIoiRlIoDoowiIQEoE 2tvbH3nkkZdeemnVqlXciew85i4WfS+z09gBk2XAgAFHHnnkcccdh7KxC1FABEQgFwlEiBJ/IDhv ecO85fXvbWze3dRFjwZV+aaNqTxmysBjptR4PfvfYSIyptt3SZl0iSm9CBQ6gUAg8Pjjj99zzz0N DQ2GBcLFaBfzNxVA3LnMYSeePHnyxRdffMQRR9gxCoiACOQQAX7RzjvAq8vq73h6Y119bEvt8IEl l5w85tipA+0ORmS341MJSMqkQklpREAE9hJ47rnn/vKXv2zdupXPln5xu00gY0Dcv8hryxqkDIIG WZNxgcooAiLQtwSCodCdz2z6x7y6pM346DHDLzppdFH4NpI0cYIEkjIJ4OiUCIjAfgKbNm268cYb GU4iyogYo2P2p+heCDUTDAZN4Yw3ffnLX66uru5ekcotAiLQBwT+9PTGVHSMaRlq5uKTx3SzlftH qrpZkLKLgAjkMYEFCxZceeWV6BjkC166HNnVMaCjQI/HQ8lomhdffPGrX/3qunXr8hipuiYCeUmA caXUdQwESEyWbqKQlOkmQGUXgfwn8NBDD1177bXNzc1hDZN9EeMkaEslJnV//etfnzdvnvOswiIg Av2ZAH6++Mek20KykDHdXM70kjJOGgqLgAgcQMDv9998882/+93vcPXtCUvMAZXt+4CaMYKmra3t uuuuu//++/ed0X9FQAT6NQHmK8Xz803QbrKQMUGCpKckZZIiUgIRKFAC6JhrrrnmySefNMKCv70J wlRKjX/+859vuumm3qxadYmACGRGgHnXvZzRVCcpkxl25RKB/Cdw6623supdLwwqxUOJmjHH008/ feedd8ZLpngREIF+QoD1YzJrScYZTXWSMplhVy4RyHMC+Mdgj+m1QaV4NJEyRkvdd999zz//fLxk ihcBEegPBMw6eBm0JOOMpi5JmQyYK4sI5DkB5ivdfvvtfa5jbMrGNvPLX/5yxYoVdqQCIiACImAI aDtJfRNEQAQOIMD6MTfccANLvCBlDjgR/nD55ZdXVVVt3LjxhRde2Lx5c3SCjGPYcvKEE06YMGGC 1+ulARHl0Jiurq4f/ehHv/nNb7QVZQQcfRSBfkKAfQm27+nMoDFkzCCXnUVSxkahgAiIgEWAdfDM vOtoHJWVlR/96EeNxLn00kuxkTz44IM4spgVe6PTpxjD7kvnn3/+oYceivXFZGHW0po1ayKyc5at tlE58gKOIKOPItBPCLC/0vY9uzNoDBkzyGVnkZSxUSggAiLgYl8C1sGLN7TErgJMa0K4kIDl7A4+ +OCrrrrqvPPOw0H43XfftfH5fL6hQ4eie7Df8JfEaCOOpqYmttFmirWdkv2xWdX3qKOOIgY7EIWb BX9nz54dU8pQ1JIlS1hs5phjjrELUUAERKCfEGCfyBeWZCJlyNidLkjKdIee8opAXhFg8Rj2V0Iu 2NaRiO7NmDEDtUEkKRnuISWDQVOnTr3tttueeuqpxYsXI244Jk6cSHxEXvMRGbR+/XrMOcuXLx85 ciQyiEJMaUbEmGSHHHLIAw88EF0CDSM907Pnzp1LIDqBYkRABFIkcPzxx6eYMnGyww477JZbbjFp 2O+afSLTXVqGLGRMXEvis7FvN4nz6KwIiEBeEmC/67q6ugQSAROLs+OIj87OTtJjhjklfJiz6BVO mVEn89doI/5yjA8fp556KolJ1t7e7hQxpoSKigpnRc4wJeCpg3L60Ic+5IxXWAREoE8IvPPOOzjY jR49mtq9niL2u/7JA9ZObakfZCFj6umjU3Yrc3RxihEBEchRAkiKe+65B6GQoP3FxcXRZxEiHeED gw3KhnIYQuKviSSGw4TNKc7yEaMO8cRE6xiqKCkpia7IjqGRd999NyXYMQqIgAj0IQFuHXbtx04d yA6R9sekARKTJWmyxAkkZRLz0VkRKBQCjzzyyJ49exJLmZaWlng4GCRCmtjOLvGSEY+dxowombGq mClxrIkZbyJpJP6/jz76aII0OiUCItBrBDDoLlu2zK7uopNGp6hmSEZiO2PGAUmZjNEpowjkFYGX XnopsY6htxs2bOidPjOElLgimvrss88mTqOzIiACvUOA95Mf//jHra2tpjq87S4+eczVH5+EE0y8 BnCKBCQjsUljBqPjpU8cL1+ZxHx0VgQKggATi8zEpcS9ZR+DxAmydTZpRUiZ1atX0+zBgwdnq1KV IwIikDEBXj+uvfZalnKwXf4ZNjpqcjX7RLIxE/sSmPV8WT+GedfMV8LP1+kfg45J+iqVoG2SMgng 6JQIFAqB119/PZX7yJw5c3qHyKxZs5hxnbguGkyzzzjjjMTJdFYERCAmgRdffDFmfDcjnaIEsXLc 9EH8S1ymM0vilPHOaoApHhnFi0ABEXjt2fgAAEAASURBVJg/f35SKcMMhYsvvrh3oJxzzjnMx05c Fw1+7bXXEqfRWREQgV4mkPROEt2eDLJEFCIpEwFEH0Wg4AgwnyiVAZ1vfetbCeZpZ5cab2lUZ1uq 4xXOLFDmQMU7q3gREIECISApUyAXWt0UgbgEWD836cRmFnGZOXNm0mRx60jzBJObxowZ84lPfCJx PtqDmkmcRmdFQATynoCkTN5fYnVQBJIQ2LZtW5IULhcr2jHXOmmyLCagutNPPz1pgazNlTSNEoiA COQ3AUmZ/L6+6p0IJCfAGi2Jx6rLy8unT58ecy275KVnmoIxpmHDho0aNSpBATSbxidIoFMiIAKF QEAzmArhKquPIpCIAFOaE512uRjrQVgkTtMTZxlmmjRp0ubNmxMULimTAI5OiUACAtnagylBFfap HpotZZcvq4yNQgERKFACSaXMwIEDe9kkY64E+qm6ujrxVUna+MTZdVYERCAPCEjK5MFFVBdEoFsE kho2ysrKulVBNzIztpU4d9LGJ86usyIgAnlAQFImDy6iuiAC3SKQ1LDR2NjYrQq6kTlp1bt37+6T wa9u9ElZRUAEskxAUibLQFWcCOQcgaRSALnQV51KWjX+NBx91TzVKwIi0B8ISMr0h6ugNohAXxKo qalJXH1DQ0PiBD13NmnVjED5fL6ea4BKFgER6P8ENIOp/18jtVAEepYAXr11dXUJ6kBPsBhdnyiG HTt2JGgYpwYNSrK9S+LsOisCBUugp2cV9SZYWWV6k7bqEoH+SAApk7hZTF9aunRp4jQ9cRaBldSP J6lJqScapjJFQAT6FQFJmX51OdQYEegDAkknPNOmpJs09US7U6lUUqYnyKtMEcgtApIyuXW91FoR yD6BkSNHJi6URXVTURWJC8ngLJUmXoaYMocOHZpBycoiAiKQTwQkZfLpaqovIpAJgRkzZiTNtmLF ilWrViVNlsUEzF2aP39+0gIPOeSQpGmUQAREIL8JSMrk9/VV70QgOYGDDz64pKQkabo777wzaZos Jrj33ns7OjqSFsh+3UnTKIEIiEB+E9AMpvy+vuqdCCQnUFRUNG3atKRDSG+++ebChQuPOOKI5CV2 OwX7XT/55JNJixk9ejSOPoFAIGlKJRABEYggoD2YIoDoowiIQA4TYILSoYcemrgD+KygeK6//npG mhKn7P5ZJi59//vfR6AkdZQ57LDDpGO6D1wliECuE9AAU65fQbVfBLJA4H3ve1/SUhAWLS0tV111 1TvvvJM0ccYJ1q1b993vfpflZJLqGKo48sgjM65IGUVABPKGgAaY8uZSqiMikDmBCRMm4Py7ZMmS xEVgmGlubkZqHH300f/v//2/cePGJU6f1tnt27fffffdzzzzDFYiKkoqZYYMGXLMMcdo14K0ICux COQlAUmZvLys6pQIpEcAQXDeeedFSJlJkyahFZi4hJcMq/1SIvICkYHUeO211954442TTz75M5/5 zODBg9OrLCo1e0bed999jz32WGdnJydT0TEkO+uss5LuHhVVlSJEQATykICkTB5eVHVJBNIlgCZg jIlNAJzbN7LezEUXXYSwYFzp6aef/u1vf8uUItSMx+MhPU4q//nPf5577jnmEDEHimPKlCmpbyOw Z88e3G6WL1++cuXKxYsXt7a20mbq4m9SewxpvF7vGWecIUeZdC+00otAXhKwBr/zsmPqlAiIQFoE ECiYRpwzrtErc+fO/dGPfsRUbeTFe++9d+WVVxrDCSUbiwgWGmctkydP/tWvfoXOcEZGhMny7W9/ O2InBMo3R0TieB9POumk73znOxpdisdH8SJQUATk9ltQl1udFYG4BLBwfPKTnxw+fLgzxbx581AM bCeJgpk6derll19unzXKAzsKhwkjhr7whS8k1jFkJ/2FF15IFsL8DRewtxC78MQBpNXFF18sHZOY ks6KQOEQkJQpnGutnopAEgIIiq997Wt2IqMzWG/mmmuuQcowunT22Wd/4hOfsBMQMCLGyBGWnJkz Z47zbLwwXsOnnnoq0oeMpoR4KWPGf/azn9V+BTHJKFIECpOApExhXnf1WgRiEMDOcdRRR51wwgn2 OaNm8GXBJ4aBIZx/v/SlL5122ml2Amfg2GOPNd7BzsiYYZKlsltCzLwTJkxATqVYUcwSFCkCIpBn BCRl8uyCqjsi0C0CWF+uuOKKiooKuxSjZu655x6kDFoHDYGnCyNNzG+y0/h8PuY6sXgoaezIBAGS ZTaRm8Z84xvfILvx1ElQhU6JgAgUDgG5/RbOtVZPRSAlAsXFxQsWLLj66qud84NQD5dddtm5555L ESQwDjFsL8AyM+Xl5SzxUlZWhgxK3X+F4aqPfOQjKTXIkYgZVUz/bm9vd8QpKAIiUOgEZJUp9G+A +i8CEQSwuzDM9JWvfMUZjzmEyU1bt24lEsnCgbhhCyR8gceOHVtaWorucUofZ96YYaSP0/YTM01E 5CmnnIKXDFVHxOujCIhAgROQlCnwL4C6LwKRBBi7wWRyzjnnfOxjH7PPIWWI/OY3v4nBhkisL5hG 2trazF8CnE1r0CfdQSK2W2IuFTKLjHarFBABERABCHgwIwuECIiACDgJGFHCPCN2RFq/fr19ioXs nn32WXYYYOZRTU0NI00mJX9ZsRfbjJ0ylcD999+f4oDUmDFjbrrpJjxy5O2bClilEYFCIyBfmUK7 4uqvCKRKAOnAfOnbbrvtn//8p8mDZLGNIqgZhpaw1rDqDDqG0aUnn3wy1aLD6dgqIZXRounTp//0 pz+trKzE8JNW+UosAiJQIAQSLcpZIAjUTREQgZgEMIGgVJjQNGrUKAQNIoaPiBsEjdE02GycGUmA vnHGJA5TSOIEnP3ABz7AXtxUKlffpKyUQAQKloCkTMFeenVcBJITwGqC4GCq0YgRI66//nqzUxKC hiNCiBCDYSa7UuZTn/rUpZdeSrHSMckvlVKIQAETSOMVqoApqesiULgEsM0gaPCbueuuu1g5xgYR 1jP7/xAfIW7slPEC9lhVdAJ2svz5z3+OjsGZRuNK0XwUIwIi4CQgq4yThsIiIAIxCKAnkCm1tbVs Lfnaa6/9+te/rquri06XQJpEJyYmpvRhxZrzzz+fxWPwKUZFccTMq0gREAERsAlIytgoFBABEYhL wIzy4AiMeYa9lh544IGHHnpo165dzgwxpYkzQUTYON/YkVh4KJyF+FgImFMMKqWrjeyiFBABESgo ApIyBXW51VkRyJwASoWRJiw02EvY2vqCCy54/vnnmdz07rvvUijzjFj1Lq3Sp0yZsmLFCrKwXvDp p5/OhCb8i6lFxpi0MCqxCIiAJmPrOyACIpA2AYaBsNBgRyHn8uXLsaCgS9I1otTX17/xxhsUwi7Z yCBEDCUYR+O0G6QMIiACBUxAUqaAL766LgLdI8AcaTQNfymGEah0/XNLSkpMXkQMxh4OAt1rkXKL gAgUIgFJmUK86uqzCGSRgJmAna5JhgZgjzFSBhGTxfaoKBEQgUIjIF+ZQrvi6q8IZJlABiLGtMAY Y7LcGhUnAiJQeAS0rkzhXXP1WAREQAREQATyiICkTB5dTHVFBERABERABAqPgKRM4V1z9VgEREAE REAE8oiApEweXUx1RQREQAREQAQKj4CkTOFdc/VYBERABERABPKIgKRMHl1MdUUEREAEREAECo+A pEzhXXP1WAREQAREQATyiICkTB5dTHVFBERABERABAqPgKRM4V1z9VgEREAEREAE8oiApEweXUx1 RQREQAREQAQKj4C3rq6u8HqtHouACIiACIiACOQJAVll8uRCqhsiIAIiIAIiUJgE3OzoVpg9V69F QAREQAREQATygICsMnlwEdUFERABERABEShcApIyhXvt1XMREAEREAERyAMCkjJ5cBHVBREQAREQ AREoXAKSMoV77dVzERABERABEcgDApIyeXAR1QUREAEREAERKFwCkjKFe+3VcxEQAREQARHIAwKS MnlwEdUFERABERABEShcApIyhXvt1XMREAEREAERyAMCkjJ5cBHVBREQAREQAREoXAKSMoV77dVz ERABERABEcgDApIyeXAR1QUREAEREAERKFwCkjKFe+3VcxEQAREQARHIAwKSMnlwEdUFERABERAB EShcApIyhXvt1XMREAEREAERyAMCkjJ5cBHVBREQAREQAREoXAKSMoV77dVzERABERABEcgDApIy eXAR1QUREAEREAERKFwCkjKFe+3VcxEQAREQARHIAwKSMnlwEdUFERABERABEShcApIyhXvt1XMR EAEREAERyAMCkjJ5cBHVBREQAREQAREoXAKSMoV77dVzERABERABEcgDApIyeXAR1QUREAEREAER KFwCkjKFe+3VcxEQAREQARHIAwKSMnlwEdUFERABERABEShcApIyhXvt1XMREAEREAERyAMCkjJ5 cBHVBREQAREQAREoXAKSMoV77dVzERABERABEcgDApIyeXAR1QUREAEREAERKFwCkjKFe+3VcxEQ AREQARHIAwKSMnlwEdUFERABERABEShcApIyhXvt1XMREAEREAERyAMCkjJ5cBHVBREQAREQAREo XAKSMoV77dVzERABERABEcgDApIyeXAR1QUREAEREAERKFwCkjKFe+3VcxEQAREQARHIAwKSMnlw EdUFERABERABEShcApIyhXvt1XMREAEREAERyAMCkjJ5cBHVBREQAREQAREoXAKSMoV77dVzERAB ERABEcgDApIyeXAR1QUREAEREAERKFwCkjKFe+3VcxEQAREQARHIAwKSMnlwEdUFERABERABEShc ApIyhXvt1XMREAEREAERyAMCkjJ5cBHVBREQAREQAREoXAKSMoV77dVzERABERABEcgDApIyeXAR 1QUREAEREAERKFwCkjKFe+3VcxEQAREQARHIAwKSMnlwEdUFERABERABEShcApIyhXvt1XMREAER EAERyAMCkjJ5cBHVBREQAREQAREoXAKSMoV77dVzERABERABEcgDApIyeXAR1QUREAEREAERKFwC 3sLtunouAiIgAiLQ8wRCoVBra2tbW5vf7yfc8xXmcA1ut9vr9ZaVlZWXlxPO4Z70btPd+mL1LnDV JgIiIAIFRCAQCOzevRsRU0B9zkZXETSDBg3yeDzZKCz/y5CUyf9rrB6KgAiIQJ8Q4FV5586d6Bge yQMGDCgpKZGlIfGFgFhHR0djYyMSEDUzePBgEUtMzJyVr0wqlJRGBERABEQgbQKMKxkdM2TIkNLS Uj2VkxIEEaDAhfgDHQCTZlECCEjK6GsgAiIgAiLQIwTwj6Fc7DESMWnxBRfQyGIAppW3MBNLyhTm dVevRUAERKDHCRgXGcaVerymvKvAQDMA865z2e+QZjBln6lKFAEREAERgICZVhJtkgkGg2s3b95U V9fU3BzyB+1kTG8KuV3McQq43IFQKEggGCIxR2dXsL2j0+/vbG9t4WSRK0hCt5szAXcw5CryFrlD RaGgv7Njz+7dzY1Nu+vrt9RtGzVm9Jxjjp85a25nRztJyspLK8tKy4qLmxvqWxr2bNqw4YmnHz9i 1qzjjz++raWltLikvLjU6y1y+YNFRUU0g3/+QCBU5A66aEzI5S6iTqqkR+HTQQ8Bt5tWu4KBIn+n r6st1NrQ1dLk7wx0MUJUUhqsrGoMBve0tQVdReXFZYNrqgdXDyorKS0vLetob1/27nsUOG78xAnj JxQVHeDha6AZMvouJSUgKZMUkRKIgAiIgAhkjUBre/uLCxfuaW5BAliagCnH4QnabhfTUKwgaiZg qZmQ3x/0I1UCgWAAKdPV2t7W2dHR3trc1dnW1tLc3NhQWuwbNmQwpovOrgBioqO1tbF+9/q1a1qa Wzxeb/2exnVr1rz2+sKJk6ceedScbTu2Dx06ZPqUKVXlZcXeosUL3163cvWa5Sub9zS9t2jx2LHj pk+bxqShyvJyH3IGZeHxBNFTrhBiBrXlKnKHpxOFmxsMFrlJ4fageEhhaa2AK9AVDHQhdrweT8jj 8u+bSo0csRRJeGI1AasoSxTRb0sVNTTsaWxqXLd+7TFHv6+8rDxrlAusIEmZArvg6q4IiIAI9B2B QDD49IJ36ptaLQuH5a1p2TQs8cL/MbKgCnjYB0OIBywwHR2dKBi0DGk6A52tba3NjXvampqDXR31 O3YUBQKbdu1Y1NwYCgQbGpu8riJEh9sy5QTLyysCgc5QZxcZfF3B1158bv5Lz48bP/aggyY2bd+6 fVtdscezecOGZmYKNTTW1+1YW1K8wDP/yYqKg6dOmXv03FGjRlUPrK4qr8L0wv8sORUKolqQWugP q61hAw1KBsmD2YhWI2vcfmSZCx1TVFpqqSB/oCuEVSnIabKF1VqYOyGrlL0HUYQa9zS8/PILJ510 qudA20zfXagcq1lSJscumJorAiIgArlLYPmGTbsaW7DF0AVMFDzpeZBbRovwJBTEAsYYzDBdAQwt XTi9trW18gELRlewo27r5i0bN7Y2N++qq2vcuWNwdXV5sW9HXd3uXbvdRT6Px+1FBwSDZYzf+Iqb mposu4nL7W9pqXB72tpbt2/YUNTV0Vq/a09DQ2NDfbDLX1zsG1E7hKo9Pt+KVStDRbvqttV1+btO PvWUENIk5K4oKUGI+Blkwi5U5AkiU9xYZ6wj5GIgijEr2o5QKQp1hfjgC3p9IVqCBPJjcrGEUFim YZKx+ojdyTLmhA0yKBiHoiG4p3HP6tWrDp48JXcvbh+2XFKmD+GrahEQAREoLALrN2/1hgI8xS1z h/V4t57o4ec8EsEaqeEP1pWiQJfb3+kN+osti0cI4017U2NRW1ux39/c0rJr86a25mafv2tXR0dX R0ex14v1xu32lZYUd7S3Dakd3NLayuosNQMHYkHxehgv8m6pa2MoqrlhT1N9QyDA4A+6x93eFnRX u5tbmuv37MFRxsOwU7Fv0cKF7a1thx5+6JxZs0sHD7KsRBhYEF38w4XHFcI84/V43dbokteLfwu2 GVcR7S6iSE4SsvqHA0/QjwsNRhkjXSy1RhB5hZyxRpvCQseSM4St/7tcGzaul5QJk0j7j6RM2siU QQREQAREIDMCHS2N5e6wlEG/WEVYD3TLdhEuLoDCQM7gblLk8nncnV53hdvHJ8weDRua6lauWbVq 5Z6G+q6O9lLOtrITQhdSB1+WQNDv6gpWDR86YtRwVv1v6+osr6ho2NOAaKisqCz1lVSWV7U2towd M3bDhg0VpRU+nw9R0dnZgYmGCr0+36CBgxoaGhAlg2trVyx9d9umLYsXLDz62KMPPfTQ0vIyPGCC QQQNosqyrFiyxTIC8dcTNjC5GNYKuwTTDLyGGZLCjGM1jP9Y42bkCv9FGPFfqrZjwnIufNoaZtoT xqA/aRPoGylzzz33vPHGG87GnnfeeSeccIIzpvfD7e3t3/ve95z13njjjaxW5IzpV+FrrrmmubnZ btI3v/nNMWPG2B8VyDqBBMATnMp6M7JeYE43Pus0VGCPEvCFAsXWTB1jkrAEDEM11n8wfrhdXdYn RAFjO56g5UBrSQjGn1atWr3o9dc3r18f6Ohwd3UVWa7AIW+JNdSDsvDhseLF1hPY09hYUVm1c9du fIK7/H6vz1NSUtzS3BQqDQ0fNmz9hg11W+oqKirq6xu6Ov2Dhw6ub2j0lfgG1tR0hYLbdm4PdHYV +4sb6z1dbe2h0s5N6zc8tmtHW2vr+487zoPysUQMBhY0VvgIO+7i9UsUOoZBpSLmM+Ej43J3YfZh tynGl8KGJ8v4ZMxPYWMMxVi9PvAwus4y++jIiEAfSJnOzs477rgDdytng1nTsBekzObNmxlAtesd Pnx4TU2N/ZEv38svv2x/JECM82N/C8+fP7++vt5u1WWXXWaHFegJAgmAJzjVEy1Jq8zEX3uK6s+N T6unSpwDBCxFsM9AER5aCj/VkTBWJAYLPEpCRZaNg4ElF0M4bteKFcv/8cB9u7bu9Hd0IikC/i6j BegsNg8GjxANzH3uautAO2BZKS4uHjt27Jq1a1qbWwbVVJeWlPm7rEnaZSXFO3fU1Q4aTFp0Tydz u9s7GpsaGJ8qKS3pwB8mFGIXR3xlUCnWLHFXqLysbPvWbQ27dtcMGkhTOIwpyeJMrdYgEjYkS8rQ eiw2SJbOLstbGSFFdsuHlyEoJo5b3syWXLH+s9cCRWcPlDP7fIZy4CL2vyb2gZR58cUXI3QMWN56 6y1uuPiN9yiiX/7yly+88IJdxbe//e1PfvKT9kcFRCAvCehrn5eXNUc71c6TH8ESVi10AQFgPdGt xzr/s+SB1S+8aDHGeJiN5F6zbu0/H3po4+ZNLswwXi/zsZk1hCJgZKfT34UpBMdgNpHG3uHxevwB f2tLa9Me5jT5hw8euq2ubvuWutGjR1cPGLBj+45ir6eC1Vza2irLynhN7WxrKbG8XSp27tgxuHYw 5iCMLdi5sdN4S4obm5oovG7LNiZLN9TXn3XeuUOG1vq8PtqKHLGOcGvD05csbWLpMMurJtDJVKsu pl2xB3h4ormlccJCZt8FM5rGFGD1lQTh7PvO67+ZELBG7Hr5ePTRR2PW+O9//ztmvCJFQAREQATy g0BTh7+pM9DYFWwK/2sOuFoCoWZ/MPwv1BF0t7mKOt2eDtbsDwS3bNv+0iuv4N3C8x4B0dHF8jHM bOpkUTxWcUG4oBkQHFWVVWW+knK8AUpKWHcGW8vG9et37dxRVVVOkh3btzc3NbK03oDKstqBA4YN GVjm82CT6WxrxSl3QFkZ//bU72LFGh6HDBoMHTJ0yLBhtUOGIG6w5dQOHLh9+45HH32EcsKqw/Lk ZXzLPmiGtYyeNeXa0iXWEJTlN4NTME0LazbL+GLNOjfTlzhrlBAKyErKQbnhohkwMxH6my6B3rbK 7NixY968eTFbiZS59NJLudwxzyoymsCFF17IG4kdzx6qdliBXiaQ09cipxvfyxda1XWTQGOX9bzm Ls9fazUZ/hR5MFsQwuMFowdrz2H38DO3OeBf9N7yxYuWBju6XO1dLpxPgnijuDB8YLZhOIfp0qT0 eYqryitxZUGF+HxexE1LSzNTuvfs2eXzDa6sKEf61O/e5Sty+ztaKspLA/72rtY9pR4X/8Ntt4RJ S97Szs42DDnFvkrsK9hvBlRVVZVVtnoaQ8GOhvrdOPfu2rV96pRJI0cOZ84Slhjqtnx6Q14mXDM0 Zs1KcjGYhKeL2+cp8jONicGvfVIm7ObrYYk97DSYfphZHijCYkMuZI8lfKxZW+FE9LCbeAs2e29L GfSKNbYY62CAiWGm2bNnxzqpuBgEPve5z8WIVVRfEMjpa5HTje+Lq606MydQFOyynuA8wK21/pEi DCR5zCM8iEDxelEGLi/uJ10texqWv7u0pakJdYLdw8gdy5JhaQA8ffGxdbPkDFOtmcc0oGbQli1b WVQPP99iXwlSwVrPzh9gjwJWBEYtlHh9VexZEN6dmwQU09bhb+/o8jCxgxJb2rD6sLqM2+/HZbjY 52U9G4a7qJrXxZramk5/CE/KKVOn4AURLtpqR3iQCFllNQhtglXG6pnls4wwQavsOxy0LHtM+HDE WcGwuouI08c0CPT2ANNjjz3mbJ3Z/NOOiTf2ZCfo2wDDqHwJM2sD06M4MsvrzIXbcp84I+NM1xP1 cqfYuXOn07bk7Gzq4e43r/slpN5akxJX94y/Etnilm6bnenD3+gsfKW787NytkfhnCBQ5nVjEWEq dUmRq6QoSLjEHSwtcln/PCGfK+h1+T2BrhJXiEXwdmzdwhAPqsdSOKgYa+sApEtJeAsmJg65y1Au uP2GggiWqdMOHlQ7qKuzA4+VEp+ntqa6mEXtuqzSKop91ZXWZgUzD5k2Y8b0yZMOGjhwIPlZSm/g 4KFDho+g1KGDhw4bPGTwwIEVZaW7d+5gmWCMNtU1NTjlVJSVMXTFsNCuHTswxtAGRIqlPlAuDCJZ 07KtOU3sdEALkThWPOYl1tazDEl+Rpss6wsH+sdy/rUOc7GsSI7wB/7uC+bElexfjexVq8zixYvX rVtnA0AgM3/4hz/8oR3zzDPPfPe732VVADvGBFjs6Oc//7kz8jvf+U70bqv33XffypUr7WRnnHGG sfH86U9/wuRD/PLly+2zBJ588skVK1aYmC9+8YvR9ZpTb7755lNPPbVgwQIaT5vHjx8/ceLET3/6 01OmJFmWcevWrYgzmrRq1apNmzZRGpOlJ0+ePGnSpLPOOov5U6Z859+InpKGQTcSMFp85513vvTS S0xZYtbV008/TSTunC0tLXb2z3/+8yNGjOAjyZ5//nk7PmngkksuGTlyZHQyrhc+2svCh5kqxQYl xx577Nlnnz1r1qzo9CnGbNu27fHHH+da19XVISBMLhz6aDyFH3fccXPnzo34ScfEghT4+9///vbb by9ZsoRyyEIJJ5988ic+8Ylott0vIXHv4l2LiFx8heg43zq+iuYrwbAgbonvf//7P/axj1VWVkak d35Ml1uKX/shQ4ak2Hgak62vNLfy//znP6+99hqXDw5p/aycTBTOOQIDfJhcrFbjCmsNF1nWGcvz NxzgP4wbFeE4ywDS8iWLtm/e5G9vZxiJXzfxYY2ATGDHAkw6ZAoyLxr7jK/YEwp0dbR1VZaXel01 XZ3tXW2tZcUedzHzn0KV5SwqU4YoYS/JsaNH7NrdsHxHXUtrR82AAbVDh1ZU127ctGnUsCEjhw1j 6lOIzC1u/GMQIuz42N7aytrBrJhXM7C6pb31iccf9xX7pk+f7vH6rC2arNoJ0DBrBwO6wro4lknG Ei2hLjYuYN9LH4v8WcIl7PqL6cdytEHg8F9b0FgSJixkTEoS60iXwF4TWbrZMkv/k5/85F//+ped 97TTTvvBD35w6qmnOp/H//M///PhD3/YTmMCvLd94AMfcEbyqI6+73/ta1975ZVX7GTf//73P/rR j/Lxoosu4mlnx8cM3H///cOGDYuu5Q9/+MO9994bnYUVltBhPH6iTxHDd/SBBx645ZZb4tkbcLn/ 6le/SvPCX+H9ZUT0dOrUqX/961+RXGCxjSIM4z733HPkOeWUU5yTse++++5p06YR/8c//vF3v/vd /kKThe66665DDjnEmYpR5//7v/9j+Z/9PzbnaZcL2cTc74jGH5gkxie6cMMNNzzyyCPxijV5uAo/ /vGPncoyGsv1119/xRVX8GSNrob3rZtuuumwww5znup+CZQWD3jiU3Yz+ErcfPPNiCo7xhng+/yp T30KsBirnfGEM+OW4tf+oIMOStAvuyVZ/Erz5WTyYMTKUqaixD8ruzEK5AoB8ws1r1imzU8+9V8C fJ2s53tY0xiXA24m2CwszxOUjSe4ZvXKO2+/fXfdtk7LmM0uSAwwWTOYMIBYWwiEx3iY4FRSQlwR asPr9THM1M4G1F3+2oHVNVWVGEosg00wMGr4iBKfr6S0tBxRU172yrx5m7fU4ebgLS6tGTgIa00r ufyBgTWDmI29fefOqpqBLOq7YevWrs7OAfjaVFQgViqqLJ8b5kwxxvSZz34WM01paVkFBpwyZkHx g7WMLvgMB1qaWnfvZA4ViVsDoTamYlVWtXuLGzs6KZxtEGoHDKwZUI2Hck1ZJU1lZ+x6XsMYAmMt YWspmuB5537cvrjR9OxTCkQQiLxpRpzO4kfM0dg2nAUiZbCsRKiHiBEoZ/reDyMOYuoYWoKFnwX0 Yt6OeWp+4QtfwIwUT8eQHYsC2UlG4sT9wsTCCma2jkmcOCtnsRzgB4qECt9sYheJWqJVKJ7Yp2PF kpgVCB9++OEExZp86FRji4pVjBUHtG984xsxdQxnkXfY2BJPiOt+CfHaFjOeYUF09s9+9rN4OsZ0 Ct38i1/8IqKELHKLKDn1j1n8SjPvgxeYmD8c2pPgZ5V6a5WyPxOw5h4FrU0fcZxl1Ag3GS/jRyzB gi9t0G9tKc1Kc67gwtfn79m1g9Vgwp4uLlbPZadr7BlMRCoK+ct8RZWlnkGVJYMqi2vKfeWeUKm7 q6bCM2xgxdDqMk+gPdDR4nP5B5QXjxo2eMSQwSOGDRs8aFB7S+u8l1+p27zZqs5aQjjU0rB795Y1 7rb6IeWeal+gONA6fsSQ6jJfV3srCqW8jF0hPdxPdu/etXH9hs0bNu7cvoPbzrJl76FeOIV8QXlh VuJAkLHAnTkQVdY4VJHbZw08eS0fZWtDJswwKBbrCBtlLMMMGa1CwpoubJcJi7v+fP36a9t6b4CJ 55Pzsc0oydFHHw0WrDLOpw6jOXxXnCq+++hYLolbJOUwzORsw9ChQ3mDN+VHD1cRz1J+5qz51kbr CewWRx55pElj/8UYs3DhQvujCTC0xDfYjCnYp0h26623RiwxbJ8lgBji+eeM6ekwP8Wrr756zZo1 zoq4WAyCcF127dplxzNAAJDUm4c2cg578fudMWMG3wGsArjLPPHEE0uXLrULZ1CLgTkG4+wYZ8CJ EXcrvi0M4dFyOw2X+7rrrjv88MPx0bMjnYHul+AsLWn4tttuc9oLTfoJEyZggGHo0Hw5TSTWQUbH PvOZz9hlZswt46+9XbUdyOJXmsvKYUpO62dlN0aBnCbQ3NFmPbuxvVjjShwYLsJGGmOpweHE6+5s b9uxfSujT8VlpS3NLSzTwvIvZODNG7MMI0flJaHK0uJqyypSXFHOOnb4wbhZl44E1rATu2p3dPLj qh1YM2b06IryKqwmvD2y62RVReUHjz+hpaW1s7MLbTS4dpA31NrJ1k4sDFzk6fIHG5rbttU3FAXb cdnpZMJ3wGN5ybiDPDisZvoxCLm3b9/W1tZeVlZJk5AsKBJrNRykDG46rKrKcsCMOlkNcQc83rA7 cFi+kALZQ9dRNPyzhpT2HVZa6/9WvI6MCPSelGFYwdlCfBqwDBKDY0R1dfUex94TKBvM7M7E3Qzz VDMlMCTkXCKPiRvOJfKcKseu8YgjjvjWt76FcwwxixYt4oVy+/bt9ll82nfv3o0HiR1Dmn/84x/2 RwIf//jHcUYxM6V5Zt9+++3OBA8++OCZZ545c+ZMZxY7vH79ejvMett459TW1ib1FWWELuZEMB6Z DNxEGDN4cDqf93/729+cHkWMcJGFh65pBv1lqMt2cMHtY+3atfZZu6kxA07yJICqEz5jbQyIOKtm 0n48KWPK51H905/+FCbcBRij5AuGz4d1mwgfKBu8i5Bl5mPMv90vIWaxEZHIrH/+85/OyHPPPZfh OZxUiEQdYp8zI4YmDT4ujDTxmDcfM+aW4tfe2bCY4ex+pU0V6f6sYjZMkblIYMvuXYgMNi6yHt6W 8rCWYLHEAA93JjD5XJxqbWpkk0icbVubmrBKMgkphIdNhx9nXsZzBpT7qisYqSkfyFh7ZeUgNo2s rqkoKfV6i5m9hAsLiqGpqYXRIPxaBlQNKC4ppWw2mGSpGO7VvLVSHaqhlDGnkuLW9kZrxT323W5t bWpu3FXfUFO3fd2WOtbJ63R5Ol0+Woi/8Ijhw1kFuK2jfeSIEbWDBjESam37xB6WlstPkAlWYVnT 5Q0EGOrysgRfZyeDVlYPLUOMpdu4MVmCJ9xn+k7/g9bIFEELBKesxGEmViYdaRLoJSnD4zPCpHz6 6aebpiJoTjzxRKcPDWNM2ZUyaTLZn3z8+PGM69sPFfTBj370oy996Uv7U7hc+K46pQwPV+dZntA4 MtsxCBo8ePghOftLFgSEnSY6gIjhsXT88ceHv/PR5yNjUCccEbE846+99toIHYNJA7OQvXsDjqW/ //3v7YwUwkASY8J2DN6p2JCcZiT8bBA3doJ4ATSc0+iCex27bjkTc2s46qijnFLG9sh2JrPDWNQY jrGX0gHRBRdcQCHIAjsNPtd8kXCBsmOcge6X4CwtQRjHHa64nQARf9VVV9kOMWhT/H5QdbahiNGo d99916jbrHOzm5F6IOtf6Qx+Vqm3Vin7OYE1mzbjemLN9gk/ttEwPML5gfBoZzimrLiIFWIadu9s a28lusNylHHjJevv8pcW4WPrLS/zDRlcOaS6vLLUWzugavjgITXVg6qraqqKK9Eolg8wDrheH9ol wI7UjFe53ZYSstQTLjXl/JcxIRxoGPVBhSAw2osGsYmBBzXS3tbe0jxoYFNpWRlqZOmK5du3bg+U Vvu8bl9FZUtjEzqGpW+4hR52xGHcTlkZj3LYzpL/d3awSJ41LmbNz8IH2KrXWh7HcvyxNJrlk8oR tBplGY/NFKe9Ksb6HL61A8QSPDoyIdBLUgZDCxfSbiDzZZxemR/60Iecj3bu6cxrYHTATt9XAQwq to4xbZgzZw5jUk5nWx42dvN4w+YV3P7IzyamJsMRBJcR+/GGvZ0C7aEuO7sJ0ADGuZj0FBGf7kfG OBjEceZCT2DG4LliR2IIcfr3MMzh1DEmGU9iJA4CznzEJfnLX/6yMTDY5UQH0EzOYUQ6Re0Ryexx h4j4mB8/8pGP2DrGTkAklhi7bYx/Ye04//zz7QTOQPdLcJYWL4zRjjFT59nLL7/c1jEmnlswljkG K+1kjDwaKZN1bnYVKQZ64iud7s8qxaYqWU4Q8LFOnN/atsgyVrhcgWAXIeNvEvTg5RLCDNKwY5uX Ex0shecJWXsY4Ebj8vn8VaVFIwdVDK8ZUF7iYbLSgEq8cnGhrSr1ljLBCeXi9visfwxHsbhMeLU6 a6Y0//cUW2vGWBOOivFoCTHTiKGekKvL32nZQmgNuslT4il3V3lKxqB9ysvdoUBTc/vG+j1FFWVt nVhbguyZgIMwt0SGnHDR7epo6aQPAWYqYTmyNnXyeRgRK6Oh9AzJYk2ycmNbpQZkE845KBv2YsBx JrzRVFjJWWctGcO88vCW2Xsjc+JK9q9G9oaUQcREOPOiXZwYmNnLu6nTD4P36f4gZcyEIGdT+dbx IHdKGZ5VdoIIFxOsODGf8dgD/j975wFgx1Xe+9t736KVVlo1q1m2bMtVNi5gYxODHTohDgYMIUBI gMcLCSkvPAgP3qOGZoJjiiEYYpsQV2yMwd2Sbcnqve1K28vtvbzfN2c1Gs3dXe1qpbVs7nh9NffM mTNnzsyd85//9/++j1M2znB79+4FJOntGFeuvvrq6eMYnJaZ443NciKQAaZBNuIwKqNRxRnbuJda RzdjhAvQJ2OepnFHgMuY7AhmoO7ubkAM2A7XXOMuE6/rrJ6xGhABD3wMNHqhcsLXvxpXpt+CsbXx 1tFQGzchD8KqZSxR66Bblvrykz5u9YeYuORU3NJT/VlN3MPG1lfWCLRFYoIehIAACEj+AW06F/aC p0GpmEPnUspmUalohAYx85ik0AqjEa5EQ94mfJMIJuMEygR8BPl1eiTjpBVJik3sNYQLJk2SKG01 TS7b7E7i1onjtAAdQu7yzSF5IIFHWLYoB9og14FEsTmAGDZnjdza7AERdKh/uGt4BxHzvIFAJByB 9A2wiQdjLo+rVK1Eiu4SGbbJeCBqHnvN63SGgDPkj+TULPgnlYoWlMzOmhNYBR0koEVCzGjWJfon LuYN7HKSbt+ZgDK8Yurkueq2aRbhvsEdlKgw+kkRNwV3zXpKQK8wMyv17/0cF2WP8ehGtSmIxLiJ Kd/41bjOpklCGeZm444nsA4z8eUvf9m0I7Ih7HqmQhOU+eY3v2mqMOZXI7Abs4KxkPeXZ555Bt94 hL3cFUCiejG1sf6Y69ww4wnD58+fb9xlPCgz/RaMR5lgff/+/cataJyNXye/flLGbfKH02ueilt6 qj8rvTONlVfBCLQ2xZjMNSgjJhchpyUuL8qTSr6QT2drWYnBm7c7yWbAZsEe/IOxxuV0EgmGlAI+ MlwDGJxOdLujthsqEWEG0xIfsC/yD+sSgQZHIwVkiGUnwEHwi6QsgIcBUVltTrCUCI85goCrCqYo wFMgGGxtmz1/fsfhRCadzbqdLpfTVfGIU1JTc2x4cCg1ayQrsWx4eo0u0DpWj6fk85CqGwCDRYyE UWUgkwszltZNQXAabJN+CK5RV1NbV7SUKmh8nsgIzASUMQl+6eYtt9xi6qzRiYNNqDiZgE2Ix7TL DHzlh1N/FH4l9YWqxPQKDtU0Xk3TJqO817QLJJCpZEpfN27ciNc0DwXjXjfffPOYZhfTvGvcZYJ1 Iy81QTWeWQhrUAWNV5+ftKmf47WGuAcsMuZWEz80HpSZfgtjHr2+0HRLjDmL1+9lLDmJ42ZsdpLr pv6b7ltjI6ZNE9zSU/1ZGY/SWH+ljwCsCqcg87e2oJThDmfmr1TKrObL2JNqTAeZXA6qg8cWmIDn AswLsVgCxIZxyx8O28LWaBF1xUWIhwEt8kxwELsOGgbKQ1PjyCEkOVJNo0SkjgZoBMVIlgTZCrAB RxHSxUJuJNqAucFR3G6HgIE+jwW7gqEgsKdQQt5bSSZTcC6VciGRGJZYvqh9FQKSvAoVBzaxvI+8 DFBKyJZxboJTosIRDKO8l+Ci5HGsnnUyDDIW/D86INKpxjL1ETjlUAYXuN/+9remjo3pK2Sqg41p qlBmgqAdpsZP0Vej/pdDcO7jHci0aTyhDLufwOSnH5R56JOf/KRpWAjnQ3A5vY5xhW4YzXzE8RsP MRj3Mp2LcZNxHfUrdi5jCevEhcNNfeHChVjccA1DyWuqMObXCY5o1Pqwb70iRzU4/RbG7Fh9IaS0 sdDUPeOm8dZP4riNd4gJyk/FLT3B4RqbXvUjAIJgFmc+BzYwycukLvYYEAvMYwGDDY5BlPALxRWI JEggCMxJqF18HpfH6XQBVuw2ciThrAQKEOGu5kQk72rCxYgVScvwCEoRcxJsC2hFxCvgIVY4pih/ hQliVfqgUT+8npIZksVaomMi0ne5vbFoLBYN98fjDoe7u/sw/lKYmQpgrFwuk05Wy2RIwEqltaD5 WbtstQqOS+6yFWUNGZ2EIXLwj8TElP4pDMOKLHJs6UkDwajxmO7nKYcy4JgTeHxzWng8YX0Yj5OA tqmP9mtU4E53YE5of+Wzre9KGnB93bRi2mTa0VhZMxUbCya7zmgAWZLJpHEHFDlkihjv90M3jDYm RMHjKXiMbU5mnUB/JhyDBxNuOxhc9M6Y1DwTNIs7Om4+PFnq65juAXBSfR1Kpt/CmM3WF5r8yY2e /MbKPMWNPUcIrEiOkztuxiNOct10Z5ruW2Mjpk2mHY01G+t/yCOQzKSZxhkBpnLYiAqWpVq5UMS4 lE+mE4nUcCGb0QSzTPM2sAWAALSAZ5KXJJCYeXggEvGXnExiNxIKB9BAa+JdrXk6UyIABarmCFzQ vIjEQ0qDDrILC7tAkggnwgbhYyQEH9BJjFmKKCqV8XgKh4J9Q0PlapHQNYl4nBg24bCfQ9Fjgtdo KEhSSNIYdI/LjpkLDyyR+hJm2G11WB0uifqnmhW4UxXRr9YBnnuqG/rNQAld1L82VqY0AqccytRb lybZPy4zmXpuueUW6kMPcEMbVSkYKUwyUiyW480Tkzzi9KuZ9LmoYehVPRah0CiU4bgnLKEYr89A PcLLmlyv6R6v+CaewNiCafqZQIxs3Gsy62SwMlYjsEp9xJcJmBLjvmp97dq1+FLVl5t8/seDMuw4 /Rbqj15fMslb4o477jDmmsB3jMtHayd93Op7OHHJJPs/A7f0xP1sbH2ljEDv4IBM4Zh6BKPYKkSd wy5TIqoLZH0StYylVCEAHbQJZh1gjl3sSBhqhIlBHsM6WY7wt9Z2pwlwA07VQqgwQQiukdbFCxor D6Qs38RNmszVWgXAAn8K+QiywKsIJymFIVhFKON0SjjVWplyjkKSAY4EwvJ4mYMckDGeAlGC8UQS /a7SwMi/0D3iTC4Ju/nDrQkRspiNuCoCm6iouWkJ7MKzSYCUtkXrLGuChUZL5J/GMvUROLVQpqur yxT3FpUG4UPG6ycTrdE2j9+TgjLc8dg+jK+tzFgmPwgiyU5pLqQPJ0YXjdd5yhHzIlXWQ9ihh6VX 9TMuMiA9yhx7scsEM+4EhxtvE/MKwWyMMVqoCb9FzNZ6KsvYCAHxjF9x3iY1Iz9zYyHrjzzyiE6x 8EAhRYNJCm2qz1djUBm+rlmzpr4OodjqC8crIbRg/cACcBlw4y4mUsS4afotGFsbb33BggVgR10K xnXn6iNyN9aHktHHU5WTU1OtnPRxo9kp3fanyS1tHK7G+it6BPZ3HtToEoEymra3THy6MvkICkTg zVurZWu5BpdMuN5yuSL6XTCCuDFbIGQIeceboSxQKOwsehjAjfAbGkFTxoPbafVAbYhDEhCjShZr MSVJHZyS4HgwPsmkJ7yNcCoQJjgwqc0YpFDygntEDQnkEPsQftdNTS1Vm3skDVdkBdBwDLCIgCQJ L07HRjELB4Ixkt4ASkRTzHNTQyqQMXIG2roQMaM4Rr+I6vHKfnpJY+UERuDU0lkmH2zuQKAMserH W0ziGGK6o1pVZ2WSjPDoNyo60asS6u2452+6XQijwixy3L0mX4ETNAWSweHZlMmSMyKtprFNdtF+ PMayaa0Tn9fk2IwtBnckkyS2/hiXXXYZ3sJ6OT0nNjG/f72ElXXr1hEzjcA/akFLcVwcw16MjLER 3ZdbLwTHmBiI+t+8XpkVaC2Ar7EOKIEMncA4vRrT8Gtf+1r9q2ll+i2YGhzzKziGKMbGTVx9vLeM JeT5MkqhuVh61KWTMm7Tue1Pk1vaOFyN9Vf0CAim0BZ+vED8PBAmSyKBZC6XqlTQyuD3U8gXs0Kz VCv8fKjLGkQLKyAMZnynltmIdvgTEY2IYQQICIqAoAFeyDdNY4uvt0hopIK2r4YXtAQIqj5bqcwi 8GMUbXAcAIk0rjElgj44DNatdDpLISAGDyue2KAcvMJ98unCqQpVMo5OsDWodTQpDlhJLhSNc2jo H0mbLQWji3ZY+dBqGLccqdH4dyojcMwEM5Udj1+X+88YFY0dQDB6YNkx9+dt9dZbbzVuQvyrHuvs a5wAmAtJeUjgFkTm+EqAD3QuxLi7ad1EfjB3ckQmeISxMBYmtGTad5Jf6RVR43TFCZwpqQ0hoojg woAw/cMnGXW4EPjsMsnGJ1ONUTINO3vxa8T7erzdkWUQ1Zet/K4IRox1g66qyuhwYRGAOO3t7ZzU 008/fejQIWM773//+41fx1uH7zGafjgc1+LSSy/licDlg7r7+te/bsQltGMcpTGbxXt//fr15MAC ssBegN6MvB27HBcjTr+FMTtmKmSISKSq043cEoSQ4X5GhwRBwrBg6jLuAvTRoe1JGbeJb/sFCxYY j16//rLf0vVdapS8ckegffYcnjP82ImWS5TcbD6TyUHJ4ENE1iQRvODKhIEG7AF/gWGIiDKsCI6x yibwjUAXzfWIf4AOOF3z5OKRRR2AATQLztYEigEjiApYO5YMl7AjNlyvoVzYTWCGKIYhVWSF3eFa ADDgHoILayCEw9ay+Tx2KxpGlRwIBsj55HHbefFAoewPeQijRwtgFvCLQ9Pu0H/heegop4f7Vc1e IdifYBkOL63SH7WwLot84ZMa6nvj8wRH4BRCGZ7RppdvfGcm7ibRw0ipY7SMEGCGZD2YYJCIklfP +M6N8NNkTcDktH379gkOsXLlStNWNCUsFBqFOKY6U/rKWyzOz0yielfBWASaY6lvR1U2vXnXV5tS yZgnwvTJMl47RhTI+N90002kBNcrE7+ORf9qXCGR0NKlS40l462T8cDYJteO1NY8euQVR2KTj7FM 0GFqq7xdROdjGWNni4VrbSL5TNWm34KpwfG+co4Ig8h3od8SIBgAIkv9LljNSA2ml5+UcZvmbf+y 39L6aDRWXgUj0BGdA9+Bm1KhXEhnkw6QQzmfJaZvBYcjEaBInDq7C2YGeACEIcYu/s9Yxn0uoskI JgABSe5HmwSQEYBjd4BiJIRvWcS3hIkRkgVKBXkMxwGr1GoEmalVy/g0oVQhMTe2IHyjNESkRa0B u2DYEicn4U6Q6GgmKnAKEYDJJUkOJmtNwt1Jwy6XW3O3ytstToCVhrJ49QBTCXqi+TwoBihTZAdL 0Vkr1WyEz5NOCHCiBfzKJeSNXEppj3KJO8wfsEuaaCwnNALagJ7QnsfdCULFWAc4cuWVVxpLxlw3 yQiYzxRegTsZMxyq3gjvjiTZ1r+OucLEQB67MTedxEJsNKCu+vnDdAiqEaveaNAxVXi5viI4/exn Pzuxqoa+MTdPfEWM/Yc/M5ne2MqLio5jYIZMhhiTZtnYGuvkippAKw0goILObZj2VV+n38KYzY5Z yF0HkjNJkeprcn/iX2YsPynjNv3b/pV+SxuHtLH+8o6APxT0Q28Eidbr9/p8uA0JIwK3wSI8SBV6 w+vzglJKFYLNlMA4Ub93TjQYDvgcNmuZsHToWVi0ZI1M/+AbwAHIRdgbgQQi5YXPAWVItBdwAp5Q vKyK57YYqKBHiF1XqdIUVIitgvBYI36oifeSpoQRqkXIHast4AKMFHLZNBCKLhWKRfEJFe2NHY0P cp6C5F8qkY0JQQ5eVHRNogfTJWGLYHOEKdLMW5zeeDDlaLlG0by81+eVevRTBWWAIKaXTnAM/mzH HScTlKG+Lrj5wAc+gODDFImLCgsWLECS8olPfOK4jQOnvvGNb6DXIQnUcStPpwJmox/84Ad0CbtM fTsYRDD3UGGCybh+r5ksIbf2XXfdBSCoj2YGPqCcznM5ptSlD33oQ/BV9VF6+b2TlIds4TRoJKjQ Qk0QZg0V8+233/66170Ov2VjNyD2yAn1xS9+kWttLK9fn34L9W1OUIIAGW9z8N+Y9x5YAWjFzVn/ G5n+uJ2U2/6VfktPcGkam2ZyBEhGJFpZbDMwIdWKKGMKQmSAZ7DKEBEPMOIP+IkboyGPKlTMrGig PRbyu10CDLRXIELpghjYh7mfOQwWREsY6QDLsApCAWrgcATDw8EwRrFZ+BmOKk3YSyVQDChIMhgI gaNxOOKEJH/gGLyepKrX7mgJBe2Vcn/3YUkeSQoltyOVTtM8VGuxXM3lS6lsLptHoiz9ASlhaYIx 8rpcXo+k6RaVsviM0wfBK/SW42v+3xxXLQAd2SibRksa/5zICMhlO5H9XtZ9cLrev38/omBmI7Lu Tay/Ga+ngK1EIgErgLKMFurn7PF2nGo51oS92sKcDXZZtGjRcWfZqR7ilNYnXggGJkabUQKIkBng xAZcdRIjCwZE8i4Riw93epAHSg6eCxOfAhfrqquuMtaBq1O8EQ3SPVJJ0xqAYLy+Tb8F49GnuU5n 9mgLUQYYAaDteN3WD3Ri46bvrq+clNv+lX5L66PRWDnVI6C4VeMLzH/c9VMwBYYYAsmMJIb6+3qG 48P5Ur5YLMCn4G0Nc1IuVHds2z00MGItlz218gUrFi2ZO0tDHbg6A3LcXpc7HAr5vYEQztIOB4SK TVJABvDXhuaR1NYuNyvwN8Aah0sgjtRBvksFu+SGZC/Ag5jjsUMhwaFIoBGfJb5L9F+InyJCmcJT z6+76977ax6/1eUFsNDDs1YsWXPx+aiWk+k0/XZ7nZGw3+dyhJzutkhzzBtyWOywNelqNWG1kn8y brUN53LAprAv1BqNtYZiQa8/FAiU8gUehvFEklwJcjjpbe36P7pRvyj1o6dvaqyYRuAUamVMRzqJ X5H6slx88cXTaZOJUM2F02lkMvvyns0UyzKZyqdhHUx7LEh0T0rfeIJgejuu9W3yx6JBNFIsk9/F VHP6LZgaPO5Xbjxk4CzHralXOFnjpt31Ejl+Ossr/Zaezrk39p3mCAwM9gMsmLfzhRzh/4dGhjP5 DIwE79RgCxQjwAv0um7cnmvD1MPEE45ESYKUJxAwBiOULkSacbhqJLt2uW1Ol2ZisoD1i2RuglWB gCkPJaaZAABAAElEQVSX8HJCckMyJCxKmKVgagAq4qHNEbBhaTyJKGM0mbB4YANioFXgicpAGTQ2 gmywEHmcnvnzOmKxSG88jUEKVyvoFhJB4XaN9yt7aLsK4wMAEsGNqHvFeQpSh4HivLST4oxlTf5g gOTz2IWCurJjazS+HWcEXpFQ5jjn1NjcGIHGCDRGoDECp+UIdHYdECjDtF8upsk6nUmxPqooQR6L 1Feb/EPkoK6SMcmBpcjp86G/BSSghslXa4VsIVOsxjOlRLDYVLQQgVf2oEHwStXiEamM5kvtxlpV ZF2MtsjySnmQCRkgUdYgbgEUQdFo1iiMW5WieCohBJbYd5p9CfcjEI74cofCoabmlsNDCZTCIJVY JDy7rS2N31U2m0il8b7Kl2B9KnmnvUTom6qjnKsgWM6VS9lqLQ0r487HLZZUsQRuqmTKNv7NFdNu T9YfIHbO4OAQeZ2sCJsZBZBRrWbUCPb19Z2W13CynWLweQdj/KGfWZ/sbidUrwFlTmjYGjs1RqAx Ao0RaIzA1Ecgl5PMdEzbGo1SwO9HsRTwLfgvwW8AF9DTNocCIbczMTLi8EftHn8SS0+xmkql+/sH Usk0ldHC+H3B5qaY3+8TIqRm9fk97W2z0Aq0NTcH/YFIMAjVAj3jBarUasUi6ATwlCGi73Aimc3l 8UVyuj3IdulSsUDuhFy5WoqGwtFIiExPmMBGXY0cbo/HD1+TL+agblqaWwJBf6mYAXtobti4TOE7 hUWqVrJYS5qBCsWOYDXEP4iRMXFRj3kcgkhmc/lfwJwAM/7Vzl42yPqrbOEECRTEQvRaIpBN7Icx zXNvQJlpDmBj98YINEagMQKNEZjsCBCaBToEEiWXz6KlxRVbcI32p03rVmS2reGQ1+bodDuShRIx 6BLp7OHeQyQ0SMSTqTSxM8A/uGK7M5XskIStQ2nr8Pr86HgPdvdFQ8FF8zvakSDEmpHdgmzQ55Ji O1coDyWIApHetXvXngOdyXTGanOEYzEcviWxkxMfKOAVLtQFsNH8eXMXLFwAGCKicNXhzCPrLeBQ RZKFctDvBe2ce/Gb2xcsd7uP41tw3EE5a+VEVmajxui4TZ2GFYAyhAfD5wvzH8F4iNx26riZBpQ5 DW+ARpcaI9AYgcYIvDpHwCdR5jxExLWnrDgvwc0gSqmUoGKquFWjMnFaq15bLdF3OOy2NwXddkut t7+PvAFOIIc/FPYE2Qkv6BJESxnKo+pCN0NQYKsr6PPUXI6C1TmYylqsQ4lExuNyzZvTbvWEMoXi wQP7O7u6EM1kCgVPKOqNtlrJtwQYIfOjpUoEPMxJdictlEYyqfjuvb2JlMNmKWRzCIVxXrLZnfht n71yxaWvueJN7/oQyuNX5+U5qWcFcMHHBSdTfEdAM3Azfr//pB7haGMNKHN0LBprp+0I4OJ0yy23 GLt3XKcnY2XWp9+CqcHG18YINEbgBEYg4A34/H6gATYYUZwUs5AmcDOix7UQUK5iwckZp6Zdu9sC /kpbU6JcmdPSEg26R/r7S8WcrVwL+P02B85EtWyxjJ1IUEi+ls8U4uVyxB8oR4IFqJumMAxK5/6D SxYtueaaN9gcrsODA26fs5zN2GrFbKHQPxwfyBUShbybFNbkdnI5g34/eQeIDwxDRIWdW7YSmMZV K5+57OxIMHzZxWsWtMxa0jHn/Gve2MAxU7ruABochMlIiOdjA8pMaegalV9tIwAQ+ehHPzqds5p+ C9M5emPfxgg0RkCNAPoUt8tLGF+Hw0UUO0w3pRKuQCVyKxESr1AtEe3fWrFWIEU8rnAkmBxOt0Qj hXTFW/KjiwUDYeqp2pwWUjwms2SiRGFjB4j4fH6n11Ym8h3K3GgkFkln01iyIuFIPJEYGhnBnYlI wLGQlyjDxcGEPZ+p5rK4fmOWwne7JdZENGGnpeJ2WP0BH9rc1li4t7975ZKF81oXrd+xc9Wqs8/p mD+8Z09Lx6LGpZzqCKjoXxAzU91x8vUbrMzkx6pRszECjRFojEBjBKY1AoRwAbsAPySfkoh/Ja0S YeswLknE/3KJIHMFIuiSFtvqKKJSyRdxT8JNyV5rSorg11rOloYTQxkch5xeJCzDgyMdCxcMpUec MRdCHILudff2JNPDlWLhwuUrLj9vtd3j7encb3fUmpqjNjyone5QJJIulb3FPHE4HW5/vlhB+NuB MiUWDnhtYeQwAf+C+e1Wx8q5c9rtFu/u7h5sYQXC+ZUrRK0xnT+nsf/w4UO9vRI9jxjAo2Jeeo3S V9S8kgpBPL81MTC1CVhTqkpcPfKBZzOSJ0EC+WmBiIkULLkQ8B+XvAvlYiExPJxOpoZHRrp7+9rn zb1gzRVnr764WMhTxevzBLwewvGl4yOZeOJQZ+dDjz543urVV1xxRS6Dcc3tc3mI0AfLRUgzusEf AyxRiTHL8U1CJENBaQ5fsrkKqiM2sbBjXJFy0VnK1bLxUiYF7UX+zLLbUw0EkwTLIUaOxeZzeZsj 4eZwzOv2+DxeogTt2LadBucvWLRwwUJC+BhHSUlk1MgYy0/iegPKnMTBbDTVGIHGCDRGoDECE41A NpuSKd7mKJXkHR0vIb4wvyLmJWuAo4aJx0nQGQfCGAxM8TisDQ7SbocT8oRouvF4IpdJl7I5jD4r Vp5zuLvPZ3fZSqX2lpbXXLJm9/a9hzq7LFVonnw04JvT2jSvrblpVlso7H3s94+F/YGWudHOPfsy 6ezKFSvCw4P9g/2uSBPO1V4YmVpl08YN569a0bpwbiQWJRKf0+sjW1M6lWd+z2TTsElO3zGxxek/ +Saf2LAhgYhYi4ujJbSU08cvS6AMCIFsBoJmamA2QW0SsQYoUyK3FG5T+WwaqxlnlE7GPS7nrJZm sF2RYMTVChnDkyPDB/fT2wz00kgieWDfvufWbVi0ZPmFF13QN9Df2tpy5rJlQZ/X5bBt3vDSgd17 9+3cnU6ktm/a3NEx/8wVK3AaCvh8BA0EyuA9JH5c4mFODBzQEk7u0k3BWmTilPCBuL7jiA6kYSFg jjhjAXZIPU6A5vIRV2rgiCASccPCb0xrSkCRpGdgN65OMpU8cHD/mksu83l9UmmmlgaUmamRbhyn MQKNEWiMwB/8CKQyTMxOp0smP7cE5vVXMxJtl4GhBByDzNYfDpabYsVqNZfLgwawRtldDq/DzXws s2el1hyzR6JNYa8bXyO3QKDq/EUdzmI54HRFAv5iydYcC2FLijRFyKpUKGRmNTetPuc8l8dNjN2m llnYtkgrYPW4zly6dCBdctksl110EfTFvogX5gW04fN6A5EI7EihUOagOGYTjNjhdBOLxngBOe6j L24cEZUx2Q+04HcKvABgIFlABXRX+luVbE0kcCqBD/DdthQrRRIepJOJXCpdLRVGBgbQFB8aGtiU TpIzAT8trGGADhI84LWN6axSKdaKJXZwlqrPPfG7tU/+fv6CDkLHp/p7+vt6XXb74c7ONJ5C8eRI 78B+t+tF+9pf+/1Lly+7+JKLSZ4TjoaDviDMDP8JnIKAAXxAcLEIIpHug2SAPOJhTpgf+JkyDI0F HGPzeAQFkftKwvaoCICcwZGFNWlldKGUtWQi/tRTj1999bUk/TxS75T/e8yFOeVHaxygMQKNEWiM QGME/oBHIA8XUS7ZHCQWcGAeqVSClXIhVZKAv0yDDpfTCphxuQLNTb193SOplMXlEzONBFuzIWrx uKL4SKeSGaLuOiwVr9997lnLg6EQ4KNUqhUy+WRiuLU57HZawn5vayzK/AuaILVjx9x5OD2Rpmb+ GUsGBwaz6ZQ/HL3cFypZam6XJxoLI/idHVvjtNfQ/8LHVG2IgIkKTKJtQEUxHc8DStzHOuDs7Dw0 lKTngmOgKJjpmciFtBBYA/GBhlni7JXEybuE6JUANnwBxJWqhd6ew91dXdl0eqi3Nzk40BwO+1zO gd7e4aFhPM3JtE3yJvgSL/YbpwsncuFNsMFlMn6rHT/2/s5OW6mQHRlKxOPJ+AguWEh9Zje1cGi7 07lrz+6abai3r5dkVddc+3rJN1Wz+t1ucIpY8eCFiEao5YYSRMlG0l+KWYu+M9I2SeftsDlxQ6/R EyCQRDEWICQcE5dJTlZ4JyFzVHRD+aYvrCaSib179yxdsozqM7M0oMzMjHPjKI0RaIxAYwQaI4Co l1i7JY+lipeuxRIgXzXR75hfc/mCgBmbrWy1ZPGLdjvT2F+KRZvdI9Ot0AY2SIJwIOx0uLJpRCY5 LEBeXwBex+P1EJ4umU0UCLFLKLts0Q3k8TT5cKFGwcsEXiNdgFhUYBXwwXb7Avhxw0zMj8Y8LrCT y4UCBuqllC8Vil6/z+p0EWpY+iPptfH8LqaGU9lUKhgJGy/hwcM9jhp5sMVKIyhAZnk1z4NjxFLD B+yKDVFzueioll3CeEhX8qmkLZdzlcv4cA0dPpRLp53l0lChUCoUiHEDe0OsHI/bVcjnWpqaM1kc qgqRaJT+CGvlcHT35jBFpeOJ1EgceRHDg7gmn6taw1YCKI8kEghl4LFsLuemDRvy2dyqc1ddsPp8 T3NMWCIIFkAXf0h4SKqJ/pq8m4LaSMbACcA7EWaZ/gNsSC+OeUxQihbxj9FDJCNXQ1CNkGXAK0kG wboGdATOsC7/WyydXQcbUEYbicZHYwQaI9AYgcYIvLpGQJvtxLQh8RQIlJfLEN3F6XLjVk0ua4me Z7UWKmWfw0FGRuZJJzOjJLCukQeSesEA4hB/W7NbLDUWJxhHowus5EEg0p3X52ppCjnKZa/N6mU+ LlUdEjrfA7VCI4AVDEvIRhzNUeiZYr4ANnLYKsTH0yZobFheDoFnNkLZfEXIIOZ8/gE+sD+EijN8 TFiUQibpg7aRuVujYrQJXbgL7ZJxUMkSidzEZiEJZRHfKCuKHNJY2uKdqd7d+/bs2Z2Ij5Aa3MPW bA7ExICgZZGwgaVqsK11dnsbUf9zpSLu6/EEWSmtAX/A43QHfMFsMtMxr4Msv36Pn3PhBDCBQdFw QMx3sWgsHo8DSpqbmnZt3dZ3qHvzixsuufSSVatWeXxeiQZYldQNUEcCRIAtQgLxCVyUrmPW0iTB dAOzmybPFpUPnZOcVlRQkEXGhr3J9X2kRINz2hcxMyWkrZlaGqzMTI104ziNEWiMQGME/uBHABZB TD5iexGihUC9LC4JVucmMSTzIlMnEySF2H0ctjJ2FnIWWFwE+635nD62kA6APT0uvKe9wAKmWGZW ez5ftGdjfq81HMwjocVbp1QsYt5xupDhMA87QDvwK/kydIXHF7BHAqWiFzmuw1nFIoNHFceukJAS RayW8FEC54k2RBYsRF4PymMtZ5PhCjrBRqIGUZSEABhYHPkH8sNqgSiSdexMVntVBLQCIcBke/bs 3bRu3eGDB1HxWEslG52r1BxIfjhtBgTFCniuUkkkk/5AcHBoGE1wqVx2OO3ojjPpVM1Ta5s162Bn Z293L2FaRkbiJfI8tDaPxJNgwmgkQj7MvsF+KCZX2ZUcsZfQG3mKhw523j80QN6o11x+OdH+NBAD fgNjaYsm3EX1SxE4RsYCfyY0MqRikDTh5AnnVIR4UgsnKryTLKPIhs7ri8J1QvvM4NKAMjM42I1D NUagMQKNEfjDHgGNCpDkiUyK4BWfzyuJHmFHwBRaRmq0NJAibJ/VMisL5WF3Ay+qJRVEz46hyY1g xubGJoRNRMgQqlZqrmLVZ7GlsExhyrFWoVbK1koOPyCH1QuGADFIfgNboZgdGUkHozE38fLQHjvt +OpUa3baKJVICAWLY+VPjFE4QZFWARxDYshMJuzyalTGsZFRBBFoNAVnw6QuH/Jd0/zKbM93ycLE ClhGcmNadu3aec9dPx/qGSS6jQQQLhNQRxrhA+TEgNATfJ9LuQJnBrMCd9XR0bFv/75sOkMmS4/b W2YoigWv2zU40NsUa6auaHnw7c4Xkqk49im3x410mR6RxZHOg1LES9xSQ07U39MXHxrGP4uusCgq Se5HjipGJLG/0V26w2XiAhVLolYGSLG7aHgxQeE4TmW+c1Fkf/5kESvUsQu7q00z89mAMjMzzo2j NEagMQKNEWiMAFNl1WEngxL6DOZNAQ6afclD5DuUImhSbbA2TmvR7gg1hdsKyd6BwZq1WLYFrITD w4iSznprDosbEIP1SPgYZ7VGIgPMQNAfJL3GW6gqXIcDqOKw1DyVqh06huh4pERwOj20Y3VXCwJR LHZJfVArVwAuUDVwHgAqnIbgJIQyYk7nkOJFZHMWLe3RJvBVyVoyXsK8nIEofLUPwTIyo8u0zn8C D6SypNoW4Q0f+w7s/+WvftV1+BBaZFAL/tjYt0AEWHYIFQgVgjCYJNLwHZja4JCymWwqgU9Tua25 ta+XiH29c+fODYdCA/0DJLxEIkQmTLRC4r+dy7hF7eIfHBhobmqGDuKc0khw3E7YrWQqReO93X04 S8dHRm54y5tbWptQV9NX4IgsWm/BKIpgovPAHNiiIq5WhDAkMyYjLbSRwDUNwYwOA3tqf9KAnCsV ZDRehqUBZV6GQW8csjECjRFojMAf5ghg9yH2m4gzHMyXFSLX8YdxyeWyF4oyXdZwfrZYfKGAs+RM jfg8WH9gXcQRWNPfQhOUCnZiz9hsLnAMC8iIwC2Yc/AgxjqFhkY8j+BtMAk5mXiZjPEaYrTBL1AU Hg+QRZIvIXEta+YTJmF0Irhq0w6ggKlaaWIl6A2QqVaOhIKLFy1GyJMXGcnRJVXAZVlmeExSlLIG lzE6qdMkaEhEsUJ30OJwf/+TTz+NuoX6mNhQAmG3qlRwHBIbFcCF8HgADsRA1jRSYfa2onvGuNV1 8GBTLBYM+oaHhgb6+0ELhNYLBVA7Y5dz5rL5OMFpyoh/baGAv2C3JUaGXDAzbnexWGyf247JyuXx JAaH4HKa2meTWvy+++694YY3zuuYx3EZE+xb2oKpTpgYQBwwU/6hRW3cRDKNvhcDnIbRKJaNnJqm ktF2kZMeRTD0TwM0nPjRkTr1aw0oc+rHuHGExgg0RqAxAo0R0EYAnIDLEpYfmxXJBuKMEvIYOBqP 214qOIqVWsFWypCI2uKiot/nb2ttxckJmSoR5orEnUWBga3GYcNHCV5BIrupOResAxoAG1RqefS8 TrfXH4BsEWpFQIatahNTESyEFjJOQtHAvrg8eBEBUST3EhOzwCAb+KYIOwEKYVeAEChq+Yqlixcv HMlkTfqPpJitZArnE0KG+ZzdoS1YQ/EC6SGNwPvg21wpb9q+c/OmrUAYS16SM4Ah6DrEB7QN5hzc paVvdpJiBjgrUAgYDUIkkwHXWEi94HQ2B/w+MnePDA+RPLNcyPh9nko5X8omPHYL/yHbdeO05PAU izmIHJczwInD34SCwaA3kLUngU/xkWHOdGiof/myM+bMacNnCZjFsTlxzH0omDCNiVcS0iEJ7Ccm uTJuTCAeDcpoJ8o4iaAIngbqB4xYIcahgB5gjwAf8dqCpBIT4TGw71Tf/g0oc6pHuNF+YwQaI9AY gcYIjI4AkAFXoHwug44WdyIneQHcjnLBkQMFCDBhmrQSrDeez4UFwVQkJEoNpgYpCdIVgRfyJ0Yd za9JufyAc9C+4kpN6Nx8DmeoUDhKZDn0vJoIxwVyAOQQXB92xAIt43LLtAuSIEK/6D80PMLRASPE UhGhyahxSA5ds565/MxoMJop0cwxBibQkczgTOCiEQaKYEhCdiNTOPwP0mWQgUXImVImEd+5bWsm lQKd4Hmu4I4wGYIBUPpy3laGBVdr/JhCkVh3dw9B9bB5uZxuCYfMGJQr5CgAv9E2dFOQnAUeDxiC CjSTK5TzhZLdA9VktWWEWOLcIamQDIP4iGcDNuPQGLAIG4g57qmnnlq2fBnR87SmpR9CxzCoGtcC NuGbnJlolsV0d3Qx3MjCx2iLoUxWtdE0lZ3yrw0oc8qHuHGAxgg0RqAxAo0RUCPA3M6sz3SOg5Hm siSuzuSYtNuQ6xZFVSvO2JVUrkxCJTvxUUoVJn8MITANSFzQywg9Uy3Z4TNAAViARLELi8F8nSXg LdNvmBxLkZjXg4uT2JgI7FslKF8RyIC22EZLhULODQfD9E50GZEOYynBEVnkMQIFHPhMFUAmgkdq 7lol7Xf7wAHgHpJDGa+jV8Sz7CE4gNpgAbEmAbNwArKh6KF5SCji/td60bD0dGPiEbDEeRI6V3Ab 4MkO6aLZpoB0bvy5aAnAAg802N8fHx4CqlGK5QjrGifvsFUJouP3eQkYePbKFTQyPBQfGBop9PUR Si/Y3Iqb1dDwSHMk0twUS6dTpBEYJiU4kMhBbs4IYMvv9TIU9GtoYICMDQ6XOgdADLkMJMgMnSIW n1jKBOExHIKjOBGNSCqDz4TiYoMGKY1QZhTuCK7TjE0C8WZuefmhDEh7W2eyL16IZ0p+j70p6FrZ QU6vSXXs0GC2eyjfM5Jn/NuinvYmL58zN3jjH6kvnt/dnR5Oof2uxoKuuc3eJXOC41dvbPnDHYH+ eH7X4fRQqsg9vHCWnz+vW2znjaUxAq/KEYA/wKgEusjnIF1AEEALgRTyKi9eNBRK8BIsTekC0WVI veQpsAHvHtHP1iTTJPQFWYwq2HBErCGxUNAAa6mMhHWIRopiZaIZJm74jwqCEhqsOor2mouwMZTT SBHJLesanyLBbDCUQNjI9Exof4mHW6qVkRGXC5jBID/sBVINFLPdg93GixJCWKzN18ApMRdJa6L8 1VbkfCCaEM7Sv51bNvUfPlTO5zEjCTzAHCQYQf7oq1hlrFUYJPgZpwtwUyrkSgGfx2GJlIr5Ui7r JfIwmMNSC/gIKuMFlJBLsmPu7KHh+M6B3ky2EAmFmlpb/eGmrkOH2me1zJk1C9enGjtnrE3RKCdG xsd8NkvsYCLmRaLhTD770IMPOl3OM888kzwSoBcWMdhJxySDAacicY41pMZJlRh08l46CQUk5A3n qzkwidBGG2e+S7ksgmjkU9VUZTPwOSnEcML9SOVKf/z5Z9j9c3+28jVnNpvaIVf7bb/e/8iGPgC4 cRPP9AuXxD52w+I5MXMOUlWNW/TJbYO/eKJre1fKuCPrqxdH3nv1/FULI6byib/u78s8sWVgX0/m 8HAOMMR08rpVrQvbjomGNHEL+taX9sW//+t99R2j2bdf1v62y+bqNSdY+dd7d//3c/KbOWdh5Ot/ fs4ENU/Kps/8ePPancNXnNXy2T898wQavPupQ999cO/kd3zna+Z++PrFk69/imreddddL7744oIF Cz784Q+fokNM3OxzO4Z++OgBcIypGsD3pqs6rls9S3skmDY2vlomfqq8Ogbo3nvvfeaZZ0jV/PGP f3wyZzQwMPDVr36Vmh/5yEfmz58/mV1erjr4DKNpwRxEOkWfD2iB/tfOTKmgR5HYtRaLE66iWk3j PwMr4oGVEHGGuBfbLMT/xVcZxFNBEFsjCI3oOAjJC9HSP9iHK49MpZob89DwUCgYCvqDGagapxNu R3CHJDaCJrGI9kZQi7ht2+1eUX4IrhEBCOhHYAjzNZAILS4mHbdYxPqzfZ1DXcZxC7plAtWYCUVE iIqWEroAKBIDGC5UTte+vbu3b3wJkbJM8BYbUIldUOoAwsQBW6M96BWBb9i/lEumSxIuL08C6lK5 KRpuaY3h4oSXNR1qb5vtJgaPh8g4PpIuvfD82sPdvRwTZS/xX8KpEWsuF3ZUXJV8BTNTLtUxu42T 6ezpGRkZgdrxuD2AFbrMORPC7vm1a5cvW8aJ0i3pD4cREKPF1dGQCV1Fm0xnBBsCGeVc1fmyImYy fdEG4QiaMY7RTK2fWiijXeaxT+XwUO6ff7p1b29GbYbKmtfi6xvJ53H8qtSe3TG06UD8H961Ys3y pvr9v3Hv7vvW9qjyaMDZFHRnC2V4He719Xvj/H3sTYsnCRogK3/y2ME7H+9iX9Xg3p7M09uGwEkf uG4hk+6UppM7H+/894f3H2mJJCBOeCZ4I1ruHcl/+/69G/cn/u4dy3zaD6D+vFQJ+d8ffalfYVyA 0eHBXHvz2JBuvBbGK//CL7bv781ceXbLe153zMNOuzsFaI+348Tl7KYj8olrqq0neJjjNT3e2Y23 38v428vky9+5f+9DL/Zy9wJZVswLLZ8X9Lvt+3oz/P36xd7/e/fOe9d2//UNZyyfFxqv/3/I5VO6 316hAzXV+5P6nKn6PJ1PWSLg1irZbA5AUiQBZACsQvg7yXJIWBnYEeZ/oAyIo2Kr5uzE/BcJrVcS AMB4iB5WPJa9XlQpjgocAs5LVqKfkLk6z1IsoJXZtHkboIHkRbFQMOz3sX8lZx/q63/phRcIFXz2 2WeHQmGMNGVLLZvN4hwOIQGmUCYmBhB1MPF2ARpFYu46C8nM0IH+4WIps7Nv50A+bhxb5LIMusAT QSkiEha7jHYZwElgNCZ7aJgN69YmhgYwi6F0AYoJfnKS/Rt0gMHI5pVIgBa3OFUBJDDyMAYlh99e 8/glNiCgpGAlQkzI5wv4/bNbmvG9gkQZHhlev359b28PZBUWKlQ5mfhwJVlAQdMSjvqdlXQ2v2B2 S9li7RtJ0rATa53dDqABkAwPD4JO0P+GwqEdO7aff/55bKL/jLx0nx5rhBZAjoWadBWcA/rB30wo MEnIJDea9gmcEUTD/5y3NCJSJk0DLbht5pZTC2U4q5BPDkHYZuM5Pb9r+H/fuS2TFyPhWy9tv+zM Jp7mcGjgib096U37E7ytsvXvf7wFiuV91yww7vsfv+tUOOaipbE/v27hGXMCais3yK9f6GVHDFWQ BJRDaRh3HHP9O/fvuVdDRecuitCN2VEPc8nD6/tAWt97cB+RgW56bceYO5oKOfrn79z+1LZBytVb 9VnzQ3ObJct5PF3c0pl88Ple8NmTWwdhgL703rMnQCePbxlI58qMhs9tx+7wwAs9H3rDItPhTuwr JwV2PLPjJM+OV53dsuTIVdA79o3/3n2wP8tU/b/ebWZ6WiPkXjn5yyk6u5Pe0V2HU//4k60DiQI8 5d+8bWnIx0vf6MINAzf27ivn/cfvO3/+RNdf/dtL3/qLcxto5sjwNP59VYwAcWRxuMHDBU6iihOy lqu5Stahingl4zwj5AsEAYqOcp6obJZqQSgZUdIyQYBw8gUUrgUiBLOrJAwS7Use1x6sR7Vsra+/ D20NweV27dwR9Hhw9omUa25vCIw0f948/LDBByhhoV1Q/xZdLowwxIsjUg01hWOQl9oqhweDlKrp giWZKY8MD8eLlWy6mrIQbdiwpAs5mbuZutXkjcREkRaKuRCew4ola6C/hwnQ5fVk0hk8wwn/wg5Q HNgftOd8LeBxhf1Ig1x+IgZ6vZiSiEtHBSZQMALWMCxpTdHIvLlz/T6ECjYQGFkng/7Aa6+4MpPJ krMJGxniGEctC9BzERjYBtFVjadzfSNxWzXvwH2bUIAVOy7aNEm8GelmGf8qa39/H+nHSQROlzR0 xXAy1NVKsUDmSXogVifpiFX85kE72oIwiAsCYBFEw58RtUhd+V/KZ3A5tVAGyct//9NlptPJFStf vGsHSAVEzaP8utVtegVKlrYH+Vt9RuRvf7h5MFn88W8PXrAketb8o0m87nnmEPWXzw3+y3tWYlnU 9yV51o2XzFnaHvj49zcCLH706MGv//lxoAych8IxN1w0+xN/vARETGuXndkMuvpfP90Ku/OLJ7ve vGaOH5Pl8ZZfPXtY4ZiVHaEv3HwWfIy+RyTgYtK6dHkTAOuepw8fGsx9/b93f+UDq/QKppUHX+il 5IqzmiN+5y+ePMQ7+gdev1A0aafr0hJ282fqHTiMEn5SYETTpj/krxhVP//z7UPJwiffvOTGi+cY h4KHgjwCILOd9ltev/DMeaHP/HjLZ3+27ba/Pj/oPXo7GXdprDdG4BU3AlYMHoJkeNryzq9pf0Xr wkxKKTFiSFQNA4ByRcxIZAASrS5MBTBDCy/D7Atrgs1DKASmUztgCHBSZAIOhMJgkOFEom1WSzgc RFSzZ+8BpMKt2XLz7DlkIwpHw1hF/B6fw4PXD7DI5g8GE/Eykl67S+w/kDHEd5EZGl2I5vQETHL6 qmUCCVdxBHLZM8fIfruHhzgR7ETql8uvl1lfKAr2x4EJcslqy6aShP5DbEs2SiglnJBwB7cUyvzM UcXxJhP2u5tCvigu04FAjKSR4Yjf7SGXA1Jd2BdOMZXKQOWga8FeRsAY2ibBZFNLSyxGzGI3h6O/ WI5IP5nNJyXiHnm3s9lUOjk0Eo/09h/o7iVOXtFiL5KyymJhokTtyxjmCvk5s2cTsUa0RJw5OSyh lcTrXQIEYlkiTQMyaQch+BheAgnKrSanpoEXPrUYOxpw4fwJ86NIGaqxSSprT7MZuz+PP0mf9K4g rRhJi0vbP7xr+WtXtY7Z/qK2wHc/uvq9X3se3PNvD+371ofPU9V481b7Xr6y2Yhj9EZ4hX3dOS2/ frFvR1cSeK3xj/pG84rSo0Dsf/j6RQrHqBpgl0+9dSlHR8QD+Lj56vnmPY/9ns6XeY2mDHLiax88 xwWKrVto/2NvOoMLfPfTh1/cM8Lf+WdE62pZOEEAFuXXrp4V9gmU4Xyf3TlUrzSq37dRcvqPwPd/ vR8si2pKxzEb98cf29i/YW98IFlYvTj6kesXtUY8P/3dQYRi77x87n8+eegrv9z1v29aefqfWqOH jRGYzAg4rG7xPMagTVjeioUAMuIzhJ7UysztCpIewIlwBiYi6yqWHWW7g8e46FiIQIPjDO7YVdHK MH8Lq+PAWAOpkCfsHiyNq+qpWQNUgtRx+1DJhEKR6Kw55IgsgHaYbR2SL7rk8oq7jjykxUnHHw7n sqJzgGkAGDF502aVxNk4IWGaQrnrrjklFnFNOA0cmwzLvkOHkZ7wn0SFoQXQkXwK2wEo85IXwWaL Dw/m8lmKcQVnekcTBBLDRARE83mdLc2BlrAv4HE0hYJtzS2RcCwcjARdATCKaIAR4OIcLntJkije dQQJCXqykROcf4UlqZJeCicjRqiWt8UQERHdGCFSPpOORVMerxc0snXXzv6e/oqHpOJWpz+QSabA MZxcT0/POeedw0uUADic3UsW/hddNSGSLVX8s0TwLMcFdzLgHIG+HCFmpFMyGqJdHl20oZF1DcdQ eQaXUwtlkH3c9ZSQKHAMSGFYSWRKMOesIK0dD8eo0+dF/4aLZ/Mo33Iw+fS2QcgSynFZUlvHhAtq 06UrmjBRsd49lFMHVeX1nxizKLx4eaxevMJEAhUEqvjtxv7jQhkkMsmsKJexRk3QMalwVQc8EKQR 0uDv/eVq7Zof06+HNEqmOeQ6d2GEO2TBLN+BvuwDz/fUQxne7EFs7PzGC9sgfo5pxWJZu3NoT3em OeyC9MKd6tEN/VTAqMEnrlUY6Vg5Z1HYSHepFhhhAYKHUvAH85p9S9oDb7pw9pioUdU/4c8DfZkX do9wIIxoGOMgbyC0iMNpapCnw9pdw09tHewZzjNu0YCro9X7htVt+pWd0tmZGte/Dg0Nbd++vbu7 m5W2trZ58+YtWbIkHD7KBW7evBllJc+OK664Qj0F9X3Vyrp166BtW1pasMSbNulfuZ1++czh1rD7 lmsXqkLIvG/dt0eJlJBVPbN9iNN51+XzfvJY582vm4/99JH1fSi3OHHepfR2WNnXm374xb7u4fxQ qgD1FQ26LlwS5Vc2Jn8zmcpg6N9vGsBNlKPT/p7u9P3P93QNZrljAVjq0Pyc1+4aQqfMLcR1wYYL gXrR0qjp56PfmX9y5Tyeaev3jmw+kNxyMMFrKPczUq1l7cd48z27fQirLmbH1583i26ghqZ9Tm3h LB92ZxB/PednHArjemd/FhsuJSG/g/u2/velKj/xxBO81tdfLFx5X3jhBeosWLBg0aJFxpa5MTZu 3EjJxRdfTA4/fRMv9Dt37jysLTzo58yZ097evmzZMqYivQ4ressXXXRRIDBqE9cr7Nixg3uP++38 88/XC8db2bt378GDB7u6urjfmpqa8EA566yzxqt8GpZLoBeHg+kcM1ERnxgyL9VIPsDc7vK6fXbC vVUqzMNYNxD1lsSvCFKg4nAxuWJdEimuhMLTGAHW+JbHxVlIgxoGG+xEjHsAnxyPOxZrnt02e9as WSJhwYJkdyGOhRHCv0mcoLGhoMaxa7mqXU4RvoKoyAPFBCwCGByLNP2OAC3CDRPiDlqihkTYOKRO mFT6omlHKEeJzMlorAQ2KnslTwIGS3ygz8EGVC+EzJEcBsTqszid5aDHNifmb4uEILBxVgoFUOWG fZ6gx+GR7tEzuCn+6BTKZC1aneYpLQpgiRkjDkcuRgD5LR3j7HFT5yQ4DVBYlcRVPmvQ7p4H9vH5 sMql0vmukYTN780VYVuq5EzI5nJEpgGeiRymkIHXgrKS3BB4ipOF045FzEtHGQ/RMInjFefOEYBN XAqQDQhTpEFa6F/tyJodCppGcmYCZwTRzNxyaqEM8O7fH9nP2cyf5VNzzxNbB7IasEUQcNyzfMdr 5vLox5iKeEVBGf0hiNkFqxAPx/pGLl/Zwl99uakEzobnJoXj+W8jeWHu4WkOM4RF07S78auCFNS/ vM5Ly1iNdTDH9Re0/eq5buYDRDOQT8YKdInzooRnOjhGreDktW7nMCjE9ECnRI0t0K0eyvBAf+D5 XmQxQBlAgKqpjgV64I/1D1y7wARl7l/X8817d+MYoGoCIh960YLK5/+89yzT0VWFE/vkiX/nE10/ eOSAWKW1hXH+6e86AXDf+PNzjSoiZEb/8/ZNujZ89HDbLD/7fdefvbbjAxogmPzZjddbQon/4Ac/ QEuoKhw4cOC5557jN/7ud797+fLlqhBB4cMPP8w6OVDOOOMMU1OpVOqXv/wl5/XWt77VtMn4FVzO 14++cbG6ncD0MI6UvP+aBX90QRunf9+6nq//aveXf7mTwjXLcVuwMZcjsdp9OLXyiI0VseDnfr7t iS2DxpZZf3zzAAL2r37wHEIS6JsmX7lrIMtNQseAMv/5ZNetD0rHWHT26GB/5nN3bgdzqHI+n989 wuecmAc51LK5R9GJfme+7bJ2JFP8ePVdOBeMth/5o8Vvf81RVz7EYdRZtSBMz//2R5sRiqn6mw8k wP0gvH/6kxUXLxtD/q83q1b29KS5W3hZ4l798i1nj4djqLxnzx7wB7FHTLgTSKGuMtfdBGVeeuml Rx55hPw4V111lX7cvr6+n/3sZ7298ptVy65du1iB+b/pppu4VY4UE601oVoGedRDma1btwKFyRo4 MZRhkrnnnnvoid4st+6GDRsATzfeeKNeeJqvaO/qihWxAQSZ9JjcSUnks7kQtHocbgw7PPuwd5Bw iYlT0AIeSuL0w1RLNiCi8wrOIO5LrpgX4GGx0Aqf6FiF6oDh8fq9gUBza2vr7NlElSmkc0Tz1fgF IAFkQq3EDExTaHshZ4iSZ7XTMkdAqMOhISlkDEElMChWAA0ZG4lXVyRqr09yGxxd2iIxeUwDJYBL tKBFyNW+AgYwnuVgl0rZLOBMIzQk3bdADXEsr0RD3qYIge4kmEwAfySC/EL+SJpHJCnEJqYvTiu+ 6KK01TS5bLOTwRtKBpUyQAevLr5BWolJi+rCn4jDlRZRj7wHEErOGrm12QMi6FD/cNfwDiLmMTKR cASjUoBNFgsyaVylJLkUC9GUJXtkiXC+XqczxPQqBj8e0xIouYjXl91JIiuNh2EgsaEJH8P/9E9c zGcWuxy9DNraqYUypoPxtWtgdMJAY1u/1VTSHHLz2kfUmc6BUTKGORsjDi9t+Bnd8o0XPnjdwouX jcGpmNoZ8yu2p6DPyYNPQav6OsmsWMH4qeBXtWDW0fcwU028UYgfQyHOVgp/mCqYvoI8gDIUdg7k TFAGKgWKgk1AGbXX1ee0AmW4lYA4JrcjU7MTfCWwDW4yVGAigT0CcsF/8HXxsUBqf3/m6e1DzBxv Wd22aLa/P17ATx5rCDPE7Y/s/7t3jE7qExxokpu+8IsdcF1UvmJl87mLI5CrKGEBXkijPv79l77x oXOUXJoKiEXAMVwpmKezF4QR5nUN5iCu6BXQp6PFx0BN8uzG69vg4OBtt93GO/qqVat4FycYA9MD HAzI5kc/+tHb3/72Cy64gH3POeec++67r1AoMHPUQxnq85zl6UC18Q4EIH5hzzBb0YHxyT3z40cP sIJI648vGRXNgBu4Rs/tGEYurcDBinlBSrZ1HYUyX/2vXQrHMCCwWYD7fKmCL/3vNg3gxPfVX+76 msF7f0qV6QzLk1sHFI7h4Qi2wBeCQqxgaNcKJYnDfs25s85aEOKi8MMEgkCffOx7Gz5308o1K8y/ aIVjoItWnxElXhR31zPbBgHKtz60l8pGyMUhDg3lPnW7qNxQkXNqgKqtnYnHtwyCbLgNPv22ZW84 /6ioTjp67LK9K/npHwoMmtfi/cotqzDSHbv9mG/QGEAZlKEwbXAz+rZ9+0YBHCva9HB03lIYBSCi c3LUAQHz/OcJft5553HzsImbBw//4eHh7373u+95z3tWrFihNz7NFW5R2sQiQDscC9awubkZLkdx Qnfeeec025+x3bEQ4cHEXOwmYzVUBY5DsCkEXhNfYALaScg4j8tddLuzeTJaCwKRMPo24s+IwxDj UEBBgwmlmCfWCqRASfBNNVcq8wMk75LHY2f+BnTiphTzhphycWDykbDI7SWyP/yMxutATJAiEbNK kcguQBasMJi13JifaB+5K+AJHENC7VqO0MQ1awl9iw+kcfSOkAFrbYoxkSvsApRhEc6CdsmqXcin s7WsxODN4/xDoUbYyLEw1uDBRCQYUgr4yHANYOC0JSWVZrsBoOAshGmJD9gX+Yd15hYJ46eADG5O AhwEv2ATI+8A/wIwnGApER4LxcTxcAeD0nEEgsHWttnz53ccTmTS2Szu75jiKh7RqjY1x4YHh1Kz RrISy4ZBHV3AcVaPp+TzkKpb3NYFyJTKXDgC8SgTkyA4wXDSDRkB9V2+SldGX1G1OjP1MfNQRkAJ bk0mUnq88+Wdjycm9AlQmqGnGmpfhL34NvMM5TWRQh7oK+eHzuoIYzGZZLPqcPOavUCZLQeS9Ufn dXbHkaA142EdtRfTqlqZHZvo6akfQg+Ww3uwXqhW4D9YOWN2AOubKpkV8fC2uulAAi0wPITcKFNf mPIVEPnod9cns6nzFkX+x1uW1jcDylzc5v/S+88GQaqtgKdP/ftG5M+/eanvr288Y0pjW9++Klm3 a1jhGGLYYGtQhSASnOd5peZCIw35xofOpZzYcYo9wrX+zWva9Qbfckn7X31vAxAHiQk7TvLs9N1N KxAqPAHf9773YRRQmy688EKsSMxSTEgPPvggEAd8w8J0BVsDannzm9/MLsZ2lOmBV3y4HGO5cZ1T I+75rIhb2YBQwxB3gDBIOo5Rlbn6QBkAurrWytuLSCpqK1P1r9fLTfLBaxcafevg3sL+3b96tnsb EjGii2oi8SlVVu3zNP/mvXuAEVzua85t5fWXch7B37p3DziGny0BonTHwOsvmH3DRXP+8SdbwKDf un8P8nyTIRKg8/Ebz9CvHRcLouWv/+0lHvjYTE1+eWA7vE2+ePPZFy2Lqc7AVEER/d2PNvNLh77i blFsltpq/Ny0P/53P9oCWAT//d/3nW0U3Rur6esrV65ULBo4wAhl9u/fTx1YE2w3hw4dgiZRuwBh wSis66YcJi1Cv4BjmDKBLDqFw82DBerHP/4xFiUqADi0F3H9yCe+8vzzzyscc+WVV15//fWqoXPP Pffaa6+9++67Qdgn3vTM7knaSEknAK1QRN4iKQxxuCF3gYAYkkKW8pJioIKCBqYBoYiwFDKBo2/N o+UogWkY9kwu5/eXyUDAFgAJWhnyajNHA3mCnkDQ5fNY3Y4MAXoTXo83iBcUiAI1K27PRGXBjAqa sFswqWTyObJZMrULWQIbgyc2IEdDJczdxWqhYMlUrHhQ1eCLggGXlo/o6HjBqvBFfyyjlOHGYObH NsVqviwx/VRvoTqY38EEoBWYF5/HEyA2jFv+aFNuEogN8Adoht8cLQJTNGQnliaQy6jfBzwIVioN OlBHAzQCHbSQL2L6IR4PwwGLBdNEGzA3kujbDgEDRRULdhFnB9jDbxmgk0ym4FwIoZxIDEssX8ZH ISBhwCoObGJ5H3kZoJSQLYP/4JTkZLWzF5OWEE0MlbBs2ge9VmPBkU9kntIaPvGPY0Hmibcz2T07 NbHL7HFi39W3ovABYwt2UVt53/rOR87DPqUiAnPfEawFi8Pf37Hlxs8984nvvwSBwdO8vqn6kvMW y/sxrAOKBNNW/KT6NWUJ5TwiTVuNX3XGCEduY/l467OibnWh9R1VTRQGyHtZR/Br3JcJgK+cPpDC WH4q1j/x5iU6jlHtq1dh5h5ImukfkTv+2/ftoR1UUDqOUc1i5vvbtwuY4GoqkAfHoDaZPMiQ/f/p VR1MnBPLktS+k/m85pprdByj6jO9vfOd72Q9k8k8/fTTqpApihVmNVQ1qkR98nKPTYp1pjFjuWl9 OCl8mx47QOE54KmpmjJ66uGUFFDWfd2BAho/b3nTRbNNOxKbgBIeUsiH1aYpVVa7QJnAC37rw+dy 3RWOoRxyTtn4sOjpOEbVBzr85ZvOYB0zn+IaVbn65BrpOEaVQLfMaZKfCejEWFOtI0rTcYwqwSqt UDgRFv7rmcP1u1Dywu5h+Bh+pKhqvv7Bc46LY9gFscvChQtZUVyLahbkyqVEfQJ4pQRJiipX60xR wFmgiSokpIcCFtddd52OY9Qm7Eo33HAD6zT47LPPqsJpfvKy/Nhjj9EIKi4dx6g2mQW5VzFpTfMQ M7a7221ze+0er8PvdwWC7nDE29wcjjWFAwEvE2o6k8xkk/mCxIgDpqD0cHt9Lo/Xhi7E4ijjhoNP UbmaymQYE2ZOXh64Loe6u4mPsmPr1h1btu7YsHHX+k19u/anD/UN7j7Yt31vorN7pKs7OziSgYU7 0Nm5a/fe7dv2bN+6a+umjc+vO3z4kEYHgaWcsCkkrJYQdpoYpFDOla25iq1E/gMi/wOrhEIxLBAl RFEBF8h0ztwufARfQCwYAwFXJL8EVkj0GlQ4Wj3oHzI+OnweFxm/XYAVOxm8xVmJhjQoM9oaBAzb NCuS5HHSEAz+4cJ58AQQBMEKRwfNCNDjj/o0h0yYFdCaZpwSyw8dxnTnjUVjsWgYgMUNQ8oCXKsw MxVyOZy3M+lkKjGSSsUzmWQ2k8zlUvl8ppDPVnBcgrfCwiYB/QCgHEA7fZld6cHRSVZgE7TRy4Fg 9Ksx01DmpFBP2BR4pbv7M5fwBoaXB89TRdgoWEN4sZu/tg7CWT/J8Vb+5Ip5MPls/X/37ESejKmI dXga7Cnfe2ifrqGZZBaF8Y5SXz4mZOUVVqMnLRiVjLtceXYztzQlvMgay0/6OqjRJJ3hELortbJ8 TfOgoBMsRDRy7RELmrFB5jmFXIkdRzneyCooEW/kyCm4uHrl153T+uVbVp0Uvx5+2Cgx9Zb1FaY6 pg2+op9QhSg6lfrB9Aa8adMmKjAFsou+e/2KoqYVPhhJF7H0cVlXLRAwrS+cIxwk5YAAVQjOZgUz q/rKTP/w5y5/+POXmyZsHivYmFQd/REzpcpqXz5fu6pl8exjJFzP75aWsRC98UIzfqIce9D8VlH0 EyyKT+Py+nMFhZsW9OyUANxN5cwT9fiMOtwVRF5gBUObaRe+4hBA9CkA3CXLY19871mTz/mg+JV9 +/ZpM6I0zDqfi7WFFSOUUYgHAY28PWuLKsF/dsybBzDESzAVjVBJ7Xhin0zB0Dzsq/C0qRFmkcsu u8xUeNp+jTSFAgGkqO5gCBcjX3NzrLWFX08sFhGTizvgRf1LRDi/P+j1BUlv7fWF7HZPd3f/tt37 cEYgyXS+VM7m0QwX3C4nQIYki1AdqDn6unsGe/v6Dx/uBa/s3J0ZGIF1SfQMDPf0xfsH4v2DmZFE MZMnRg0TMgat1uamUCiA/hXMIWiBdNPQKXAaVgibMqFr8tV80ZIjNDFpoAQviOPVMUsyk07liM0n fxBFqSxfU4lsKp4GGoCMh/CJ1gSzTPPEv9Fi8dmI1EJYPGxhQBnAAYH0UMMARYTCATRwAPGu1nTN lAg+gKqhVOACxJVgHW1d2pRdNMOVwB2qUKbpV8A0IDNMdvwDOYPbFB5P4VAQCQ8SJELXJOJxZNfB gJ9DIQOiVP4KeWCYSGIwgRFVjz/N6kcPkbHTX0XziI2MuYooy4LcZKGTfEoPjiwK3Bz5NhP/zrSB idcsXsh6hmU+m8zC2x7VuN46sND3Qi3Fw1q9xuFbAbWOn8vvNw8w6XIIeOlvf/g83c9F38u4gsUE G/y//GI7QW6++8DeWx/cSygX5ey9eLYfDh8jPfVjdf5BxkawUqmvpIIylo+33jdSUJMylhG9DveB CifT0eo70J/hT9/EyqI2PzJhzg6YZZrDjNWmuT7XIBfVm9JxtvZ70YtPcAXpqNrzv549jMS4vhXC OlFIbD0+oVTRfd/+yAEu6Gf/Y1vQ60BycVaH+DpxdU7WGwCCA2wE9T2hBCiDnwhiGn0rEwl2B6wS vGbpeynrEoLNibsE/qYdBLx8qhPE1DhKGx85ANJd0B7sgrLl4c2EPQ4aAzujqqK9g40+TtFEQ5bQ FPrxjaJPN/+mplT5SBcsV541avXTSxQzxE2oXhj0cn0FoxjdMLGMbEWVpdfRV9QdZcClo1vmNvnG dL9iM6GQMTUqvkpvhxWG67FN/fJQtSBoM2MjY836dWxMykIEo6bET8q6BJKBZeFSUo6dg5dR9lWI RLcuUaLuChILACPqG6cE4Nvf3w8EGXPrVAv1m9AoJTY2omC3seS0XSdyCmYk9C1QCWhAfN6g1xN2 OH04LyNPSWTTlTw+wQQCLhEYN5XNkRFx1579O7Ztz6QGK9VF82fHcA5Owt6kUh3t0DZOLtayJUva mlvzKcQphfbYrJZgxAP14/JwdZKOFDrgEEippZXQMAV0LGhqXbZwc9iOzag5lkylRflrIweCSI2R yfADI8s26AQVCl5OzP42QuNi+SEdk/AwRxeSRMoULnoezgbxMmdQAgNls5gok6hlCGOMrzjoAvTB iwoeVtz/UCfE6MOgxjqUi0akaLwKkiCQihipxDVLcI20Ll7QWHkgn/iG+YuqgAkqAGX4U8hHkAVe RThJMRzck6yKec5ZwjRNMilJq+SIhMLQKokEHto+qBvIGE+B08ITSfS7SgMj/0L3iDO5JOzmD601 A6bZtISL4X+xxfGPwC6hr9RwaH3V1hk+7V/p+wwuMw1lmL95feSVlFQDk9FeKCiDQnC8x6gaK2wN zHD8wYEjNoQS5xA/+M2Bfz5eUqFLljf98BMXog/YsG8EQAOO4e3zwqXRv3jDopc0j27aB99McEV0 tKS6OkFNtalnZHTK0XekHKuKelLjev2pf5e3/PoF8h/Nytsvm1u/6aSUjCdEOCmNq0ZQOquVxzZO 9IiHtFDV/uy185G1wsowZxPjh6mLPzYBC/COeeua9nrnbbXj5D+NHtemvfBwoYRnEkYl5VurxL9w xyhm1PsxPrqAG54eSh1sasH4laka2TIgmyhEyrOaK460XI/2iyCGO5ZdIBjUjmTPYJ7+5B+PGjVU Idwh8ZCwohqxC5QG7AUWJVVH/5xSZbUXvuL67mpFQRmjZ5mpghLwYpAFifLs07dO6Y6aIAa0QnL8 NnOFipF3Ib8HxwL5EaUJPHfHYweVU5vegQlWuLgKqgJTFJRRrAw4BpAKRkFRiz4Gpg07EVeZuUp3 Z6NZhS3AweMdAp6BTVismCB1Lme8ysctJ968qjPe7aru1eO2czpUZcNiggAAQABJREFUoKtFgvPm 88yXpGvGuoKSw+0K4T+NJcPm8SBXqQIliiSUtFUHBp9/YdOWbTtxFs7ly7v2HmyO+gOSWboIUhxq acMChaGmfU47Ml3ckPLFCmMecHoJzhKKhiElvMGA0+EORpqApclSHhBBFBe8nkmOAGLi2GFx+bGK tBUYIh8oRZiiK3v27U7X+mYtgZDwCBNSthLBX5IrGJb9nQeFLdGgjKbt5QxQz5Jmigi8eXIq4XwF nUaQHOLOiQ2IcxY3ZguEDCHvuDFkEcsQ6iHZLm2BLYRtQbdWclpBY8K1wBihbpH9BWYITBGOB+cl mcBBImwV4EP/ZCub4W8QEYF7BItzPmIfwu+6qamlanOPpDPgEQANxwCLCEhCCiOYaRSzcCAYI+kN aEQ0xYAuwSqgLFYVxuKYUnLsol6z2O/Y4pn4NtNQBv8CdVqE0MAVYuJTHEwWdmpvsQQ4UTVve3hf Nl/Bx1gpSOp350mH5OKFPSOoCLd2CiV73AXXzc+/ZyXVeAnmWak7Kw1qWhmsS8anc31rKDmYWTkc 8TA+/EeLuOfq6xhL8ONQX3U6h68PvjBKUYyH2JR5BRvTJKFM3T1m7MLLtk7QP3Xs97yuwy1Rysde CAqib7hwaYw//HvhJwgXhCsNvAWjjWPXi7tHvvS+sye+Ono7460AU8bbhAM2m3gq8LRRdQA0iH/X rl2LVEJBGUXJLF26dLw5Rm8ctH3BGVGu/ub9CfTpvJKBTYk1QPwY7hlwzGd+tEXBWUAJe2FT+69n u7HEXbBkFNlQSLW/vHUDAm2eFecsDCP24qfBb4o3BDKYfvI2CXyiL1OqrO/VdET0rZdwh6N8V+ZX vdC4ojYB1KZzLY7bPs90U3AdBoE0VeimOXERzD3e+ZqVzXq8BmMPx1yHZYF1A8qgPmH+A7IATbBx UBluBiiDjQkooyiZJUuWGEPFINHgztEd+OvbVzcPJL9+89TX0UvqpwR9k1rBIqBWgNE6HWisQ7nx 6+m8Hgl1FAjg5iQ0UVEjERxi7CGhgET65RaSCHUiz7AQU3/g+bXPbd30Ujo+jAcNGCM+kuvtGVw8 rxUFynAmtb/7kN3ljoZCoAFf2JfOpvwtwVq+nLRk3ZZsPk2uabfX4yvYy5nCkIh7g36P3+XwOisI V3D2YZjAKKhwKmVSEMg8zTFEsuvq7En9+omtQ6ns8rPmr76gKdaEEYaoHHm4FePYAhoEOQj8EHkv IKZcQd2fI0+UNA3HXK7ki1mhWaqSoFtkwahPMM0ImQeCIm4LRAmYgXbElsMIKP5Da1OoFmCS1ARJ SJYoZYeiC0K+SP8lyB9QQwAVz3wpRD4smEbDGRqm4dg0rjEl0k8Og3VrMD7k9yHRcaCHpgNYkOgb bA/NiKM3MmsydNMl3NQ5Fi1rp03jHFIsXNTUStSHdlj5kB6AcRQtY6gwA6tH54wZOBiHIPLKrQ/s Q6NHBsfjQhniAiP4Za/rzh8FPds7Uxv2xbEljQdlqMzEwJwBMcP8Z3qNm/gcdRpfVcNviBWceibe i624OnM6vCWTu4AcOhPUx0KkguAh5ISxVzXxNHl8s1gxbrho9pi+RWwikBrTHpwNWorJJFHi3Cfo xsu1SYkqODqX3mhfO25/gJsINZRWg1fw2x7ev/NQCh009sQJ7oTjNksFJrDxqqlX4Wg0qr3ZjNYC wQBlsD6wlU0KyhyXklE7v+uKec/sGPrOA3tv//j5BFbhniEvBzfqglY/2lVCA3BLELjlyS2D6NDv W9eNagohtrF7BAsGxzCjf+HmlUaIY6yjr0+psr4X72L6uloBKnE76WEUTFv5qvgh/X2jvsJkSnRd f31ltQkTs8keB3WqZMV/87ZlH/jXF1DMfOmuHd//2PmTRFRAmYceegj1Ll5sunVJHR0o8+STTwJl kITv3r2bQqN1ia8IwwkVo9t96vt8XNrGuAtNGb/Wr+v0D7frmATMBLdxfWsvb0koGM2JLhXfpUKl ViByL37LHncQWQZh8iwuiRnDdNvV1f2b3/yGdwZsNaALEACzJBN+PJ5MR30+l9hrevv7QrgrCX9g AxOQxQijlNVtTWfTGG48LiQ3wWKt6rK4SV3kgCR02PJFfj6wQaKlpVU7oeewwpAlG3sNE7CoaW2Z bO6JJ5891DNE4pWtm3cPD/VddPGieR3uSi0jM7VhaZ89hxLwAdFycaLK5jMZ8A6Zv8tkTZL26DkG GoAAOAPDkCR4AnwI0yKbwDWCRJizNDjCWTAGoAHAB3U4FJBE0jkI5sFEpLEk6iVV2BGySFbkdZBI dXzScxCMACR2Eq6FwYJcQSWjMSfsVkNgJGNLsspyMYBMhsyTbjt3Dgplf8hDGD0NDQmUEc94esI+ dJGOcnq4X9XsFYL9CZbh8NIq564W1mWRL3xSQ32f0c+jbPDMHJbAMIhtORaPbOahCQ7K05OIYVTA 11qPdYvVnBK0kLyXT7Avce3YiqneSEfX1yfW6ke+s/6ffrK1fhNWAFgWyiczU/7plR0oOahMsBNe Hupb00vIb8ADl68fesNC7bLLlkdf6kM0z8oEkTN0nawu/tXNc/GMeSgwsyqXE2n9dFqAL9ov10Ls 1/p+8UQgr/jXfrULVRBbCXCCuxOv2qaaGBQ+845l6pEySeLN1ILxK/SvmsaMhazzjqUEv0ZnXcrb tYUVxL9ESCM8Gm/JhBsx7T7mV+gW0ntBvQDFCItHei+qYZdE0Ao8JfozhYwPNwmc5UevXwyOeWBd Dz7nemtbNHhNZJp6HFMPBaZUWT9E/QpIi0JCY9cfgnLJlqpdTR2n1rcwmRI8uvGprq9J1OnnNEVz xxFqVq+j27ywcCnTElgfdKhXmHgFfEBkZ+oAVvbt28cKCEbtsnCh/DwPHjwI9bJnzx7WTZeYGLLU hLkZE0NglFRObaoaNXVGB584dQj9k6lCOUPpJfUriIjV48IYH89YbbxyY53TZD3gJ2MiViGhIxBh yOxO+ACxrtiZWzF28IMCXD700IMb1m8gpJsKd8Lpiy3GYeeKIKMhJxFzJum1B4eG4okEslywBEmI SMcowVr8AbAJTjgClEjSZCUrEWpe9LxVzEXM8TLZS5IBAQEQWszVYsMRUS2WpuqOnbvWv7QR/CC8 SrXScyj7u0e3bSPodomER8e4qXZE53TEZs+Nts6ONMUCgZDP43W6CU1Xq9hhewhRB82EGxb2NGAK wiCyPfHgwtvfJ37jgglAQBwFMh51rgAc8jQI4pEofQTfgTmS+IDi2iQ0EqeAEUyyLGlBcfAtQscj gIP04QhigESaJQwJNEiJUlQy0EjSLj2yEgGYXJJQmwwHCbcliRXWPQnUQ4Qe1El0hgFCFGR3AYLo JwxVno1AGRlwZET5EtwTg4f9SwCcMDgSv08YJsExdISF/rCmiKaZvOVmGspwbu+4fK7yG/rCL7b/ ZkPfmGe7vzcDka4CuhjjTzCNUR9MiOs1z7gx98UmpcxSBO0Ys4JeOCvqQU4IlUKYdr1QrSBTgP9H gmDyGTZVU18xQqkgH8TuI8yXiq1nqsk1Rlms0jiYpiIl+AV4TUC34KWlbHPoHKGaaFwPv6vceo2H u3dd9wRQT94LXqYFZKng2h2/PVjv4v6bDf3M4qQ9Vy5jSJfueeYw3mRQWab+zo6SPFZuXSLkmjad wNnx8sfP2dTOM888o8wHa9asMW1SpiUmD0XJrF69ejJGBNUIWnLmXQg2yJiP37jkV/94KYlF7/n7 NYTS4YJiH7nrM2t+8qkL7/z0xRiPwNlGTzpaGNQQvG6n0zsGFL776UPqq3oLm2plvan6FTRJPGr5 Odz6wN76rcQIVr9TNNr1W6dUQgpYpfs27oWVDdqSEoX8jJuM62+7tF39fMgiAmNn3DTBuuJa0HGb oAz2IwS2gIynnnoKUxHIxpisgAYvvfRSpj4qPPDAA/XtE9iXGZfyyy+/XG3V7Y/1mAOSj5m7vhFj CUfnNqOEvApoRIybWAdPq1vRVH56fsW0SmwX7BfMeQhUmKd9RFdhUpUAdy6f38ecDlv24ovrRWmE yERsZ6Kr5QMEUiRoC8kKCmQ0gtSpDo0Md/UcTpHqmQB3WJAC/mA42Nbe1rF4QWt7mycc8AQDwVgY xyjUHxay44kilhj/kkJSgAAgCPclQA1RgEmYkMsngaH7D3IIniQOu8dC7m0LKuPq2ue6t21Nl4rH kPT+EImeOCTRevG08iHNEZCkHrAyqVehN7w+L2ckYAv5cK0S9XvnRIPhgM8hDlPSB3ZRyRqZ/sE3 gAN0t9pzTMABJh/4HH7UWrxjyCTSHoBT0BGLkYmpkPg3JKYiKAx0Dy+xIn8RTMEmIa7EOqRJXMBS AZezVirgcQWEoktAQnGLExOZHYMeI40jeoFLAh4C7QlvBM4UM5yQNEITCVOk8UfcWRSPuRwtl7oz uLwMUAaej1gRJHHk2vyf/9zx7fv3ELceuRZnzdCDKu55+hAx0JSJ5L1Xz1fSATUmQBm8r1nnafUX 317/8Ppe47MPcQC0/P+4bSMXmKi1esz18cYTv1AFqv7hji1Q+uxOTfTIhC+DX2GdeZdYtOPtbix/ y5p2Fb+YYP8fu3UDrSndA3WYiZ/ZPviPP9mqcAwzmVHIubs7BQCimgrIa2zTtK6ImXyxCpphE7AA zxFWCPP625f61QAypQHCwEwMr2l3vqopcFtnCqSIDklBovpqp7TkfdcsAIWgd/mLb7+IsYwfPodD JwEH872HZKZc0OpDBcIKczlwn0tJMHuyCOm94gJxzyhyS/cVZ+sJnx12hNtvv113NgHB/P73vyc4 Hm3Onz/fKPZUfSAuGe+OUDLAHUomaV1S+6JT/qd3r2gJuYkE+Jkfb+aG55ZWzk2qAusEO8bH+KPf 3UASMRJoGwGuuuJE+zUSGPwWuOeJf61a0JHflCqrfcf8hPx4i0YgPbFVPJ912yV8zL/8fDthmtmL m1P3GB+zkckUYjv+mx9s0kNHgmDg5FRuB+JTT5y7gKfsp9+2lGmSGwozk6I5j3tQBWV448YeBPNh TCmwSMvB9Pjjj9OIybpECYwOaIaVLVu2EBVatxDBxxB4lywEbAJ8QOGxwgIrg08TK2AO0IyStgCg af/++++fILKitrd8YOpS4ImYv0Q2Yt6lkBZY/973vqe+6pVP5xXhR8TsAudATkR/c6yFv0goEgyS Q9HlCwS2btuxdu26ZCJBEH1IEZlpsQyJycPBC3+RzJDkELDUmImJO4fRJJ5MjMTjVMZsRfZEUAUC GU/AF2qKgGAsbly5XXa3C58cvCJJd8BUz6QM8QGg0XCE2FAwsqTTGWArXBFPAOgf/lCP4I+MoIfs B6VScMvm4a0aYawPL8mIRCuLbQaepFop4r9dgMgQHATTA1IDjPgDfoebKLmACjycLbOigfZYyE9/ uGXltVxyAoAY2IczZT6mM1rCSE6WdU4UmAWQc2D5EhQGXiEhFLwMR5UmCBgIigEFSQYD0AwVJOAM YET+wDESe5gVr93REgraK+X+bnIBwb/U7G6HQEDSeLpI3FnN5Uv4i2Vxctf6Q3+xNOGPja+7l+jL uIrxxiZ2J/rAn4A/ji+aZOFj1KKBFw0XSo2ZXSY1T5/0LhHO69/+6vx//ulW7CCknuaPMcH6gEel /rLOq/nfv2N5fTR0DOS9w3meqvh/fumunf/v7p28zmK34gnOQ1ZwKCGw3HaCl5vCY9SfBWjg83+2 8hO3bcT54ot37aAP2Pt5kmptSHwX3pvr9xqzhOmZpsiqg4kE6QCtUQ2chGRSDwdMCaH6P/32ZcaY b2om4BbQTUhjtk8h+hI8k1nBxqRUI++9Zj7WMd6J8ScHIDIOh4aQmFmwxy1tDyh3GGNr5IaEq8fX 45Z/fYFycjDhImSsMAPrdJKUOl+6ewfaC4g3ArwSL/HgQIZus+AsRr4nfhusI136n29ZRsgfpuoP /OuL7Mg0TwQEoiyqyuSXNgbCObGz4+Wb5wQv5V/5yldgtpnMwDTqvQo3lne96131Y8K0BJphuuKR x1xFtfo6E5SgS/3hJy8AbnLp3/f150lkAeVGIS483MC7D6fxUwMQ40n3hZvPMmI12oR7APfzGyHg NYGwMTKCmPmK5BZ8DIXDOmEIAPEfvG7hlCpP0GE23fL6hQSpw2MIW9izXxoiZjFPND3MHQH9PnbD qGlm4nYm2MogAERQ7978teeJJxTxuzATq/db9Gp//67lE+yrNs1v9b/36gWwRAf6sz969ICRzR1v X64drkY4KFFBty6pymeccQY4Q5EreG7Xt0CYXYALuAQwwYKEhelWtzeRskAFytN3BIvccccdNAjW YfKgPviJmYzGuYtI8PT/2XsPaEvSst57p9q1czqxc/dMT4YZhiQ4IA6MepUsXBETXCS4VESv31p+ y4+19HO5Pr1L19UrBlCCoEgcZEQRJA3DwER6Yvd0T+d88jn77Fi7dvh+T73dNbv3Cb1P9+nTZ3qe ojlTu+qtqrf+Fd5//Z/kt1x0hiR4pBX+7Gc/y10HeWJYgU6xB9gMNzCdOe8eFt3t2i+s1sjCKx+N MXLdQjzILUNVgRg6q0308Ey1+o1v/Nf8PGGDDQbgNtWV2lKGCGZBjSUphd0EQicZSwBduVxtxzsE QNWajVKZNHR2MpmRygUheAAiAtUjiclOwEfEt5YM3QzOqC8kwMX0A3fAACO8SvQZsVi12+lkivx7 tVpVXGdIqxvy6EXIxgsWUoGryd7d5zhFlGrzcAoMMWhExTK5WuZI0wBREGYp/YZYt8jvZycS5YrD wegZla/zKQp4c2t71aCaLc4qEBcHFbrJLSQiCicNh+EM8VERO1ELTYVFeP4ChLAbzw+YEgXi0eLx PM5L+iw2Km9zoUZCkMRZmLIMwWCSWK/R4Z07tj1ClZUYMk5zrjTPE8etyOTFkFMLogHribct9gTj BCy8sSGABEtRv+CsyHKWpUBi6C5LDZERg5NHcIzbr3mJr+HtdXmoDCeIOPE3v34rA78JnOa2ws5t Thx84Tq/8bqrF00KDHj/7y/dRCQL1YPxAOWS84nPP7MtaVeo10hQQ48P71KQUqUPHwWUbcxM9MEk /MCUAxvAFuDx5qU27V3OtXv7q7ZS/4+TMj4chI+aLDU0ZeAhNz+uEt2bYSPDUYYlKBDLV42hDW6P yBW864lVQVbZMZqkk5Rx+N9f3o85iTGMxB6c/m03DPApbxSg7mMx//Yf20rSXkKBilXCCntWrt1P zCgf3fji/3PXfoKHK04LasWxGRpJVE/22+4LxxJGNaow4oLNMO/rARA1Uub3ZFS7sLPDZv/Od77z m9/8Jjo/ryEmOkPqMwaY173udaxdFBdsTObLe/kMv4tuy0IoyP/1s9eRweUfPbdfsiN2t8TUiCsV bNWP0/bXAt3//d+v43bFbcUwCXwBcSbDW5xiF/tPl8nWQ9S6iWZfUWP/EIvOQPr/n7fd8JJrCp+5 5xi3mXnceHPRVepIvPncu3rRPZx3oR0JwWLxdEFYJZMC/9gE8vqKGwcowLlo4diF+8QPj8gvZE60 ST4brt8i4UjLTyguRnrpoTLbvZpKjCbEbC/qaQujffvb337dddeh4UF/GcY4EC8BGAZGydtuu63n uNxR73jHOyiYgDkJQQE7EWYjXHDe/OY342Lc03jRnzR+//vff9ddd+HEwx5MGUsoDpU0+PusoTL4 5IqXroUWhW2GCGEy+ENlWAjdOHjw8L6n98MGIDql+jzqAyxERmjuNv6Pr2u7U6s5zSTsXSQNHGUY icm2FwvboVIZLxl2kuDDjjqLnkThjcBBHBShAuR4w+cW64tHNCTXC3oIIoo4MLWDhXwe9aFeLFbm 5ynbTVFKSXyDjzAOJaGQ1LZsB2q1c+wYk1MTjOOQBtITk/4fa1eljmswR5DOwjTgNJAP6FSzM0M7 TDzZXJ4CC1RagGZAWiTTTCTaodh11A5ZUc/EJGIbWXV4JRJvhA8QbkX430AmIAuYpSBVEBUhEhxB 8BGdBJoDi4H9SAQ2JEYYDOUyyd+Dj41wGixEMSu2bctWMuyMzZUxSFUqVeQWCkGhP3E7sYW3qSg+ ECCJPmdbCIrYqIS+mCsgRIojeT9EAWKmZxJC07NoLX6KALUWx1n6GCC39/g8ushc2UWuGMhESe7Z rVssvanYbsi2xzud1zduE4yC+B72Gb/Qs1usLSdnSNfoklp+qVRdPZss85NBFzdJcrthRCukLXhb T+XIZba9gFVYixCThrMx3xHyAnay9ptw75khGQWCfHHLFCLAlmHukHQigjzTU11hVXrOSwfvS6gM rqAmIneZ3RKg+7GPfYwv4w9+8IN+oOwy7ZdZBe2gmqa5VVA7cAMiTeIy7VnFI4PtCUCQ/dAyTQZh swlJCLnlSCjgvd9k2Yoam50s/xfHdtgnuyXe6uLz+nAs7EGQOWqN/Z/3vYCfyPMYy7D2chaX4kIv f3YXthaZAYMjtxAyDyPr8jvBQQHqg/cMpGf5lkutZQhnD9yrHK4f49RS+1mD5cajuVu5/PQXP5yM Y3VJJ5MpCiTZMcZTvH3R+cK1hvuRT3zyzi/eySgcaAawG9WqVTiBkBmCcQJhCjcH6+Utw8lNo1nK NpkCAbCiTRs3DmQLOPxu3rgpT52hFMMz5Zk8bQZHWiExNqYnCAMmGhmX4RlM7U65XKoUZ7ArDQ+N ksgf3lCqlD/88U/d98gThY1bA1bMomxC1Bbv33awVpUP5kcf+K6P2//8/d8SKsOw32yUcVEuC/fy PoA94w81rkkn0w5Mjk3veWIvnsBpO/ya2148mIzXXRx9hHhACog/R7eh8wP5AdyWhQN12lxWrGSE GCVsCk7aEDschFmVyhXoTKVagQFi8SGwWqK7SEUTiXjWKJ6eFjl7xC8HExKONUhEzYZwK8n3GJic n/unL975+L4D7aBVqzubNo2+5c2vy+eS5BWYK5WqhJIhiGaTiWg4F7U35IYGE/lIMFJtusjm88FQ NRab7QSKEtsSTNmp4XxhOJNP2XGsgwRu8VacK86jLgkiokt1fuan3+BjtfBO8FetysxlU2X83vPO RRpZRMD1Wyw9gwjBv36+vZbex5k1vuvJeVv204Dhln/9tFyVNrzxny0v/e7z5clEeFtUe+tuxjwG RP71LFzdnyjQGJv63CcSDi35oL9IHsNO8qno8l4gC7vEI0N+xe4Ui34bjCz+vJlZUeOebRf9CePE GLToqlVZCDO7pPtflU727ITRtP+bB6J8Xq7cs/+en+j6fmxUz6r1/xMBg7FZdBGhrS2y3WFaGhsb x0h3z733PvjYk2gkpH9BI4DtUUEacxLxM6TKF2FCSAjuMrjqNrFIIW9AczDujE9M4P6BY20kHBUa FCCJcIAwKQgQ7SEMWGYkjNgNNMktJ0qFKA9MU7Oz1bnpoYGhVCqJoMHoy/B/803X//DJJ+dmJpOF 4WA0TupfzCzikBuCmZyR/w3OmKKYged4MopD1LRRKWAO6D/QfYQN/GkHM6mMbRVnZyPJfDiWpOKr 02iXSmUS55TmyzTm5UO4+OBAIZlMiBDSCSaSsU2jI5RyGB0cxOwFV4BMIc/EoSqdjhfABXmqQNdm ivPVWh2+Zdkx3HbpEm5DjbrUW8hnsvlchkpPmMDOhBpF0MCSQERQOgarLRs3jgwPNBplAMEuRLZh ArLx8aGsZqMTIpOPCyYYwjDCSTS854wM04ILIhCJ9CL/F2mI/3maSJdyYxBau7+Xn8qs3bnqkRSB 1UCA7+89e/awp4VGhNXYve5DEbiSESBQCeuF41Sx9DQlaKl193fv/dxnP3/40BG4RWZwMJlIkpmN gZW4nhRVmdxGsTgnyXODZJkjhW3IQWgQQtLBDRWkGiEijMq4vkqcjURTM7UKuQKOsZAd7E1B0tUQ tSR1Ion+xgsWyUBKLMEAZsnTk0rkMPpYZLwV710G5+1biH/atu/IcadSRF1J5EcgGw51sjtN7E3d 14bULMghiCi1uuci0xaHG2PgEdJFzFWrOZzNUAzzmB2Zd9yEbRfL1ZNjJyhoUJyjZAK2dfgP5ja7 0qpOl0WCssKRuCAQPHpqPJ9JX7Vt6yapaj2I2y3MhnOgxDYWtukihsry0/ufPnDkGGUccAzKFgoR gr9Js4PtDVlEQqgduNG2LZu379gOGSKjMNUs67j1EjSBE06nlcuksE4x08AHGgUnLEa5Bnyv08RR udZuoMdEWNt06+T6oya5ZXfO2NyRjrqQ8OY9NnMOPl0tLvmsUplLDrEe4MpAgDT2eCfwjUjgEu9c XCu2bt16ZZyanoUisGYIuK06OdpabrlRQ0dIO83iF7705SPHKKZrM6zaEQueErHsesetSToW4o7F zoNMAHmhQSsaYtAVVgJR6QRp35ZaSxGCbyYmJysk1KtWkHFIKjPouqlkRhLFRS08Qhi8a+U6ZIUR t4q7DblV2h0G+AIB21TepgSARAiRhiY0UMjfctP1E+PjbatdKU9UwsFEeoguUXHRC4V+BqqEZJmL wbvCpSDBS2gzmHFQMOgqKg4kwQq246FOcfxk1g4PYF4KSFo/6gaQGTuazGRjaTYiChrnZs4I/kEl B7hCKBhNJ2KdaMQJWlOlaiA4jQMPRrgtGzcFY5mK0zh65PCx48dxmqk4TiyTj+eHAcPC5oRJK0BI FN1ohS324M5WSnP7D44VS7A+uBtBXgQvkYoQa9ett9xy660vQCEir0wDv2cphO3i5OsEWBmwOmHq VVFeMtSUJFsN0Wkk0ww5gDybmvAW/t89PYPL5eAzSmWewV/nFIFlEMBP88477zQNsCu99a1vXaax rlIEFIFFEWiH6oycyCetjh0IW6fG5ohGRm5hSMWMg68HA6dUM8QNJGrVq8STtqxINEhpJooytVpW OBoKkk9XPFJxVkPGoNA2W5Fn12nUCEXCYwUVhyzA+dwAFQdsW/hGpUx57XCxXK5RfqDpYo7JFbDm EDlFFSaKNIl3PyM0QgoxQTisXLtz50O7HqOiGDlhpmdLLfIF5wpUTXLdcwxMqXiKEt5QA2xJmHtq qBht8SQWf9xAR6wzxEPNzM08vX80lWyNDhSbrY1DQ/m0PTsx4TZqoWYnlUyGInGSNlUbTVQiYSH1 Tr3iULsrR6K/XNpBuhnI4sF77PDRa6665o47/huBWSenJu2E1axWQp1G1XEmZuYma07RqdsdSa7D /3BEou4AMQGIRDTY9+RuEtNEO80br3t+Lp297Ude/rxt259/9faO1T5NMHunWW01SyS56bjxThuY 4UPIRbFAJylURYxPZPCLRSwHdPCbxlAnZAV7HJFoYmqSRoKeZ3TykDQ/+btmk1KZNYNaD/TsRoC0 vxTiQbzGTeH2229fNKrl2X2Gl6n3hKPjWEaA3mU6vh52TRFw3DLuumgRqVh2drb+4MNPFovz3gc+ 2oRxu8BZowWRidlxp1aXVLxiPYrgxoJdidQmFJbGF8XLDhPGnOIpDRI17TjiqkLyu2JprlSep7TI yVPHMQDZxGHj92vb8WQym8mNjG4g6QJuwDCYTDpDsLSXg47BWbJwhJE32sFcFt/XGH62qWw6HE1M TlfirQxGG/xzusHCP8XGmQZRKBJlY0gS+gUeJghJpMRz2vjmdIK46SCKxKLZXHp+pjyUzznlVtxN EjEEByKItS1Jge3Z+aoYeYgXh4gkEkkrHmoSMt0u5PK5Qo5SDJwIjslEbE3PzuI1RCbgQibuUBtq qhiuV9q1KhVHMEvF45GhwgC+yoSb25FgMpXAR3e4kB2bOHXTNTu2DF+1a+++m29+/k/c8oLpfXun a7NuNlRsCYeqNJ1OELsSog48EW4WiwUD5CskkhD9inh0zHuSZ0fEJv6P4y90xzAd4TEy5xGabnzW cl6pzFqircd6FiNAurx3v/vdz+ITWK9dp2zZ8pXL1mvHtV8XgkDdDdQq9fJc9Vhpevfug9MzGEkk zS5mFsw3OAKjKmC1wQwCWYHPQGu82GPkAAk8ZrBnIU4wkgE4RPI5Sd1GPwhQajbTlVpF2BCp+7Ef YWpxycLT7MQSUYv8NfmNoxszuUJeipbjDhziMIlEHN9hnGwgSxiGRJgJUdKSApP4vwoPIONvYSCH MIN7D0skKVzXRPCQHIhhHpIlzr/8p4VJi91It5suSeYcMugSxxSMYMYhcwsKBqpPuDNA7hxOsFl1 Z4rTlbpLGBMuLDNTs1t3bJ8uz1qFKI44JN07NXZ6vjzTajgvuf6GV976wnAsfvrYYZLLDAzmCRBv W3Yml6O4Q7xRP3nyJIl1ULxw/N1KzBiWs3gom07GU8nt2zYFIzcR3hUOxPefOo0tzCHau9kKxqyK W6YcATkC0VoEci/bDQKNnAv8hEXCD4kikywyzME25R9QeDgY/iINZIFp6s3zc22ZjVKZrhtTZxUB RUARUAQuJQIH909Ojk/MzxZPHD1dqzZTqRwJfFE1XKQF7zufg2MMMhlwiWwnJAcGwcjICIkvC3RD TBoRil5DaCQg2UaAgJsQvJS1a7UE5irxFxF1BHYkRSjjUTubzYwOj4yMjpCWj9GXKGYieRBmYDOw IwZpvENEWxDFAWEmXJovURohmk26gTYhe/lcamJ6IpsfkrKKXVO1WpLuhCJk2WMxUUIy9kueF9K/ UIQJE49F0hmIF9HnLeowuJCbEP49iCdk052bK9YqZbdaw+hzw023nDw1Trx4yHU3DQ294mUv3//U wRPHjgfanEg9n0psHB7YMjo4MDKayca/ffe3s8nU0Ob8sQOHKuXqTTfckJ2ZmpiaiOYGNoyOktaC rHqPP/bIi26+YXjHZsibYEQseihaLuE93cGjiPBu8rdCTiqlGTfsEucuLtSQNbx8xbEYbyR0Jfyg kaokYsmjJ2I6Mv8zGLBQwJN1ZgK/ZyYWPfPj0s8plbn0GOsRFAFFQBFQBDwEHr7/AIWAyNk7M1FB KQmFxEbjdmp8w0vwj0dAEDQgN0gFCC/QGggGNiaPgpAPN0gcEhpOkOgkO+bJK2HxrCEjbySaH87R lNgeRmEUHqmz6HEgiAt7lrKO5KvDtCSJWuKYnGQ7ceXFcUeCw7E0SS6WTrtSrxESjeVIjh7qZDLJ Q0ePxZOZZPycpIulSkUMUnjvBCksRdWEZLuCQCM1JVgCj8H4lcymmwOFRpskwnVhS+wzGolj9QqH OSZkYbAQzuUHyJNDrBGez2Cw7aqtFgY4iwwUyYYbGixksCXlBnJUVXKcysjgwAtvuRUShpPQwNAI QFFWgDrgN1577WTZJQvgbS99aSjQPJSLU0gBeYnqnalcDq7n4I1E6QYikhoOBjdy0QRjMWceHoP9 rkN6PngYpwtdQwaTklES+A13EUYi6DMJk/Ecgc6SFuErnq+MWc8JGt7DQlVlwE0nRUARUAQUgSsQ gdJMnfKJBEMzZMI/oBxQCuKD8c7gbBllbZvBkjS44ZDLmMoyMWZAKGAmVM4m+IbxH4/a6fnSQDZL rSXkBNuKpHBboeI2+VhSydFR3E7cSqWMiCM5cfHDDWFOSkjxApxWokQsUcIyDgkR05KM06I9QGgw ozBS45Z8emIMtxqy1JXJsUINyRRVtyP1aiWbPKdEcZ0ULk0XMxceO6T7a7XSRHmXXEn4y84iUUvy 30WjqcGBsfFTsxQNjSaQODgfwshxaolF84RQleYrZAmMBFrxpP2C512fzlDJIe66HadSny/ODA9m bSuQTcaHC3kJIaIudTi0dfMWHIvwANq285qpyalquZTM5l+ZyFAm247G8oUsDr8bCi8nTgn/X/SY dggnYExEFLTCc7pRnuMSdGKp1Exz2pGclE2LiHLEJFNxKoBdixgoaCVR66hVpOKBYHoqE0RF/idw yYz8O2Nxg8pAa4T1nOU9SmU8MPSPIqAIKAKKwBWHQL1ahqV0cDIlm4lknAtHo5GGpKAL1xv1eIci zWIZsjpkhENiaJLylpWej6kTtSMEYYufSzBMJafx6ZmNIyOk/Y1QOShsJzOZWDJtxWxKVTPe14jK rlU9rxcS3aKQQDZScB3JL0wOXxgTAT7IDJI7Dy8QihnBPxiQ2xPTk/sOkg9X3HLhBCxhlCfR3NTk ZDpZ6L4gzQ4mLDcWIDkvCVFT9FJim5u40eKBLG43zWCAHoRti5pSVDgKhWMi4HAojFLhcDaVxS+n WoYj1bAAUZAKXYfeESA0Xy06LsXm6o1qw4byxAYoJWXhwSsOLPSWzL2ksKHogWUnUni1YCbbli/E pGgmVA3rFXSElMKNOJXGraiUg5KTg7YAbaM0Q47j+Uwhf3RyWjLMkBjPC92S8C2UGQpXei5BElMu DteyKWwGl+aWLXUYQEAoCwKN/JNUg2ckGY/NmJXS5gyx6QbsEs6rgekSgqu7VgQUAUVAEehGIBLG lRYX21qLoJkWcTpBRmMMMWgM1SoiCAqKQ/5fhkpElkbQwbFXQqDJ1EI5JJsgGhEPEApQVMq12tHj x2+4dmc8EZcKRrCABHJLUlLO4QmTSlPogB12GnWkA5xqaBG1k5aNHkPAEfoL4/YZjUFKCMBoKI/Q bB4/eZzxnJG7gpsOSeHQJULktGvMzc0SGNV9Lt5oLWqEVKsgUV6twpGx3RBWLQmCyZ5HXFWrmYhE SGMDB5NUfRwJQQVnHStKgQVKaY4O2jAggp7gOOIJBG9oNsl0B90aGshQP5OkN3HohUtVSNSfmPAO adfCsIRBKDJIfj+LugFwo0ioRX48bHDoPvFInEPgQ00lBdLpIAahe/EfvIvYHgqWtlN1/IoEAQo2 odfg+0xmZKlQBYeDh7EfKY1AXc1g1HGhmEL8PA3rGQxo7i2Sv2cmkWrM/88uWZP/KpVZE5j1IIqA IqAIKAIB5A2rTlp9N0gAjeuiZ+D8QjYUigxEcDJpVOvETuM1I5WgIS0xO0IgUIvcvDVK+5AJl+E6 FJXqAxhbQrHEkbnZ4t49L7n1BYV4IRKNwSQY4LEjkWtOhnl2JbpBUopIw1MQZ8jXKwoPmgvuNxwZ rYJC0LjKtDwP1nCxUtp38BgVkkjfkkgnKo06wkQnEIFKEfhcnJMi6v6ET4+YfKTigQgtdI+JYguY zMRYhSpDQHUQFoXfbSwSwrWW9DmNQBRi1ElYCdZQb4EtY1Gip6WgJh2BB4QxcYWrhWQ8mE3X5+fI UoCUgoTVsqIY3OA9EdgOnKvexO0mlkiFcym3EYeQkC/QFADn2C0KUoq3j5iBJHGeZzAScaXVjOPz a5GKsENZcNhdINSGrWCKE6YjZj64DdQKjQZ3Hzkp+gRRILUMJcW91eLWzGREGZGJPPbkLRFqeFmm c0LLLksP9KCKgCKgCCgCzxEEcL/APMR3P8M2LhkMhHzCwzoiUZSYoOuQW0UGSsZuCQtieEfAiItI w09xmUW/CYeoQkkiOEnCEk9U3eb+o8coG4QHLvtBh0jg5YudReYZs2MQCeQFGotpRyaOyCE86oJE IoO3RHCzBKpz8tSpmbliiXR3HI6oqBjKB3wojCoRiIQr1Zq3hzN/kDQ8nUW0DPgKod1nlBJilISX tPGlkXXtzsjQSD6dJq8w9KKNUUcincnRgqtyLBqCfsWFY3nsCn4RbbQTlCDAMtVswFrgZs1gq4bb Mk3wDIJ1SX2DUNutT42Pzc/NEBKOExBCFMY6yjlgMSPamqPDLSBu1G6wOXVEGckZ41YrkjgYAuZ6 fr2yK8k06BE7XIKbeBZ5Xfa4jxilRIcRcEjgA2b+6XsrMHIJtzmDJe3OTn6zNZtRVWbNoNYDKQKK gCLwXEcAisLnPkOehBQ5+J8y4qIHhIgpgkpgD2IYhqKELDsUI1UbYkkIu1HDqsxXykgRcZFbIBVi kopJCFK4XiOVf3POqdidpKkIz9jMJKoCUUIiacAqECBk0EVggA+JPwh0RpQF+cNwLNJFOExBg/0H 98MyiEIiLAmWZYVjpOzF4gIrGBwcIdSo+/qh6ohuYWGEEadhiINnX4qR+c7FIZjOo9pYQeKmMgPZ UWd+bHKqE2w0Q6kgfsl4OJer8U6EYg2dDtYj0WMs6jw1SKsH0+pEgtAK6mi6+BUnOEagE2u1w8gx ZMejJAIcjf0E7bYjFIUoJEofUO6SU0aqISoMVgdNQ4YSyQghikOSK4d8fI3ApvwA4eduENcbikbB qtBgOh67AgsJqkKREcVFXImaYYQeZtlHiEIRUBmxRfFPKJWUBAccT6PhAMJ4BF/hM90wrcm8Upk1 gVkPoggoAoqAIiBmC4wUIsUw5mLZET2GukvtgLh12LZTo9C1G4M/MBwSNYNjKw1IWxcVM1C1Wstk U7QUXYdU+rEkbAaFhX9T1WI+PFxvuzHPDxVegoWI8RbHD4KeoS0M2KLEiDYjBEZGW3rhSTGM3ngF s8vTY2NHjh9noKYcQZ2RP0ilAhK07M5kBwcGRrLtgB0/Jyc1dh9Gc1yDIU7IHphi+IdxCUXIaQj9 6XCOgUAik7JcqzSbwAAmBABPYy/mvEFIuksxAByAQsRCw07woeFkWvj9krYYcoGhx0tORy1xnIlQ d5CqOA3uI6GAIRCQepkUX+IsscNhdJJTNWISHM4rf01ItfA2kt5AmTrNXCZ99VVXA3oNo1MHU5dH gFwKYgvJo/YmEUvCfUIRjF0oO2hoOBsLz2JClfFELJQa6aKncp3hhIAqh7ls0zN60WXrgh5YEVAE FAFF4LmBQC5HahaPRgTJBsegLsYLdBR8ZbAW4epBdjuKtsJoGMvx+eAvwT947DJ4zs/PY/fAAwYa BAGampres2fvxMQ0dqDpUvmpQwfK+PkyPIuy4OktXjPJu4LDMP9QcXBkFdbiubWedZ7BEIUrzbET x79193dOTUzQhw2btwwODbmtwOEjJw8dOTE5Pedl8o9z0O6rhIcNIUuoS6EgKVsQkFz6y+5JvEfy Ptx/4FIVAs0DHYKbqfg9OjxMkJPEorcRXxpCMjAyRULEKMHPOCm4gscXWEMT8eGpUwW73YknU4gt Iq14pjFYEi4vDfxnxE9FUtEAKV4vFmHmKUnvi7+vd46oXHAeiTNnU4gQLOr6G669+uodrOWMgB+6 SD8wn6EfUaMT6x/h3hTI5rIg8VBCG0ubQ61J9iKIQqPgDIg4+OAIgxQ+401cUY/MXDY2o6pM952p 84qAIqAIKAKXEIEtW7fMl0poDHhkoCJgikkQjoSO4akLLTdBkn4S5zOME+GMioLlo1atI2gQRE12 XUJp4s0WNSNPnRybnJyG8BDohLUptnPL6cmZVnOve3V7++bNsWBSWIu4yIhvCTQIoQEpRv4rEwIE DIoBnZE70Kg1nj544IGHH3pi7x50FTxpYTPJUHhqau7ppw8NDg6JKzGMA6EnEu2GxvOubWHhwjuZ cCKLugB2pOlEarjdiP6DmSZIst65ei0rDKYlLiv49ODALHlahF7IP+EGXlwTRZ7EW4WSlFRzqkPp anXKX9Yz2TxFmeiSIWbizQKBqtfxfgkgy0RtIRi46uIrTdi6sZ1xdNgNtcNxmYHDSKe9Q3eCN15/ Yz6dR8GZ9w7DTKvRjLTQrPAmEqGKDkF/yOgDMhyIOWliCWE6azcSWcujLh7xMq7F3jG6wVnj+UtL ZarV6h/90R9xSr/8y7980003MdPPkjWG4Nl4uH/7t3/7wQ9+QJ2ND3zgA5eu/2tzlEvXf92zIqAI rDcE3vSG1z/+xJOezQcDEx/84mWKjy3WJYbqWDRGAUlEmRjeJvV6PGUxrCI/JOM2I7oMqs3A5NTM iePHJcpH2E+QLLq7dj1KfaOtGzdNz5Ue3fPUJPlmRjds3759ZHhQaIu4FWOfcmV8ZoAXN1w8UfBx keDoUr2668knHnvi8SPHjgYsO5XJTE5Nd4Lh8fHxEyfG2p1wPJEhewtUABml1TrH7RcHG4QVEsng pOyFLEmoM+JPOIS7bkNqGUgwdqtUa1JQKQwfwtUW5xI4AecoTricfLPRdsOUQMKIhgUIpYR9NajW UEWCou/Uv8zlCngLQVngfwhMBFKHGqJjIfuwJ8epwfjwaoF5YN7ygpaQd8SiJioKge+4AJOORiKU 7E6rnLQTkiEm0CGLD1QJbacTalCwQCQWNvakFQm7bklGGeGBXCSpJoWKIwQHr2W5o2BPHp+BazIx LzqbXNTLxmguLZUx942cedfknXDXb+/eOue3/ugDAblxzpLkPppfYJO1Ocp5O3fkyJEvf/nLNHvP e96TTCbP214bKAKKwPIIXK5n6u0//7YvfulfH3nkEUZAbBJwE0gA3IIQZqSETCbLKM9IT6BNtDSf ymQ9woE9pZXPD2bSWTSaUqnMS4CccozIjMrYZchO++iu3YcPHt+yeePWTRtPnB5Lp/ZvO3b46h3b b7rhxsFsgcht722JliD+xuJDg5tOO1xznHsffnDPU3vm5ouTc3PDGzacOnWqShLfWmNmZpZyjfnB UQxfCCXQLaxIqEfdqGL8wagEu6jXGOjx/hHhghkjWkBYxLoTDDZanbJDdhlKL8UwNqFvSLWmTkcq TUoYUcNt4Q4k0UFYmOih6DG1CpUwqYot9Em8f9BWJGIcNNhhO9IId8RmxnJ2AicJMy88guw7ESx2 iCnizYJrDOyDAKdOEzfiphO0QjHQdkT4ahwfPz5fmcfkRDO6w17RhlCMcERCjAni8BuSeClciBzB DpbFmUlUlHAXXGaEEEKW6K8M4bAbDxl+n0HIO6FutC7t/CWnMj3dB4hEIsFC7r+eVfqzfwSwrAIj xUT63+QCWq7NUfrpGF9pp0+fpiWPbj/ttY0ioAgsj8DleqZIu/LRD//tr/yPX/3Bfd+X4dxhsG4G CXjGM1VcYALJVNqtY1dxkPBnZmaS6XQ+nyM3PwWuxbm1TZxSGtXBqbnEOiFyEGDMP/xAqtX6vv2H xienEGASsSgiDE61s3NzL7jx5o0jo7AEb9CVoZaxGAPP3NzcfQ/cv/vk8Xq7dWpy0kom8JhJZwsk vpmqTWHkSSQyDNxwAXGwwSLWJq/KOb4gJKbDp4WW9VojkYBaSE45jGO0ZOBvcF6kYyEaqN0u426C KkJCFwmqwiUFJ5cA+X8bUo+bI5BoBq8gXnDYwhClahNT481mQ4xhgQD9nJ6ZzqQz6WS6glRDShi3 iZ+xZH/BXMVGHtXCK8ZzuImLkUh4jdiKYD80FCICJWq3gsBsi0VsrDx5ePJIrePQMIxORI8CIfFI xjLmpcJjIxyZif6WeG7YC/22cG82yo3s27u7ziAq7EVmL+e01lSG0fcP/uAPLucZXxHH/m/edKlP ZW2OcqnPQvevCCgC6wqBkZGRr3z5S5/45Cc/9U+fOnzkGOHZ2E+QZPCGadTmU6l0yW0QmVQulTH0 oEWkkylxwnWoMWmlIilxC6GyAelmEolqXcK5vUIHEUKKg+FAuVqqNRql0vzXv/GNTaOjz7vxhtJM 8Zabbr7m2msZlL3xVlyJK7XK/ffdj1GpTfkjlArLyuZy5PxHicF0RVQ2hhTYQyBCyBKMq4N3jmdI OQdI6khDRIirgpBgKUulJLcLDrlYYgiYktDkjlAZGEcr1K6R41jywoTiHUgDTCHkWZJqfJJiAIu0 PJpE2sCmQ+XqOhPaUL32+BN76B55dApIUpAtEvrWwtPjE48+/DCpgp///OejY8WSiWYAJlcllBo2 GMLo5ZmY6DYkD7Bw22ngDG0585XpIxMzDbdycPz4eH2GMtkU8rYCRHlDEQkHJ47KYy/0JozjsOci zQrYDShJfDex3d7HpDAZeM9ZNC43j6Efa01lzp66/lcRUAQUAUXgCkeAL3ohAnzFi77wzITi+773 vId/zyxa87kX3fHGFR3TCMPnbEL+W0o34ZtMJlxxksWgA4uhHHdLikrhSCviixCARqhZJx1OoO2I JIOQgpVJZI+6U0c6IoSKTXFRRsyRYk1uA+tRp9oZnxhHdkKVeXrf3nQshukn1+zY8QwcaduWLVAL fI3IGYiCgvdvgwoPlGigugHlNSWFsnTFMzmF8TB222UnMF9pzs7MzDVa1VK7EkiSh5Dcf5i0oiQk ljCyKJFSmUg0XG/VkkTLY/JDaGpzLi2KTcBoCDsXv2KkKUxL4iEjk2g+wmueY6oMps3vfe973A3Q yaGhoXNuiwU/JiYmnnzySRZjGX3pS18qqJ2d8Ml6+umnT5w4gW/U9u3br7rqqm3btvF4nF2/3H+f euopbkqcqV74whdOT0/zE/soM6Ojo1u2bLnmmmuy2eyi28Pld+/ezUFPnjyZTqevvvpqjjs4ONjd mP089thjuGT92I/9GMvZ8wMPPDA1NXX77bfv3LmTVTSgq2yLdsopYLHmFMxxaWB2dejQoYMHDx4+ fBhzY6FQeMlLXkKD7qOYc0+lUsDiL+fW3bdvHz1kz3SVtcPDwy960YsW4txny0WPYg7HdeRY4MDE e2rjxo2bNm267rrryNjt94cZTu3hhx9m5sd//Mf5e+DAAc6XiSvFlxn3wObNm1m+zIRNfXZ2FgBN m+9///tsCyxmh/6GffbHb7/UDDfGD3/4QwCk51xEMLz22muf97znGatoz1YYsw1EgECX8vk8l/Xm m29mvqclP1fUuJ87zRyCfj744IN0u1gsUniP2/L666/HxZ7O9/Sh/5Y9Gz7xxBOTk5OcFLf0oqdG B/hm5Tbjgvrb9nlF/DuEOxm0/c3NzN69e3mCeB65jc0Sbic24UnZunUrH7W7du3iPuSu+/mf//me bXt+0h/uJe49BgY2RB42dyAPY09L8/P48eM05mHn9stkMpwdjyEP48U35t3FA849A6oDAwM8Ozt2 7ODx6dnzSpHpfrfI4Oe9W3jb8IJi58Dr3xJ9PlM9/bmwnxwU5MWNN3ZORpYL29t62yooWWtgMozt 2G8831/xdWFUZyk5YihULalaZJ345xCnjQEK3gPt8Yw5JDXGPkbZKWiAWHokYghHaAgITkK4vcwU i6MjQ9lsGqeaAweP4Co8XG0ObthIlptsPssukrFEJEaVKGhRCEtccQ5jm0t9ToZKhBYyCmIIgnVI LjvsSx3HSrSbJBJuw1rscLkeaWIykxTA1A5PxOx8ZqBQGKJEVb1ZDju1thUguaCYlPCjobQBRT2F yHQ4I9qbSViqdN3jMWfIjBifzsyu4QXrfd9d6kMD9Ne//nWOwntk4RDbfXReYR/96EcrlQovsl/9 1V/1eQzQffe732UnjMemPe+Fb3/727xu3ve+9/UQi+4d+vO8mhmueH3Q+OMf/zhjjFnFm+v+++/n kXv729/OeOC3NzO8d/7lX/6FXvnLH330UeZf9apX/czP/Iy/kGb0jeGW9/4999zzH//xH2bVy172 MmY4Lm9eNuHu/8d//EdERLMW4nL33Xf/yq/8CoMQm7Chv0NmIEM/8RM/cccdd/gLecUzqBPB5FMZ xhLg6vlugNZ85zvfefWrX/1TP/VT/rb9t1x4FLMT3sVAMTY25u+T9ybzvOh/8Rd/sZudML6ay/2K V7wCv11O398EBslpAt0rX/lKf+HCGYZJrq+/nNNhHvS6qUz//fH3s3CG181nPvMZ7o2eVSz51re+ 9d73vpdRp3sVg9w///M/M851L6S3nO8v/dIv9YxMK2rc553GcYli+8pXvuI/CKYnjO48Mr/2a7/W Pe7237L7dMw8d6m5iFxZn237zUql0pe+9CWeyp/92Z/1F/Z/Rfw75MYbb1xIZbiBgRTW4lOZ++67 DzAZEThHbni+djgoLxP/0IvOwKE//elPo8B3r+Wm5bOq5+mgAXfCV7/61Xvvvbe7MfM8oS9/+ctf //rX+++ilTbmSnEDf+Mb35D3vzfxzjEPBa8L7LndHoQrRcZ/t/AG+/u//3v/3cIh4H8PPfTQO97x Dr7fOGw/z5Tp3sX/hTLyzoeWeR2OYn8AAEAASURBVGWJnvkWvfg9r4c9RIKUBMBvB2cYYq4DJJDB YkOtykCQlMTRdJzq3pK3xWlUowQ8N6ky1SHRMTyGNxgWKPxsxVeGZHei6sArKEhJgsBGB5Um2o51 gikaIerYCbxkMplcfmQjNSId2I5ksLPJ6utG45LZTj6dJPoomc1SD5wfUkEbEShisU9J54sTEKap Dja8jiW5iDthil85rXbdDUGEovQpkoknBtKDudxgNGFFKd8UCbQiATfcjOKLjAcPNibyBockgol0 OXQZP9+OaEuchViaPE9nIU7yb4EItwYXa62pTJ+ndOzYMUMyoDvvfve7zRNotv3sZz9rOATfynwE 86jwauPh5Gn58Ic/zBu8HzbDrvjQ/4d/+AcYMZ/R6DqQDw7KuAWzgWS89a1vffGLX+z3lk8ods7H HISJ5eg3vGj27NmDcAKv4sX02te+1m9sZtCTDI/hRmMU7H5NsxVEhA/oH/mRH2HMYzhkJ7xnObUb briBrytoFmfHsXhT87blrfTNb36TVT0DZPcR6TM8hmNBbjgdnNQ4Qd5f/IXnIc/ceuutpn3/Lbv3 789DLLg0vJ54obNPjsVBgY43KWLG3/7t3xJ4T1f99mbG8BgUDsZCThzomMyYwRjWwxK6t0XpQe0A bUYjlnOxODXz7JpmF9af7kOYecZjw2M4Iyag5hwhc48//jjfuHfeeSdsxt8KPvrJT36S/jNswD4Z a42OwpUFhE984hO/8Ru/QbdN+xU17v9Oo2933XUXh4DRMtJDXLhPQIlvbuD62Mc+9ru/+7sGqP5b +ifYPXPLLbdAmPiwZs8LqQygcf9zUWhmtlqtK9Ldh5553s/cxobHIJghbPQ06P4J5+Zi8fDyDNJ/ Li4z8EW+ELiyPB3cljxxZhPOBYZk2DOXlfY8O1xWbldImxEF4RwX0JhN6AbXghn2yZ3MX7rBi4In F1rPQ8THWPe9bY6yor+QSPrPTvhC4MbgBKG2vAT4Bvuv//qvn/u5n2Nv532mVnTE5RtzdXiz8XRw przQrjBCEyZeKBJBWMFM1AgSXtRGHiF3L/FEcTsRjoXhxbV6hdQ4OPW6EldE7HMrEsUsJeO9F10E 0ZBvci9/S7tOLW8EFMgBOXECNhJ3ihINMbtQGNwwugHKjm8O9aqptRQgw00wjMs0KWyIhiAfDQ4x 5BKGBXk0Q0omSYgR3AMC0vL8d4Ro0YTq3ySR6eCBbGWonh0PtKOEc8V5l8Ut/lLACoNYs+1YRD1R ACtIwHlQkuuJrzJ5iSVlDoQFpUbUoLOkXMSf4OWkquuRyvDiYLDk1cNX4Lve9a7u4FtGBcNj+Prn XWCeIgbU2267jQcYNfWLX/wibGb5p8us5cXE+/ed73wnD7ZZgoDMtxGHZjTis4z9w29YxdVizKA/ vO8QTnxbAy8LvrH4YOU1hIoDr/KPy63DJmz+xje+ke51f2zRhncWsjaH9neFVeuv/uqvOAQ8hj50 EyNepn/3d39HH4BlKSrDCws9nD2/4Q1v4MPR7wbzbMuLEtAMlem/pb+T7hmGEJLNMMbTcygL9jWz FuigZbypIZQ04HR4wrs3hOi86U1v8vuGaY/TgR2yQ0aUblmreyvmjfrCdTdUhhOECfltLrg//h7M DPzVfBwjX/GZ7q+FIjDsIWlwybim5jpy0H//93/nJz2BZ8NrTXuUJwY8QODWgptyvixfUeMV3WmG eCFO/OZv/qaPNh0G/M997nNm9DIKWf8t/RPvnuE25uZBsGQ/nBRPTfda7lh+YlriTcjMal2R7kMs nOee4SHlTN/ylrf4lHFhM7METYInC6De//73d988fJP86Z/+KdeRW9GnMpyO4TG8UnwBhtPnxP/6 r/8aook2w4U2XyYragx6hsdw86Ng+TBieuZ24h4z8omvsy51Ossv5xAwGF6b8AbT8jWveQ0iDbov TJTXEWRi+Wdq+f2vdC3DGySbiwWb6ZEwV7qry94emkgfgNfviTeOG1WEzMUuYgSpcvErSYTIkkNJ SxvDDsN7E+eXhgOloAHJiHGpYRKjD/4x+NEyBUiqWxfiEQiwF/5SfABrFPHbuK/EU6lBaO+GDWSV cco14ohwUw4T84VLDnloIBHsCt9exBmy5ImjtMRt46jDoTsUJGBqSyQ1NSmJzXaxaDkN+FIyRt2r FGUokWRabSsUsPC6wStZyndTbkkS/klNBupWsguqGBAiD/1Ci4GxeP7TzAub8dAQExkTl/ty0RlR ptbVhOrLByWvHt5TfAd38xguP8MkvWXU9HmM6TxPi/ng4K0E/e/zjDDZ+DzGbIIIZPaDYYsvMLMQ HnD06FFGC1b55INVXDWGPfrJPO9W09j85eZkPPv1X/91Xpc9PIYG3HM9u4KjGGWCV2S3MYjG27dv 5y3MDIOT2fnCv/47wgwnfgPz2qKH/nuz/5b+Trpn+MKDGLGETvo8xjRg1OTVzzyvLawA3VsxTx98 HmNWMXiYU6Z9T+P+f15wf3oOwSjC3cVCbq2eVXyys4T3FFKHWcX9YPQAxlGfx5hVKEycF/OYzy6s cf93mrmU3JY9N9gLXvACVDEAh1aaPvTf0rRf+NfAgjDjn5dpAzMGOubhsmbJal0Rs7el/nLPQJ6w O5+Xx7AHQ00Qz7p5DMsZ7M3l858seBjWH1bxPEKau1/LPLPmA4P7xICw0sb/+Z//yZ7pMLeN/zyy hMvHg2N6wncRrz4WXswE6/J5jNmPEZjpMNfrYvZ8YdtygijldImz7ob0wva2rrbCQkQEE3II/iU4 6nKmuPjySKJc8F/S80JHYlHCmsj+x1ArDERS6obww5UtYRUOkdxU0GzUcVdxO23+kcy3Rjx3MAQZ yqQyWzZu3jq6cTQ3UIhnUpFYMhTNxpMZO57E7EQCZHLVoJag+qC7uHWYitNEQIEtSYUmrEtO0yvN BI/hHdapuS0Ik0tpylQ8nEyEUslgJh3mXwIJySbKW6KtpboVNEgulSFXbUm4x6y8IlF8cOxAGpK3 JSINEzMefWG1x2dky8tAaM75dL7sdwkftfgfwAMQOfjo9781Tcd4Ds1Lh8+ahV1lyDf0H6vKMl/5 /obsfNEPIIYifGwROfi+4YOJ9vv37+cvy9m/v7k/Q2dogErMlz3WLn85ZKubv/vLmWH/C61gvGdR lXiH9pw17eE3jKPmpunejz+PEg7HQsjFpMXmvLWFoXsTAxvTBbT0N+meMT4xdHVR6DhlRgKGeZr1 eMAseskgQ5wynK/7ECuav+D+9BwFRvvHf/zHPIA94PNwmi/p7vZmCUbPHh5s2qDbGQ7B9eIqrKjx iu40+Aqf2gD4hS98AWZp+C594KAIft0d7r9l91bd81hwoKpYcvmy7/6KwPpGMygpT4dpv1pXpPvo C+e5UniP9fnC5IuC68go07Mf+JD5zj7zCg4EANO8YYxnW097ZFdsdlxW83210sa0Z4coIj33GAu5 ZK9+9avxP8OPjU+FpTyRe/qz6E/eUbwJe1b5Xx08a+f1K+rZdlV+cqUAzeC2KjtcJzuh3AJ8hcDn cAPDDvpKIGKFqV3AQhQW162Lt20LDxp5FVBdgReMFDSwbSxJbsCF0/CNRC68ZLJJBQLWkBsQXxmK OUglh0AoHUulo4lY0I5UXLdVjMfiaaKgiHlqtgJRRB90FPZJXrwArsKVeo2qC3jZQC0w/DThLLAc j26QTLnRdpxAhapKaEPoRdJrvH+tIOWniKiCP9FDixglNBnqM4SDUmRBIsZF8/GMR+zVQx2iI2uk HpSoTCwzJKfnknDJ15bPrCMqw2uRyQzYi349mPcOiCHG4hzTAx0/RagLBMwX88K1PUsgE90SS/da Q2X8bzWzQ8jE5z//+e5mZh79hhkOzZsRIuI36I7m8BeamZ6vQ7OQO4mZRZ92s6pnJ90/uS2hDnzS 8aqCC8KoMEuZOCnoVPct1X/L7v378wYT9rlUlxjzgGuhMLaoN4zp2DIUzT/uUjMX3J+eHXI6/hmZ 4YSzwMeCD3r/NvA3MWMS19rfxF/FDDdV9321osYrutPwTUE4RHHBNMZEfxixuOhc+m5KTZf6b9l9 Ij3zCDNQGSx9MGb/BI11CauWf4+t1hXpOXrPT8bj/odknzpwp3FNAZk3CYwB1mXeGP7OzcXiJ28A f2H3DDK//3NFjf27aKnPG//VwbNzMVRm4TcSHfZv1It51vwT1xkfAZtoZVtirTv4lWBsCYTicfyB UjBnUv+VqzXEErhEk1IDuAFHYxhvoB5INq0A9ibJDUw2vVKlUshhwwmiqdP6xKlTE+OTqVic2KR0 JJ6Np0byg9lUutIJRSMW5qZ2KGCn0x0rgp5DGkBS9FE7od6sT81Mj2zBu+saOBPSEM43Ivng54J9 KdhxmrVmqNYmN7HNoE/dhgD1KyMRxBvyDWMzgr8gyEi2X5gZYxGERjaT1MRoLyK3EKclNMdbfQ5L 8SiO/z3gg7PGM+uIyhgnGIRxvk154xA20mNq8QdI8wJdCinDLZZa6y/3v2L9Jf6M8TJmSENRx0Zj Bhj+mhm/Wc8M7buXdLsqdy+/RPN81fHdjIsP72j0IQzzTBwL2oRp/0d/9EeN3w9L+m+5sKvmjbzo 69I0NpQFJopq6g8hrALGhXu7+CUX3J+Fh8ZnFrsYfhX+qEMbToFvXGND8TcxY9gy94/fkpkVNTY3 mHejSWDOUpO501Dsf+d3fgcdjgeHGxU3DiacxGEVyEV4SKDVmT3033KpI7LcOP9i/uC+MvYmTg1y w+GM/cJsu4pXZJnO9Am+vweuIN5LuFt1m2/gJVx03wxHY//S9xho/P10z1xY46WeHQxPIMl44DOk 7mP1P+8/5v1voi0vGIHcQAbZApWCCB4GfDuaSCayESuJW0qlVp/HH7dB2pYgHi+dUAQTEnINS3DB nh0/vWXDADoMNiay/FF8YICy1tEojsDcBIRHj8+cRo+pBa1aJO5MzF61dUcynixW52pJm8oCds2J JMi0Rx47mIXEMA0PDjRwPq5VXXLSWARGBMmizEsYlxlS9pG6pt6uN0Lk/SO8GodfAq8QWSBO4sxL QFOzTT48dgdTYYZAcgpgSxEnwqsitMFSJaHYslC0GTgNkwRjiWjDJH+8mQtG8uI3XEdUhicZrzSk XZzU+BrGvQ5DCcOzf5K+YsFrunuY9BuYGb9Zz/Ken7z9e5b4P3nBMc/FMkdhhzTmU2lhhLa/CTM9 3KWft2H35hc/j1cHEzSCz83D3sQnOzoNRnqWvOtd7/JB679lT6/4bgAKqFLPcv+ngQ6juH8sf9Wl mFmt/qA0EHsFV+Ym3LFjB8IGXlOMOox2mBo/8pGPdHfefOP2fNB3N+ieX1Hjld5pEEQcSHlqGKoZ p/mLqw0dw6rFFcfM5JvA+m/Z3fnuefaA9ys+YXjDGCpjvii4l7qJxWpdEXPopT71VvRwwVBNAS9o PYQM/QPCjahDt7my3VSGV7k5bj/qxYoaA4vZMw/Ioi8oOJY5Wb9lN/gL55dCZmFLXXLpEMjl85iR kF0wG8EEEvF0PAaVSUTCcUb/YrXcqrvYbxoNlxoFpWqtNF96+sDhvXueqpSmWu2rtm0okK5lvlyh VPjWTcg24kt03TXXjA4O10vVTtXZVBgZSudiITuOohMKzUeoKB7NFAq5oWFSw+CH2w61Q9FQdjAb jkXSg4X5Ulk8f/GSoeoBkowYiAJU2S7Xq4RUE+VEgpuQi9twx6aQt3jZYHqC9HTqTjPMHQrxEUqC sQl6JN4xeMKQBlj+hcV/GHMVhg9aeL6/MscS4BUWLq40l5POrCMq89M//dPGM5RA6L/4i7/AiIhB 57d+67f8QdFXd3mlLp+Tpp97F3vQUs2MmyTfSeZtxXFpDFNBz1hqk4XL/TfdwlWXdAn9xJHF+LKg b33ta1/j0xmnCox3PQ4r/bf0OwzsGNr871F/uT9z3o9yv+WqzKxWf2B78BjuNHJvMDYv3zcoDsqf uUkWtmRoNMmHcK2A0q2o8QXfaRyLic7QMUZuQvcZjBm/f+/3fq+7h9yTXsPzt+zeyp+HwUBlIEyc O0+HoTLdkgwtV+uKmIP6rtZ+H8xM/w8XzN6ErOMw9Au/8AvLixa+ZMIJLmoF5hMLzgEHwk60osb+ +4rbbFFjqy85+y17Trnn51LI9DTTn5cUAV6hDZLz1usIM9EIN5edSqXtKJW0Ywz/oVgMd5U2VKJB QclQe3LqoYcff3LPPqfSqNWbTx88OphPpqig7TYQYqeHRrFAUfp608ZN0AfCkOqNFndvyoqnc+lM PhvBupSWgKN0boBYynm3HopaiVQsmU1QHAHGxLGzXllI7E4QKfQeidFGU+m0DhzaX+6Mj1wTwZUY QxiikYv3LqYlgsMxO9UDjUYzRuy2sBTZAsOXuP6K74zVQZmRkG5Yjug0cBfPlOZZlaS1sKUzPy4p 1ufbufhnrJPJfzXwqBvTEiZtXsp+93jIYX/85GXqL/RnwJRhm+wgpNXyFy4zw5CDcrGwARTKuGr6 7xRjlTfhuAvb0xkO+q//+q8Q4YVr12YJTsfEdqFj9RwOax2hUgY0vtdZ23/Lnl2ZnwYKhupFiSCG D3Np+vdjWPQo/S9crf4YcBBjFvKYhWdqbgxuHrSchV3FxkdeGcKhzXC7osb932ncpVxxJkOb/G7w xU9cnvHMpedckf5b+jtZagY9g4m1OP/ybGIFxmmGoK3u9iu9Ir7lcaFdmE9IrKXdO7+AeR5b87EI LAt5TA8f9V9BxB8sPBZsA8GYi8uHAWtX1Nh/dy31dvKX+8/OpUZm4QnqkpUikMtszaa3pNMb4olC JJ4MkuuF6CWMPtEIYUuFZCbL/3L5wvAo3igPUbry8UfLc9PVyhxpeOdma2Onp6AIhGfPVEqHT52Y mJ6qVst48SZgJ9FgcigdzkbnA9VioHqqPH26NFsLdsrh5pgzPducDadD8UI0mrVakI0AId+ikLQp 4h0Ilqnd5NQCrUZHUgkHj50ufe2e3Xd99dg932rNTOYCnTQJhWtOrVSvVxrNstOqSTy3CC7sAC4j jAbO0gpQg9umLBOUBotSpx1G74Gfeau9ICbcjbFxSayT8B9hOJLRRtiQGXK8wXqlkF5w+3VEZbrP gaQOxtLP8IyoYFbxbJtPQPhNt83brOX1SpYXvhp7fB67d9szT7jNQv6BT7ExoPjBw3yMMizx1iO1 Rs8eeNuSyYaDQqt99ainzRr8RLXGAxS334XjARENpmPGCtB/y0W7jc8N6iVnbbL/9bShA8Zs1xO+ 1NPsYn6aYcnfw2r1x1gZFir/3B73ns366h8aL1c6AEXAMcXviZnhJvHNLsa0tKLG/d9p6D0Mt1x0 HH57+sBPo1/Shmeh/5YL97NwiTEt4Z1jThOdr+e2X+kV8Y1TxlWu+4g8VhcT3WZ25duPFl5cTsFQ Gf/KIjUZcYsnfeGh8bYxLY2heUWNObq5E4iv7GGf9BP/GHObIR35ms2lRsaH2j99f4nO9IlAJp1P pTL8SybTQj2DQWoqMaZbRCmREQamH49nc9lSqcxYg2W2Wi4TNI2rrridhIJzc/N8bMAAcP4dmxif mJqowGXKZezzyWQcd2LLtsq18tTs9PTczHytXKyVEXTIwxuJR3FtqTdqKDooKLCHJkJOgGhqkVaa UqRA1BMOUqnW7vnefSdOT9ecxu4n9n/z608cOUg1b5uQJYlBasdwCw62a3j84hmIt3KrxeudQHH+ Sa/4rxcO5TEVWURQEzRHBAUOyvkatxlJ9ss/b5FA591Sa3xfrVMqwzCAmQkCARyYmXzCQQQmr05k NxLK8SUNtuDG8IzYYAZXvml27NghaPYx8XX1sY99zJd2YTAwJ76q2bTbM4aXiwnOJOcpo7XvKcIn Ixq+2XzR6M0+urA6TXj/ghhofPzjH+/+kIVY0GcGXQ5DeAt/+2+5aM/4EmWsYhWAk27VV7l5/Mj6 b8LKGN7Mt/uie7iwhf44hJmM4ccfn1arPyauBIfWbqEODs1XuI8n52g6D5JGiiBRbPf9gApCXDRX gfuWPIcX0HhFdxqSG4eAzcCoupk9RhCT12f79u30hDb9tzR9XuYvgf1oG0gyMH6a9ViXWLLSK8IA YHL1QixgM+ZEeN7hDSSO69NxZJkO+4mAkWx9lJjh2nGxzIbdHwAmeQzPOL5T3ADmdcw15d5mKKI9 kYmco9lwRY1Rmhlp2CEOOpwp3wPshD1DSf/mb/6GU+YR7s6NeamRWeqZMqemf/tBIJWEq2AVImSI 0GYqUguvkCCfsCTP5UmBzHjeil99ZNcjFSRSLjM6iZf0gYRQvJ9xo8G4Aw+oVmtTMJZi0SWiqOnG 7Ggykcik04lkCu5TIZ0w5iCS1gUx+ODNS3GlNuYiqAS3EHoI7rgQCW5sfH09ekE0eBB+s3ff07se fQyZRDxe2q3TJ6rf+SZ33LTj2u12LBiIkXCPXHiSLbhJ4UgGXHxOqK+AYw3x1vJfdiw7RH3hBpWs e8JjmExSPMgME5zGPClCecycabSGf9eRr0zPWUNK0IQZKnhvQmnxpKEBXyoYvCE3EAjeNdxDvP1R RLicrOXhxNXRiFs9e1v4E4dibjje+3/+53/ODUfuFvZprgID29ve9rbuTaBQjKDcArwBmfgg403k D6iMW7gTdrdf43n6g/sn+hAv37/8y78EJSz9MBjOyCBDEBMDG73qv+VSp/CTP/mTDOq8i0kUxoS1 mFvZt8LwWWkS5S21+YUt5yrzXuBBhZkxccQ/+ZM/Mbtalf6AD3cC+ycBMToWIyhOP/zkBnvzm98M S2YeywKE1SStx9OWqw/a5n5ABQFtGLa5f173utd1k7kVNe7/TmPYw3qClYchn8eEbtNb+mAoFzcA Sd4MRP23PO/VYXyFzTCuM9hzjouGFq/0ivCYf+pTn+K1DhvmKnNHAT73LV7/HIJ0++ft1TINEHdN bgXuWJ5fWAg9N2IMlJTEdHAyXKT/7M/+jKIBeBNzRG5gvme4pT/0oQ8ha9EfVBNuAI7CfUiCO/9w K2rMzsmVheUR5sSZQqSwOnGm5kuDW449G3Okv/9Liswyz5TfAZ1ZHgGL5HiWRRKYZqOGMYfBPxFL 2LjMWBZ/CYAkOAk/vB/+cBcPJm4plC2AA0B7+IM3S4PEL9RBclxKZBN2ND07w5C0NbgpnaCeADaq cCQYzmSzVjjqOM1AKBJLpeKpeMSOEJZNHBPuK5KxznNsgFIQfe26DfQeRkC0H8o5lWvOkcPEASCu dCzceslGE8HLuP3A/acc17r5lk0UyMKnuFELNlBi2F4y7WFCoj6UxGCLfNRpUTKbHUJk6JswGi+I SV50aD5yKO//Z2Hil/eb1Ws9rV8qAxKUXeRDGT2WTzRqEplkD7zgfvu3fxs5BLcM9Bhe5bRkbOMD Ebdchuo+IeS9D+/BVoWOjdOD8XtgAGD/DEWs7d4PbzQcQvkCZuIdZ16FNODVw+vm8vIY00/SrcLk KKGAroBY4uslvG0xCjD5p9N/S3+T7hkGM8ptEhqDggVV4hFlLXc0gwQmOSyD3Y1Xax78OSijmj+o +Htelf5w0XEqgjFzZQ0t47lFmYMgMtoR5GwGb1+YYXgj8Ro3D8HbcBrItOmPGdt2nKsLrqhx/3ca g9973vMeHg1sFgzPMH7TB9gAN+Ttt9/OWGWW9N/SR3WZGe4lI7/5GX57Gq/0igA+DxcOZ3y/whgA kzsZ3QsSudCE13Os8/5ExGXn0F/0PHZujDs85pwFgZDcTlxBlhvyZPYGr+UK4izMdQdYJpbzQmA5 qHJ23QddUWOeGuLn8XAi3IwXjhH8uDp8ZpCid+G765Iis8wz1X2COr8MAl6aXRn/oRXxeDIWjeVz A2lijuw4dZjC8cQPdz32wAMPzheLDcdBFOE9GcYyBAkgtQwut1SGdBqReAhxhqNUg/W5+SI6jB0O pVMp9kYiGfQS3IHtVMghfQxJg2NRHHFI5UniF/LUEWbEmwqDEqKKuLh4E/wIHgOtIb0Mdy/yT4ci 3VSGknQxuNPYrht/ZNcUldNe8uLNnXalWcMWJRUJJImMFCKA1eB5TL4aMvyRfVhsSrgBQ19EdDmr ytBhITJYlQxtYWvhNR5aMnfGYWYZ9FZ31RldaHV3ujZ7A1gGHl5GfO6YT9I+j4uog4cBbytTrYkL zzuFNwuDVj9Bnrz4aM/RGSp4J/Z50DVrxnALj+EvryoG0WXOqP+WS3WeD0pGUADk65wRdKlma7b8 IvvDe4DbCXKGRIfQwjvC7zmnyVqUQlFTz534yGYtpw+ZY1g6d2XvrxU17vNOQ7Kmz1x07kluyGWe hf5b9va76zcaBmZZKMIHP/hB7rGuNYvMruiKQAohx2iKvgVnkT1e6CIecCOBcBG5vv5u6CHqGpfb N7j4q7ji9AeCBaQ8Sgsvvd+SmRU1pj2XjP6wZ6bu/Sw6f0mRWfSIunAhAoZ6diuR375HzPdSX6nT TsQTqXQmAaGJxVFUiP2ZqVb/1//3vx5+aNf01HSLrC81p9miOraXUpwajW492nau2zFYyCaQRJgw Vg0PDY0ODw0mM/lcfnBgICGVHUnsgiYif+14Aj4ilUpI08vbCbNRAKJjIwihvDSJlHJrjWargcWq 3cbU4DTbH//0Zx/ff7QdTUGt4FAhkgjbNsoLUdnoOzdct+G6a4esULUVbSUThdHhHbmBDVactDUz 9dJUzG2MxBPxQBg9qRqKNBLJeixRCQZLdRyKA/FQimTE2Vh649BIJpacmZzBYQMhB3OUGNpwEA6F 7nj1T/kwLkTPX7UqM+talVn+DGF+fb4Ilt8PN0Z39prlG7OWQeti0nGed/8X2YDXdPebepm99d9y qZ3wqboi6Jbaz2otv8j+8OwhszEt7A/j38KFZglDIKaKpdb2LF9R4z7vNFgFY38/w3//LXu63f0T FZOfqKTn5TE0W9EVgXYvw7y7+3AB87zZ/ZyB3ZvTwx4VzV/L/cB1X+bS+y2ZWVFj2sONmLr3sMz8 JUVmmePqquURkIAjik1bFt8wqWSaWkuxGPQjzkLoxsGDh/c9vR/6QrHpUn2e4R0WItn0RL1gwiTU qcFvkjbGIqgwnyM88ulMMha2Q6UyXjLsJIGHbyjSlljoEJWbkEJc+Eu7Y0VRgqhvTaIXAofEO1dE lGZLHL/awUI+T+2nerFYmZ8ncx4uyJL4JhKE90AxhHu1Q7VqaM/u8VKxcu21hXiekk/sREI6omK2 4rOIQG7EGtIAhwnbxsjUDQU/pENnF8kZnXH2Pbtozf/7LKYya46VHlAReK4jgP6ExwkoXCJL4nMd Xz3/ZxUCxXKRJLy2TfhSjO+EsEUctleZIBSuOQ522PnSPMM8VMax6i2y0YmBCZoTalEJKUigBo66 EidEBpcwqWRaLdgMXzsUQKKCUqKawQ4lpZsI8Ca5rnj1kuMFEoMTjY3XOBvi7ot9C86BmYfiTRAX nC6Gh0aTiSS+w9FIKBGz65VSIptH2bFs4hnDWI5sNpfMIZL7bnK6Un6seuPzt1AboeVyqJjHSyAx 7BLDmVSXbFPpSWxZYksSzxnZVNbLf886xUgfvAay9HJMSmUuB+p6TEXgWYWA8S/GMxcnWV6gxMEt qnA8q85JO6sIXCwCpG8hba4JUMZhhWx3mJbGxsaJh7jn3nsffOxJNJJkLNkKtDCb4tjLE4Q5ighn 6hhwbEiDlI5sNLFIUT8SmuPU6+MTE/i94BAcCUfbTTxXSCIcIEwKAkR7yAsuN/iykBSvCReSmGpJ 6MI0NTtbnZseGhhKpZJEUsEyYE0333T9D598cm5mMlkYDkbjpP6FbGE4x+2YgtwQpkYr7ZasPU+e joYGYpHhwcEwG3px1c0QVEYKYeJFI/QGonImt++Z6CWWsEJcZTwWc7FgXuT2SmUuEkDdXBG48hHA FffOO+8054ldiUQJV/456xkqAudDgEClVoeS01UsPU0JWmrd/d17P/fZzx8+dARukRkcRB2hqBHh zDjQpjIZ220Ui3ONRp0YIwQSqIK4zwgh6aCHcLRGiAijcoCAbpiLRFMztQq5AjFIkB3sTcGwhWut 0B+pWSDVKAlWosRStVYnYCGXSuRyeVIGo9TQMeST7Vu2Xr19274jx51KER0okR/pBMJOs8G+KbSE Gcx1m1Yk6tSCDz301GOPH7juxh0vedlN2QzWLyobIAZFKSEVCqInocNAjyRu3Ggx0mkJYhLnQdiM OA17DsCi2dBG/uPNys+1mJ6LVIaAYTjywniBtcBbj6EIPAsRwH+I5DS8VnEcIYqnfyePZ+G5apcV gX4RcFv1IC63brlRs+xY2mkWv/ClLx85RogAPCBgRyx4SsSy6x23Vm9QBInB3YqRW4i8dm0atKIh lBVhJRAVUusSryS1liLVWnVicrJCtrxqBRmHpDKDrptKZkhkF45amUy63QzUynXICnJIFXcbt4Fg ksPlP5vCU4e9QTHQfsKB0EAhf8tN11MLvm21K+WJSjiYSA/RJepMYuAiOR/R3G232gonS1Un5Dh3 f+/BJ/c8tXmosHVD/qpNQ9HNnVwiFBPWQ9SV/BPPHBFoJNsM/8TrB2lGTEvsStQbcbABPzZ4xpem Xzwvpt1zkcqQ5IrpYlDTbRWB5xQC+Lm/+93vfk6dsp6sInBeBNqhOpWSkE+oNh0IW6fG5tymi9zS ojpjhBhpCiG5wSCOMNRnsurVKnYfJJAgpZkoytRqkTCGCtbQHbgBrjbwADIHs1WlQm7eGqFIXpDp XCaVJsZ7oDBg2wky71XKGUJVCFKtVYlXcvHkzRUKeNjECNlOUaRJ0oiITBIkXjtEnr1rd+58aNdj lJ+MB0PTsyVCupO5Aod2pcal/CGHDfKLjRuNOCZb01PF2emZfU+38+lYLh0nTHfTyNDWnVelRwdZ S0ZhcQPGmgaF8QxcQly8I/p/vQViPjMza/P3uUhl1gZZPYoioAgoAorAFYyA45alzFGjmYplZ2fr Dz78ZLE473mOuKJTiA1GyghAZMg0Q2UkScUr1qMIbizYlSimTbY7oqxRMrAoRaEzVgQ+AQlwHNE7 mq5bLM2VyvOkHTl56ng4Qto84qWiJDeKJ5OUdxoZ3UB2V5v6JBErk85EY4ROI7bAIThyIByhkEEw l80mEzFy56Wy6XA0gZ9vvJXB/5j6lygy9UqN0Op4zIULzRaLRJSXGi6R241Oe6zYHCsWQ+3Z5P7T yScOZQfzG3ds3XLVNgwaUaxdEj9F5Ul4GIdDiTnrMGPSAAubkry1azYplVkzqPVAioAioAgoAlcO AnU3UKvUy3PVY6Xp3bsPTs9UHKozUva66WK+wRGYIZ/wJYgKZAU+A60h966X6x/9Ay5AnpcYTjBe BuAIvjZEK4FOPJ5oNtOVWkXYUAdphwR6/CXdXbMTS0Qt8tfkN45uzOQKeUmDiZknxGEo+ITvMJQI skSRAxFmQoRGRUVB6QSTqQSJ8goDOYQZ3HtCHbFkYYqKRMSxBm+bZDsJ36JqAsUR0IkwQrU6VoeO B5puvV10quMztSPHp+I/3L1p88adO6/aefXV6WRGEuqJjwz+yCaGW/QZWSCHX9MLrVRmTeHWgykC ioAioAhcGQgc3D85OT4xP1s8cfR0rdpMpXIk8IUcuPUKaoW4lCCN4FpLTYBWm5wxtVoV2uE5mASl YiMjPgoMRZCI5caJBtElKuYhsuBFs3atlsBcBUOAylBCAPmHtvGonc1mRodHRkZH7FgCJYQYcLLZ IMzAZmBH0BeS88qBhVAgzIRL8yXHqUezSTfQjlqhfC41MT0xNLoZXoWAAuFi/4R81xsuSXEqpQrV m/AqpgaTK/nuJJswveToWJ86Ldcp12vF6tjJ8ZPHTt/2yldcd/VOuZQcy5NlmPMOLkSGvsmqtZqU yqwV0nocRUARUAQUgSsIgYfvP+A6tabjzExUUEpwOLGjcbdDIQBJ/k90EQSECCPITavVwHMFWsCg L4ntPOcYiAdxSGg4Qew1dsyTV0jKi9UpbEei+eEcTUk2jVsNhAMaYTgQxIU9O/gRRyAwcfyN7Vgc k5NshxYkjjtSvRpLE8HY2Lgq9Zp44iLXSE6bTiaTPHT0WNYZTCVzLcm6R5yUW3dRYkieR30DksiE Ce7mcJa3iuBv9oTBSgpnd/By7lB3sl5u7HvqQLsTHsoPbBwZ5XBiafLcY+ik0WXO+s+s0fVWKrNG QOthFAFFQBFQBK4kBEozdSkYQHmkZgD+AeWAUjRdhzS+nCZJdUmhC6tBGgm5Aa8UuiRigVDATKic TZkmoQyd1vR8aSCbjaUSRGTbViRl4QsTjyWSpBAeHe2gzVQqZUQcBJ1Ou4nuEo0lpHhBhOLbRCxR wjKOV4wQEU8JEqMUrCJMFr4ObsmnJ8Zwq4nFY2UqaruNZIqq25FapZxLF4itTiYT5UqxWqm1clCW UCRqwb2gNrAZoUKSnEY8byhV2YSEBSmdjZATwCkZFempx/d+zbauvuqqTCIph4bMQNPO2JXWVJLh 6EplAEEnRUARUAQUAUVgZQjUq2VYSqfpdFqNTstBCYlGI1RxZKbeqMclm64IM1anja9uKNCkvgEr scEEOk7UjhCELX4uwXCFYnbTMxtHRuI2gUydeNhOZqhrlLZidjJN+SSKDFScWtXzemkhrhCNFIun 4DroMVAZ3IBJXiOWHcmdR0AVZSM9C0+wPTE9ue/gAdxZyCETIcENMlAwEI2ECc/OpAejSEGkCa5X 8/nBVDyB+EMBpkqx1qRhWCohkJiv3YLJNKFRFI/CA4cMeyRlgC0hvkCXHtn1yLe+9a23vP6NxEBB n2TpmWhsmVkZmhfXWqnMxeGnWysCioAioAg8JxHwak7jYltrNSvNVjyEpchOEIVElBHlmRjygyGH /L/QBUSWRtDBsdd1pfYk5Q2itiW0AiWkDWMIlWu1o8eP33DtTgo42iG8hVFlkFuSVHjCghRPpamj zQ47jToJW3CqoUXUTlKLAK9hIRb8g0vAOpBkPGEEAgSNOn7yOFyJmPAKbjqWjUMLlMNtNWZmpufn i9lcaHZ2hr4VMim4EHJMOGYTYYUDTkNcc9BgcJQh4S+EK0z4NRW40Yg4FsamNjn8Om691bjry18e Lgxcv/NqEY085x/PVUe8gNbyppAMgzopAoqAIqAIKAKKwIoQoN6AEAwcTVrQBbLv4vzStrH1hCOI GY1qPYT3bLuFIy7sApaAmIJo4jZxpmlb4UjCslIxSlFGJQNMKnVkbvb+vXuKnVYsno5EqZcE87Ft /kpWGgxJZI3JpnIDqexAMp2F6GBhkjqSEjkkHjhYhNodajPh6SK564hOKlecfQePOTjvRqKJdKId wokYmhGBhrhOY3Z2cq44hVMvtb4TmWwrGCoTmE2ivFYngYaEn3I4FIVymRqYktOPjHoSS0XwOG49 tYZXP6oVGZ+Y+9Q/fWb3nqcJh2L/UArUGWE/HqNZEZ4X01ipzMWgp9sqAoqAIqAIPEcRIC4J85Ao Fi3JeodNBVaBCSYSRYkJug5ZZMSXl7pL1AdghCc0yY6LSMNPXFuIvbbCobgdswhc4mc8UXWb+48e ozQSKWHYD7HcCbx8oTIyD0eiaKUNY6AxO/NAFwVGwpZEEoFriE3HozLi5Hvy1KmZuWIJgsLhiIqK 2SSMIVTbxV4UCZcrYrEqDA3Ek3F8a+pk5avj+sMZwWCkSgJ5bjw6Io7A5ixk1/JPCiZwAIQgKV3Q Dpw8dfqur/z7bHGOk8dj2GvC6aoq8xx9LvS0FQFFQBFQBJ41CEBRvDhkfGRbBDzDAzyGESKmiJEe e1CdpXAEFBsUjVYLhxLsRkgsKBoUX4JeeI4v4vlCut50OgtTcRrNOaeC6w22J7gAEdryD3uSuMUQ i015gyjkCQIjJhxxzRVRRoiD53njzQbYMQUN9h/cjwNNU2KqxQBlhWNoQ3jNEP89PLxhw8ZN6VwO vQhdiW5IwJXk8JWJC0D/WcLEPNyFBqSgYaGswu+Y4pfYn0xMlnQmePTE8e/d+32qY7KWiW1YuJYX Un1l1hJtPZYioAgoAorAFYIAY7mkU4EghBFmcMiVfL243mIQgnM4NXgMyVpErelQj4DCjDQgbZ1E CbWq1Vomm6Kl6DrBUCxGhjoEG9FxpqrFfHi43nZjUvKazHbkB44SmE0NJ4kgEr9halZDGNgQ3uFl cBFfGYiNhEThFcwuT4+NHTl+HLqTSCbrLhzFct3W44/tzmQHBwZGghGioCSlXpMILP55yfu4KhwP mgVTMeTG/GU5x2Eh3eYM+UszZjgtZmSVlD4I731q//Dg8IteeCvnKDnz1tbtVw1MV8hDpaehCCgC ioAisJYI5HIZcT6BRgRDEAVoB3QCEQVfGaxFhEuTfc5hqpM7pomDL3/JB4PCQuaV+fl5cs9Q1cgT PKypqek9e/ZOTExjB5oulZ86dKCMG47kqSMZL3RFNBB4Et4z/IMoEa8NmfBYC8IMRAIaA+OBoljI OcdOHP/W3d85NTFBHzZs3jI4NEQW38NHTh46cmJyeo5YcRIKo/TQOCwaT4Q90Dd4CegZWiPKivgX i3BEhDk/5RTITCMdEcrGWmY4LPyM06cwZblWv/f798+XKig9QBIOSbq/NZtUlVkzqPVAioAioAgo AlcOAlu2bpkvlaTSEe4jkl/GTRCOJJIGTCPWchMtsv9SOrvVIh8vbKDTbNaq9USMoKR4tVpy3Ga8 2aJm5KmTY5OT0xAegomwJ8V2bjk9OdNq7nWvbm/fvDkWTAqlEBcZ6k+jA8Fs2pAF+a9MwmOQZKAV UJFGrfH0wQMPPPzQE3v34HETIQONZSVD4ampuaefPjQ4OAQTgop4dCTaarachmP4Cg49GLmQUugn OzW0hp9EY9HYCDC09DkNV5E2rBU7UihIQmOy0szOz1MLs5DNQWbwUl7LK61UZi3R1mMpAoqAIqAI XCEIvOkNr3/8iSc9mw8GJgcHGDgNPrZYl6ALsWiMApKIMjEisOv1eMpi7Md8k4zbmWwefkNivcmp mRPHj5PIzmM/Qeo37dr1aKNZ37px0/Rc6dE9T02Sb2Z0w/bt20eGB4W2iFsx9imKCpDvRSxXHBFR xVCKUr2668knHnvi8SPHjgYsO5XJTE5No4+Mj4+fODFGUph4IkNxJexFlCZotqokv4EG5TJpCBC+ NflCQahRMEj+m0qlwv7pMDyGvzAYtBlmWGiYDTO0hD8hRjFDTyBOyWgKUiU6VaAzMjpKmzWbwn/4 h3+4ZgfTAykCioAioAgoAs9GBJBP6HY6nfY7f+ONN3zn7rtPnz6NDYkK2eK6m8kx2hNHTWMoS6NR R7OANYQikQxaRSBQr9VQWKhinSH+ud0sleZRSKwImo14zMAMyO07fnpybHwSl2Fowcmx8ZNjp6bn ZkgMk8lmU8kUbMYjT8I52DmijFCNcKhar9/z8IOP7X5iZn7u1Ph4YXh4bGx8amZuYnzq9OlxJJ9s fpDswJh+oB2cAuyEUgeZdBrV5eSJk+wkl8uxCkOSpPKLRFgC3WIGnsRy5pnhmFAZtuUnO8HShf8y Bi+EHuxlGNQ2jo5s2DiSSiZvuO5Gr4Nn0FqIng/jqswolVkVGHUnioAioAgoAlcyAgsHYwb119z+ 49//wX0nThz3vGVtKAqEBFNLrVq1qImEDSjQkUAnyhoQ5ExBghjuwDX+C51oNEmaZyVxWwmLmy2U wUQrWcFoveFMz8zOzM0dO3Xi9PhYIpFouM7s7CxKD/PYk0QgQfognwy57Tpt+nbv9+/dfeQQOtDx kycJMYonEuJnTE8qtfliKZFI46Mj1igKPIloJIUPoCZRy8LMdOgQtqfBbDYLj4F/0IjT4VrCaWjM DMuNxwwbGlrDQm/zCByOeVgXMzgQE8H9wlte8KJbX8xalvvTQvT8Vasyo1RmVWDUnSgCioAioAhc yQgsOhjjEfK2//7W4eFh8ueWSmVkD3xlpDg26opTSyTiWJigBtVaXQozEcZs2TgLEx8NJ8Cpxotg kggg0scgd0AXCBTKJNLIO5lsxnEbREGV5uePHDk8PjZO0t5qqRwJRXKFAhqOhzUZeFuVWuW+++47 cvSIg7mn0y6Vy5iKqJtNpJHjNKYmp4ilGhgYCltQGdFxsHlBR+AruWwGPjM+NjZXLG7atMnYlShR yZ6hSrQxPAZaw0+vw0QqCYsyP2mGqUuMXt5uoW47r7rqja997Wte9WrOqOdWWBS9njYX8/OM1nQx u9BtFQFFQBFQBBSBKxuBsbExRvfR0VFv5L6yz3WVzw7cQA/cQG+Vd312dxqMfRYJ/a8ioAgoAoqA IrAEAniNsAZJY4n1unhJBAxoBsAlG13cCqUyF4efbq0IKAKKgCLwHEDAWF7IB4PG8Bw43VU7ReAC NHZnAFy1/Z67I6Uy5+KhvxQBRUARUAQUgQUI4G+LroBvyuTkZL1eV0KzAKHeBUAEUMAFaEAHgL0t Vu+3+sqsHpa6J0VAEVAEFIErFwGG5JmZGcJ5rtxTvCRnBo8p4KrslXC6JAfAmVmp5SVCVnerCCgC ioAicIUhwIhZpX5SrQah0dFz+YuLny8kBrsSesyl9pVWKrP8tdC1ioAioAgoAoqAIrCuEVBfmXV9 ebRzioAioAgoAoqAIrA8AkpllsdH1yoCioAioAgoAorAukZAqcy6vjzaOUVAEVAEFAFFQBFYHgGl Msvjo2sVAUVAEVAEFAFFYF0joFRmXV8e7ZwioAgoAoqAIqAILI9AhJKYy7fQtYqAIqAIKAKKgCKg CKxbBFSVWbeXRjumCCgCioAioAgoAudHIEj97vO30haKgCKgCCgCioAioAisSwRUlVmXl0U7pQgo AoqAIqAIKAL9IaBUpj+ctJUioAgoAoqAIqAIrEsElMqsy8uinVIEFAFFQBFQBBSB/hBQKtMfTtpK EVAEFAFFQBFQBNYlAkpl1uVl0U4pAoqAIqAIKAKKQH8IKJXpDydtpQgoAoqAIqAIKALrEgGlMuvy sminFAFFQBFQBBQBRaA/BJTK9IeTtlIEFAFFQBFQBBSBdYmAUpl1eVm0U4qAIqAIKAKKgCLQHwJK ZfrDSVspAoqAIqAIKAKKwLpEQKnMurws2ilFQBFQBBQBRUAR6A8BpTL94aStFAFFQBFQBBQBRWBd IqBUZl1eFu2UIqAIKAKKgCKgCPSHgFKZ/nDSVoqAIqAIKAKKgCKwLhFQKrMuL4t2ShFQBBQBRUAR UAT6Q0CpTH84aStFQBFQBBQBRUARWJcIKJVZl5dFO6UIKAKKgCKgCCgC/SGgVKY/nLSVIqAIKAKK gCKgCKxLBJTKrMvLop1SBBQBRUARUAQUgf4QUCrTH07aShFQBBQBRUARUATWJQJKZdblZdFOKQKK gCKgCCgCikB/CCiV6Q8nbaUIKAKKgCKgCCgC6xIBpTLr8rJopxQBRUARUAQUAUWgPwSUyvSHk7ZS BBQBRUARUAQUgXWJgFKZdXlZtFOKgCKgCCgCioAi0B8CSmX6w0lbKQKKgCKgCCgCisC6RECpzLq8 LNopRUARUAQUAUVAEegPAaUy/eGkrRQBRUARUAQUAUVgXSKgVGZdXhbtlCKgCCgCioAioAj0h4BS mf5w0laKgCKgCCgCioAisC4RUCqzLi+LdkoRUAQUAUVAEVAE+kNAqUx/OGkrRUARUAQUAUVAEViX CCiVWZeXRTulCCgCioAioAgoAv0hoFSmP5y0lSKgCCgCioAioAisSwSUyqzLy6KdUgQUAUVAEVAE FIH+EFAq0x9O2koRUAQUAUVAEVAE1iUCSmXW5WXRTikCioAioAgoAopAfwgolekPJ22lCCgCioAi oAgoAusSAaUy6/KyaKcUAUVAEVAEFAFFoD8ElMr0h5O2UgQUAUVAEVAEFIF1iUDkUvfq93//9w8c OLD8USKRyLZt23bu3Pnyl7/8xhtvXL7xpVt7+vTpD3zgA/7+3/ve995xxx3+T51ZJwhc9sv0oQ99 6Hvf+55BI5/Pf+QjH1knyGg3FAFFQBF4biLw/7N35nG3TnX/fx2ccJwMmacypEmiQiohTRQioVAy lJlEPaVHSYkkUykR0YDMGZIhVCQSTShlylBEhg6Hczh+78f39Xx/67n2vve9733f1332de/3/uOc da1rje917Xt99nd917pqlzL//Oc/77nnnmHh3nnnnVddddWJJ564+eab77rrrlOmTBk2y5gneOaZ Z8qmTps2bcyrsMDRE5jtw/Twww/nc/Lkk0+OvkeWIAEJSEACoyHQXwtMzz333FlnnfVf//Vfo+mS eSUgAQlIQAISGBwCtVtlekB5ww03nHPOOe973/t6yDuaLHPOOeciiyySJcwzzzwZNtA/BGb7ML3w hS/M5+RFL3pR/5CxJRKQgAQGk8CkGTNm1NrzHXbY4dZbb80qjjrqqFe/+tV5iRnm3//+9+9+97sT TjjhoYceyvgXv/jFP/rRj/LSgAQkIAEJSEACEmhLYLytMpg65ptvvrIpU6dORbgsv/zyuNlmPL4I 06dPn3feeTPGgAQkIAEJSEACEmglMN5SprUFEbPKKqssuOCCjz76aFxirbnvvvvY01RJj8flz372 s788/7n33nvZP8LWp3c8/3nBC16Qic8991zuxuUcc8yxyy67sCqRdwn85z//OfnkkzPmbW97Gzun qP373/9+Rq6//vorr7xyXkagywbg7HzmmWdm3tVWW+0tb3lLXhL48Y9//Pe//z1iWKTYZpttyrs3 33zzFVdckTGbbrrpsssum5etARyM2NcT8a997WvXXnttCP30pz+95ZZb7rjjDpQiljAIr7feemwW a80eMV12LRK31og37k9+8pOLLroID+6llloKvBWeH/rQhxji66677le/+hV2OBC9/OUvB/u73/1u WhjFXn755awtUgKlUciKK6744Q9/eLnllou78W+l2Mow8eTcdNNN9B0C9IiBnn/++RdeeGEq2mij jdrujxtplksvvZTCozHocuyOZfMijCXymmuuYe/e7bff/sgjj6DUeZhXWmklOtu6cIlwP++887IQ HtfJkyf/4he/uPbaa3//+9//61//ggAl8JivscYamSwDI21/ZjQgAQlIYGIQGO8FpuOOO27VVVdt y26LLbZI/UGCCy64ID0SIj2z+1e+8pXHH3+8NftrXvMabjFTxi3m0XKL7LHHHvu6172uzMVU94Uv fCFjmD6XXHJJZpQtt9wyI/E+RkPkJYHuG8Cy3YYbbpjbW1ASrKCVRTGlMcNFDDLrsssuK01Qhx56 KFon7jKrXXzxxRVTVlkUYQxaf/zjHyPygx/84Bve8IZPf/rTTz31VCXZ6quvfvDBBzO1V+K57L5r kbdS43bbbbfffvv96U9/iruLLbYY7a/wPOOMM+hmhQPpmdoZOybpww8/nIGIEvJflOhHP/rRj3zk IxlTKbYcJjadffzjH0cIZuJKgN3+hxxyyNxzz53xPWQ58MADL7nkkigBkXThhRdmaQTAzrPH8igK o4yPMI/ZZz7zmYoiuf7668tTABDrP/jBD7773e+2ZofzzjvvPGnSpLzVQ/szrwEJSEACE4NAv+xg YgJIuwJkESUVh8ovf/nLn/3sZ9vqGNL/4Q9/2HHHHe+6664YFawsEYh/+YFbXhLOc0EI80udCaaS oPVyRA3ARMSsmYVgHSm3dt99992pY0jz7LPP8uM7ExPAdJGXr3/96zvrmEwZgd/85jeoilYdw138 qXfaaSfMIZUsI+paJS+XzNnoidQxrQki5phjjmnVMdyiqTTgoIMOatUx3J01a9bxxx/P+A5VbMY/ /fTTe+65ZwcdQ0rsHMDB5BO5esiS1bUN4Pi17bbbnn766W11DFl4yPfaa6/vfOc7bbNH5BFHHNGz 4qHcAABAAElEQVRWx3D3lFNOufrqqzPvmLc/SzYgAQlIoEEE+kLKMF1985vfZEZPcBgt+Dmel5j0 MdLkJcZ29jfx8/Sd73xnrhzdf//9n/rUpyiKZCzHsHiR6UvhQuTMmTN//etf591uzsEbaQMonNWc rIJW/fa3v81LVkAyHIEbb7wxY7A6lGqjLCfTdAiwqMFUzcE8LDMhXMiON1Kmp/CKnuiha1laBK68 8sqKFKskiMuYg1kzete73sW/ZZoHHngAOxkx6FcajPWoXIVBFnSe+6MotNSf//znLHb77bc/++yz MZlg7Nlkk00yHj2Xre0hS5bTNoBcY2E0by2xxBKsarEChRkG61rGn3TSSaUvfMZHgEU6AiussAIr ShjYShTEo5My/Zi3P0s2IAEJSKBBBIb0nKipD+eff34pI5ilsE8wtWCoyBpRKsxDeYm7A/ue8pJ1 KKzxqWDQNLvvvnvIIOZpDDAx9zMNpEMDKocJPj1vmMxy6YdicbbIwtsGemsAVhlmL2RTlImhZd11 140wniKVikopw3JD3mUpoeJkk7c6BBAErKmliwmWgN122y3lEYsjWLDwRKGE3rpWqRohQgyGKKbt V77ylZi4sBZU0sQl6pMlklgfYUo++uijy2RrrbXWYYcdFlM+LiYkfuKJJyIBHj9lyrbhkipKjmWp qOjNz394Bhj3yMhDgq2LcA9Z2lYdkQxcLjwRg5TE2pQKhof8E5/4RDx4PPasISJo8jGuFIso32yz zSISFCzn5RPLo8JDFcWObfsrbfBSAhKQQFMIjLeUwTO0M5q3vvWt++yzT2lI4Ld1Lscss8wy2OfL CQDPG35z4+cbxeK3G1KGNaZvfOMbWReGmZQypZEGZ9jFF188k7UN9NYAVoWwLrCiEWWy7pOFp3Bh ro2VCMwJzFVxxnEpZWheZaEtC+kQwFEmdQzJ0BY4BqEMIguyD7cVfEq47K1rrVXjf/21r30NHdN6 K2NYyCtdXnBLwqekXAhj6Scnfsw2KL98WsKBlwNdsrTWQLlACUxE83vf+95Mtu+++2aCLCdjSNZl liywNYCDS0bikIRbUnaHeB7UPfbYA60WaW677TYGulyFzLykTB1DJCjQ5ek7RQw0sPcQGNv2ZwMM SEACEmgWgf+/iNMP7V500UX5Zc+/ZWPKVYM111wTj1pmnfLDr/lMj1dKGAn4W48OyPh0l0E6lN4G Fa+aTF8GemsAJaQZhjAezTHxsADBnpQoH9fgCKS7DGtD5VJUWUKkHPZfVMWb3vSmSjLcolmwyMh8 K1bPXcuiIoBG6axjSFYOB5csIJbbshivpZdeuiy2bDDxQ7lJZZbyvCIiMXvgtsLCJWqSvGg7dEN8 MmUGopBusmR1rQHMJxnJIlq5pS7iWQ8tPY7L9JmRwDrrrFNeEn7FK15RxiBl4nJs219WYVgCEpBA gwiMt1WmMxrmeH4941vA6kCmLP/i4xna1jk0ExPA9TIMLTjB5L4e5uwHH3yQnTX4KKSSwCgy7OoS BfbcAOYk9uaE3YVy+BWOnSAXBagdXxZ8RMK/B1MNEy1SLFdVyNKDlOFHfGm1opD4IDVymSb9OXru 2v+W+j//U93GG29cxrQNl8IlEpRGCxRYJVfFR6Ryt/USex77htL1mwT0jk9ssMcmh+TFgFc2o4cs rfVGzGOPPcaDl3df9rKXZTgDGOpY12OrecRkIBNEoLJxj8gKnFy/G8P2V9rgpQQkIIEGERhvqwy7 M5i884PZnO3ZG2ywQYkMH4J0c8EGk/NumaZDOFejsLiEt0QkDmNMmmeIxJJfsQC1FjuaBjADUUWW GfuScnWJ2Y6ln/zBHfHl6hKipGKoyKI6BNge3PZuOUGi6jD/jKZrZRXUWO4kL2+V4VaBVXp2l7Im cpVjV5YzVHiBBRbA65blxbYZMUSxAPSBD3wAL+DQjpTTQ5ahai8lFGmGWhYs4ytZsmRaleEIDHUa 0Bi2v1KjlxKQgAQaRGC8rTK4g1T+UmMpYb7HdFG6TKJ1YgsSVnqmSZaTginioJK9lTWTdEQyxXJe XEoHRAw+wqWjTDerS6NpAM3ArJJmGFaOmERz+1J4nrK3BUsMKVFv2GNKKdODSYZyklVAyH/zpzwx TI0IC/7tmW0WS6AUSWX8+IcRphwbg/c3shWSbOGu0IA/7kF0PFyFaGEPWdr2K880irucVd02WRk/ 1JPcVoq1LY3IsWr/UOUbLwEJSKD/CYy3lBmKCD+XSylTHlKCz0Re8pubzR1DFdIaj79kShmUBL6W ucjChNHN6hJljqYByJHcp4PHBnIqXTVTynBYCLXgLsMxuCFroiO9SZlwFWpFgSUmI1nmiPlyNF3L 0lrNLXlrtgRYQuKcQD4g/etf/8qpuzxa6JtsDEfr4oFbmjp6yJKlRQCHdAxLuWGtpF2mLOOxupW3 RhMefftHU7t5JSABCcxeAuO9wDRUb1ltKRcpykWl0v2TmaltCcwQbDaOTy4fkBLpkxMt1pqvfvWr mZ3zf0trf8a3BkbTAJaQSreJPIOYtZVYe8IZNl1BOT2F2TcagBtsmbG1VUPFINdKepGMjULlsXvM uxE/mq4N1YDZEs+gcxxLfkIxMPSs37Hz/NRTTy1lKwYqFG0PWTp0jbry9Qsku+qqq1oTc3xf+c5U Dh1oTdN9zNi2v/t6TSkBCUig3wj0i5Rhai83RXPeSZLCGTbDmGfKJZiI50c27rTsX+XDht7SPo/Z vzwkPq07ZOxmdSnKH00DKAE5FeXwb7pHMMXGGb4sYKU/Tb6ViZS9mWSiIg7BS1/jiOEQl9KbOHuU AZKNlG2U3Cf/8vzgCvOl//2UFj5aiAGmsqsLpdhDls6dLXfSsbaV+/AjF0q6POgPEw6rn50L7Hx3 zNvfuTrvSkACEuhbAv0iZQBU+qvydz9PHEEKsAc7Ce6///4ci8IyDb+tWTNi+QZHzrzL2wdLKUN8 28N8+Q3N7o/M1Tkwyga0FSXlO6FKsZUtaZsr73YOMJEfcMABnMkGQ7Zuff3rX09rEBnxrsgNR6Ps WudmjPPd8iH53ve+V77BgLdG5MlDtIqVnXgRVQ9ZOnSKnXc4fmUCXubAg8rZj/jrcKoQC6Pl4ZAc AonFLhP3Fhjb9vfWBnNJQAISmO0E+sVXBhClVYZLDs/I/TvYWnh3dDgiYF048vlPKzsWa1ptLWgC dkSnE0PkQklU/DRbSytjRtMAFnFY0CnflEnJ4SgTVbRKGdrGSTBlA0Ya5pWEfNrmYhIttwuNpmtt y59dkRzSw4a48G5Gu7DRnWNXcCLhgamc78yhL9HIHrJ06B0u7cBMXy4eOZ7Ttuk55Ib3hLe9NaLI sW3/iKo2sQQkIIH+IdBHVpnyrUkASv9cwkxIHN3Lvx3AMfczc6RnTKbk4ODS8h/xbU01maU1MJoG UBrGj7JMGpmLSsTjE1N5WzVn3rd2pCyhQ5j5G9NU2wTYq3jhIstw5d1Rdq0savaGWbPDPpeORzSG JTNeKo6rdbmPaauttkoZ0UOWzn3kLRO8N3uorUmRl0U9XsRROh13LrPD3TFvf4e6vCUBCUigbwn0 r5SpuDugVFg1YFtK5bgwyGK84V0HrDQN9QbpinBBJfSwfDOaBlSq4wj/0scZhcErDspHpJK+vDVs mNJ23XVX3l1QgiKSVRVm+q233rq1hNF0rbW02RgDRg4lYst92ycBUxwvcMht2NHOHrJ07iAmn9NO O42jksqXb5CFIUA1InQ4WqligOxcYOe7Y97+ztV5VwISkEAfEpjEOWl92KzOTeIQPE5xZb8SJ5rg cMAMgQtk5yxje3e2N6DSHV43mOcas8p2/PHHRwLeocjubparOOq37exeKYfLfutaawu7icFJCB9q tguxTIlq5Dlh/3npyNJaSA9ZWgupxLCRigf10UcfZUWJ/UojPb+4Ulrnyzra37lG70pAAhLoEwKN lDJ9wq5/mjGUlOmfFtoSCUhAAhKQQE0ExtWYUVMfLFYCEpCABCQggYEloJQZ2KG34xKQgAQkIIGJ QEApMxFG0T5IQAISkIAEBpZAH50rM7BjMPqO41WaL9EkPPoCLUECEpCABCTQFAK6/TZlpGynBCQg AQlIQAJtCLjA1AaKURKQgAQkIAEJNIWAUqYpI2U7JSABCUhAAhJoQ0Ap0waKURKQgAQkIAEJNIWA UqYpI2U7JSABCUhAAhJoQ0Ap0waKURKQgAQkIAEJNIWAUqYpI2U7JSABCUhAAhJoQ0Ap0waKURKQ gAQkIAEJNIWAUqYpI2U7JSABCUhAAhJoQ0Ap0waKURKQgAQkIAEJNIWAUqYpI2U7JSABCUhAAhJo Q0Ap0waKURKQgAQkIAEJNIWAUqYpI2U7JSABCUhAAhJoQ0Ap0waKURKQgAQkIAEJNIXAXHU39Lnn nps2bdqTTz45c+ZMwnVXZ/kSkIAEJCABCcx2ApMmTZo8efKUKVOmTp1KuNb2TJoxY0Z9FTzzzDMP PfQQIqa+KixZAhKQgAQkIIG+JYCgWWSRReaaq0bTSY1SBhvMAw88gI6hAwsvvPC88847xxyuZ/Xt w2bDJCABCUhAAmNGYNasWdOnT3/44YcxaqBmFl988fpsMzVqC9aVQscsvfTS8803nzpmzB4QC5KA BCQgAQn0NwEmfaZ+BADmDMQAkqC+9tYoZfCPod3YY+acc876OmDJEpCABCQgAQn0JwEEADKAtoUk qKmRNUqZcJFhXammplusBCQgAQlIQAJ9TiBkQEiCmppao5SJ/UquK9U0chYrAQlIQAIS6H8CIQNq 3cJco5Tpf762UAISkIAEJCCBphNQyjR9BG2/BCQgAQlIYKAJKGUGevjtvAQkIAEJSKDpBJQyTR9B 2y8BCUhAAhIYaAJKmYEefjsvAQlIQAISaDoBpUzTR9D2S0ACEpCABAaagFJmoIffzktAAhKQgASa TkAp0/QRtP0SkIAEJCCBgSaglBno4bfzEpCABCQggaYTUMo0fQRtvwQkIAEJSGCgCShlBnr47bwE JCABCUig6QSUMk0fQdsvAQlIQAISGGgCSpmBHn47LwEJSEACEmg6AaVM00fQ9ktAAhKQgAQGmoBS ZqCH385LQAISkIAEmk5AKdP0EbT9EpCABCQggYEmoJQZ6OG38xKQgAQkIIGmE1DKNH0Ebb8EJCAB CUhgoAkoZQZ6+O28BCQgAQlIoOkElDJNH0HbLwEJSEACEhhoAkqZgR5+Oy8BCUhAAhJoOgGlTNNH 0PZLQAISkIAEBpqAUmagh9/OS0ACEpCABJpOQCnT9BG0/RKQgAQkIIGBJqCUGejht/MSkIAEJCCB phNQyjR9BG2/BCQgAQlIYKAJKGUGevjtvAQkIAEJSKDpBJQyTR9B2y8BCUhAAhIYaAJKmYEefjsv AQlIQAISaDoBpUy/jOAjjzwy59CfpZde+p3vfOcnPvGJ66+/fpQtPvjgg7Mewt2Udsopp2SWXXbZ JbOssMIKGf+Pf/wj48ch8IpXvCKrvvvuu8ehxn6uYqgB6uc22zYJSEACY0VgrrEqyHJGT2DWrFlD FXL/85/LLrvsmGOO+eQnP3nggQfOPffcQyXuHP/cc89lRYQ7J467Q2WhnCyqm3LGMM1YVb3uuus+ 9thj0bBf/epXU6ZMGcNGjltRQw3QuDXAiiQgAQnMRgJKmdkIv5eqn3322UMPPfQ///nPN77xjV7y m+f/Erj55psffvjhiIPt/73plQQkIAEJNICAUqZPB2nHHXdcbbXVaBw/uB9//PFbbrnlxz/+8RNP PBHNPe644z72sY+95jWvmb2tZ11j+vTp0YYXvehFs7cx1i4BCUhAAoNJQCnTp+O+4YYbbr755mXj /vKXv6y99toPPfQQkdgPvvvd7x555JFlgvEPszoz/pVaowQkIAEJSKAkoJQpafR1+OUvf/mWW275 zW9+M1r55z//OQKsN4XLy6RJkz796U+XffjDH/5w0UUXRcxrX/vaDTbYoLyb4csvv/ySSy654YYb MLGsvvrqW2211Vve8pa82yFAY9LRZM8995w6dWqZ+N57773wwgt/9/wH7bXiiivSho9+9KMjst88 9dRT55577rXXXvvrX/96kUUWeeMb30jzXvayl5UVVcL04rzzzqPq++6774EHHphnnnkWXnjhNddc c6ONNnrTm94UiaFHsYTTqkT4a1/7Gh5Ic801F95IWWY3pWXizgEac9ZZZ/3x+c8zzzyzyvOf9773 vcstt1wlY47pkksu+ZGPfASX6tNOO+3qq6++/fbb6fvKK6+86667Lr744pVc5eXPfvaz9BDHRXqz zTYr7/LAHHbYYenntMcee7zwhS8sExiWgAQk0CQCM2r78GeXD380/XRD4N///nf53DDnteZirs00 zIORgI08EUmgkuXEE0/M9Ow8irtf/OIXM/ILX/jC5z73OTRQxhDg8lOf+hTPRZaGBSgTsLCV8S95 yUsyHr/kjCdw6qmnLrjggnk3A8gdtk2VKTuEmcLf8IY3ZN4ILLDAAldcccVKK62U8XfddVcW8tOf /rRtvZF4++23f/rpp0l8xhlnZPZKYN555x1paZm+Q+B73/teWw0333zzHX300Ui9Mm+O6RprrPG3 v/2tVessscQSv/zlLzNL6wChTbNf6KFK+ddcc03efdWrXpXlGJCABCRQB4HQA7XJjRluxs4/6Q0I /OlPf8pWLr/88hnuOcAS1UEHHcSDW5bAJT/Zu9ynXWbMMMahrbfe+tFHH82YDEybNu2zn/0s5WfM UAGW0pjIr7vuukoC7ECYlzD5VOK5vPTSSzfZZJOsF0GAAYNZP1My5X/pS1/Ky86BMSxtv/32+/CH P1xRq1E7/k977733Ntts07YxGJZYVUSrVe7+85//3GmnnSoDV6Z5+9vfzgb+iEERltqFyHPOOScT b7fddhk2IAEJSKCJBJQyjRk1dmKzypDNffWrX53hngPM+mw//upXv/qb3/yG6e1tb3tbFoXa6O28 FtZPDj/88Czn4x//+M9//nN8lrGIZCRaB0fmvGwboJDUK1hKDjnkEJaZMLrssMMOSPtyYSizH3XU UdyKy9122w0xhPjDXHTEEUdkmosvvpgwh/TEyhc2nrzFZmwiUzx1X1qW0DYA2/RqwuK17777svrz i1/84vOf//zkyZMjy+mnn37++ee3ZqfxqJb3v//9GHUY/Y033jjT4DtFOXlZCcwxxxwf+tCHMvLM M8/MMIFYXCOA2tt2223LW4YlIAEJNI9AfQafMCjVYaoaTZlPPvnkTTfdxF/2E044gfUapqtvfetb TAn8BGcu5xYJRlN+z3krP9nf9a53MRnzwSuCn+x4mZTPFvrjnnvuibpyMYJApfZhF5gok75nLhZf Si8ZXCjiVuv6RcS3XWBaf/31s6mYQLJwAviF5C2USnmrEkaFsPKSifHmKRNgxshbBGKBCfPG/PPP /4LnPwiUf/3rX5kFU1CmR0xkPAHcaPIWO8XyVm+lZfYygPtRVvH1r3+9vFVaR5ZddtmZM2fG3RxT MmI1ySx4t6y66qpZGk9v3Go7QLfeemumXGqppcgbiZFrGc9jloUbkIAEJFATgboXmAbI7RdrAT/r 77zzzvR2fP3rX7/QQgvxy5hdzfgxcFgLP3x/9KMfsXaDeynOKPkXf/wDpa9Da+0HHHDAMsss0xo/ 0ph11lmnVB7IgP3335/NU1EOxEZaIAxxZIlc+KxggShLwE0n/UXwxi1vVcI4+ebOc1ZYSnMRKTHq HHvssXjOlrmQd+mDXMYTLg0e8UWtuAdV0nM5VqUhj/CnjvJx1C3PSiYSb1yePbyzCaNNcYvBRTcS 57/I2QzTbAwzv//97yOm8wnLFIWnURiZsO5gc3rzm99MxlI/ubqUbA1IQALNJTAQUuaOO+7ghzs/ TNne/Ne//pXfvi9+8YtZ9UAnskzDT3bMM2gXPDDe9773sdoS+pE0TOqczd9Xo4s+wEsUx4sxaRUe FZVyUDZhtyCeJYzK3WEvyyxvfetbK3oFdXjSSScNWwgJGKZMVoqtiMT9hf1cnG6XacoAUpXVKwxs jDviACNE6WNUpuwmPMrSynU0hCPboyqV0ruQMsTTzlYpw86vMgs+vHk5lHTLBOx+yvUyLJEhZXJ1 CdvVpptumokNSEACEmgogeof1oZ2Y6hmMw+xNsEm3pwOc0EBNYAJAY8Q5AvOoazF3HbbbUzt/HRm 0ywF/v3vf//2t7/NX3828eJ5MFQVNcVjdCndOJi8aSTC6z3veQ+abKwqTc/QLBDDzKKLLvrggw8S g5cGiEa0TTe3iJO9tfCsZdhA6ejatr8MU6uUYXGQAcVgE6fvZC0pzjKmm8CYlFau8pQOyNmAUpqU iSMBLc8nNmIq6jDLaRtg4zq+Sqwbcvfss8/GZQeZnsa2LbbYAiekthmNlIAEJNAgAhNZyuAZypZg VAi/jFlIqmz54fWNnJmLqxALGRhmEApMjT/84Q8rg8fWD+Z1vFXG+Y8+bhCVI/IqDWu9ZOmkEslk XImpXOYiThmfkRyywjpLeWvYcPqxkrKtZ+6wJUQC5FSmZI0mwxko3V8ikv3GH/jABy644IK4RAQ8 f27LKq985SvRf2uttVbM6NzlVpYzVGCsSuPByyraDkfSJlmuvmWWUWpoasc/KXae40PNsh1buLNw V5cShQEJSKDRBCaslGEe5QC3sC4wQrxnpyJl+CvPihIHqTFrslqBuyuWAHxlcitvjiuLHRSFy8I4 q5lsQOcAaxbMu6TBBMWKQ2nLwazSOW+5HhQp2f2bk+tLX/rS0v+0c1Fxt3yXAlauShbY5h5vhqP0 AqmkLFdVWq0v9BSfp0oWfHRSx3AQy09+8hNETKYJRHk5bGCsSis3mrHa1VovZpKMRE9neKwC6JU8 RIfDivCYiZIZXJyQxqoWy5GABCQwGwmM97rJ+HSVqQ77SuoYKm3rVcC2IBxI0xsGUz+7SNq2kKIo kGLb3p29kYsttlg2oDLrpwduJqgE2APMcbpl5Mknn5yXrX4beWuoACfX5Su7MWixSFemPP7449m4 FJ/KrTIZ4dLnmgm4oi/ZdcUGpUqWdAohfvfddy91DLvKSx/hVvNVFMVqWpY5+tKiKJ6uVMBYRPDt zSoIYFtim3rGlLonI0cZYI9SLmyxozv7NVbuVqNsntklIAEJjJ7AxJQy2FpKv1HsFnlifQUZCyK5 JsK8UplpysQUSLFlTJ+ES1cStgilNOHV2ezY6txIjFVMafhBR7KrrrqK41syS3mKSUZ2DoA6bS0o P3w1ciWIjTzHHHNMZscDKcOtAewTuWsJKxH+TGkrQgPtvPPOrVmy49yq7GwvT0muZCxXcL7//e9T S9DorbRK4VxS/l577RXxAOHVE6mqqaLkwyImTl2tJYwyBrtanhyDC1HIOJbYylNnRlmF2SUgAQnM XgITcIGJfSuVs005mj1/GQ+Fm1/k7GnK+bJtMorld3NacdqmGf9InCHypzYnyGFb4jU9LJaVRqkO rWJjCx3HuxkZx66fXIjhpUW9/XBHTrHdN47XwzkDpcXOHZZRSo9gNiHHbpoODWPDOdaXSHDllVdS DouADBOvFip1Rpbwute9LsOciYf/Mpvt6RRHC/JKprxFAJ+VPLSGtcU08GCiYy86frU8Br2VVtaS YY7CAzKPJTEAwaEbxx0ENEIzrU349uYxeplxrAKsMWEJK0vjPaCtL0MoExiWgAQk0CACE9AqE8e5 lmNQrjWU8Rlm9QE7P4Ig7RN5qxJoLbySYPwveSlS+dYhZkcme3QMTjMcyNa5PRxzgsgjMRt0sZqk jmFm5eTAbtxjW8tHJTBzp7ML4oNXWpY6hsWjU045ZdjCmW5RJGk1wfmXcjgkFx2DR856661XqRrf 3jyMDg9fXi/FSwxYaULHwKfcB4QtKvOSJsMEMJyE3aK30sqiMgxhvFXyFZiYqdhVx4OUOoatXpxm VHo6Z94xCaC/UXVlUTr8ljQMS0ACTScw0aQMJ3O0OmGk98ZQo1XuUB0qTcRT+GgOKelceG93maRv vPFGfuiX2TE2YGsZ1q+TJSQsH5ygU+Z9xzvewSFspVmivNtNmHcncVbKPvvsU9mSQ1NZ6+Eg/y43 eFMCp9thVEvdg7KheXQt/T+yPYwyqoUNxpmYW4RZXkFI8aaCTIkeyjAvwcYTuTy2OG71VloWWwmg JED6X//1X6WiIg1yEzXJDrtcTatkHKvLcq0QrcmbEMaqZMuRgAQkMNsJTMp31ox5U8LvZJyXY3As LbeERKc48xRniw4dZGpkw0uHBOUt7A0YQsqYPgljbOBgEjaZszbEsSsjahVeFBw3wsOAYaMy3Y6o nNbE7AFmFmc9BY9gNNNIt0RFgWFqwryBpzbv1m6tpYzhZFt2ZsGBZ49Kcy2pTNMaxupDFqQP3S+z 9FZaa/kZwxG9qGEMYPgDDeVmnonHKsDpMpysGKXhJYP/71iVbDkSkIAEhiUQK+z1/cWbUFKGDdi8 57l1nxHeD7yNGeeJtrjx6kAAlTtc2ibLSAwDn/vc54Z1vsn0BiQwWwhw0iMikvdS4ZRz4IEH5vE8 2OHyxMjZ0jArlYAEBo1A3VJmQrn98lu8VcfwxOBdwd907A259IBfJw6YuHHgwcDd7nUMpVEFFa22 2mqD9iza32YRwMzGTuxKm1n7U8dUmHgpAQk0ncCEkjJtjyCLEeIWEoSVJi7ZqYs/bBy9yg/WVq+L YQeV0pQyw1IyQb8RwEWJLfr91irbIwEJSGCUBCaU229uCWmFwjsFORUm5AtOPOUR8mxvGdb9olJg h4oqKb2UwOwiwBk/fKJ2/K9xiMbfGT+q2dUe65WABCRQE4EJZZXJw8fawsKnlW017PThyHbO9uA4 MvatsAebTUls7uUHK6tOnIOXp4y0LSQiO1fUIaO3JDBuBNivzjOPasfVekQvoRy3FlqRBCQggTEh MKGkzLDGEoQLzo+c/LvnnnuCj1cUsbrEv/jNcMlP2C6dZpQyY/LwWUjdBHAOK3dj1V2d5UtAAhKY LQQm1ALTsARxl2H7BueIcEQ9Z41gdf/gBz+YvsBd6hhqGeolPsM2wAQSkIAEJCABCYwtgQlllcHr pZvT+hE0HOzBh32qe++9N2ehstcDrKw6cfwMkXj1shSF1iFlW9xdnvDWNq+REpCABCQgAQmMIYEJ JWU4O7UbKZP4WGz65je/+fa3vx1pwlug2ZgdFhrOYePDXc6ljZPyM0sElDIVIF5KQAISkIAEZheB CSVlsMqMlCMn5PL6G3LxnqZcaYpCMM9wnDwONK0HAdf3upyRtt/0EpCABCQggQEnMKGkDFuTsKP0 MKJooKFeFMwLnDlun6No2M7N/qbwkqGiHmoxiwQkIAEJSEACY05gQrn98g7FfJHyiEjx6sShXmuA VWb55ZfndYA77rhjbgZRyowIr4klIAEJSEAC9RGYUFKG9yIhO3qAVXk1dNsSWIqaNm0at3hJ4UiP 1GtboJESkIAEJCABCYyewISSMuDgzJgeoNxwww3D5uLt2ZFm3XXXHTZxDwl4VTJqiQ+BDtmffvpp 0vD2qA5pur81tqV1qJeXTg/btQ7ZvSWBzgTiSY4fG51TcpcDqHga8/CFyuWw2XtL4FegN27mkkA3 BCaalGFndTcmlgoaNmbjClOJLC85Ri/kzuKLL84yVnlrrMIcu3fY8x/8cjqUeeutt5Lq7LPP7pCm +1utpTEZ0AAmhu4L6SYlL72i2fly5m6yDE6ampgPDkB6yvtiecAuuOCCbnp9wgknkJg3h0fiymU3 JfSQprevAD9s+D4Oe/hnD+0xiwQmEoGJJmUYmw033LCHETr33HN5N1PbjJwuc9ZZZ/E3hS1Om222 WWWjU9sszY2Ew1e+8hW0XXO70LiWy7xxQzZuDeY9KnwfjzvuuHGr0Yok0EQCE2oHUwwAvixsO7rm mmtGNB5PPfUUZ8zstNNOK664YpmRLUvomFA5b3nLW3rzxSkLHGWY90ZttdVWnKAzynIi+9iWNiZN shAJjDOB97znPXz9F1pooXGu1+okIIGxIjABpQxoNtpoI87KY+/0iDBhfWEvdyll0DH8Yv7tb39L Ocz673rXu0ZUYB2J+YM7hn9zx7a0OvprmRKom8CrXvWququwfAlIoFYCE1PKsCV7m222wcoyosN/ Ac3rskvcl1xyyXXXXUfMUksttf3227Mxu7w7W8K4KyLRkCDpsnP99dfTkjXXXDPe7H3XXXehwDgm Z+WVV2aHOeE7nv9gqebQP/5qY7XKlpelsagUThvcvf3222fOnMmOsFVXXTUTE+At4pR///33L7zw wmg+3JJameDeyJsf7r333unTpy+55JKcmzyiowupAg8enANoALvfqYXTCydPnlw2gzCOzzSSWvC/ oXysZZzX3Lr212WyYfsFxttuuw3yNGzuueemxtVWW61yUmI3aSq9GJY577UGJsChuthiiy299NIc BNDKvCwWevhd8Z7U1qOScPli+DDpgTSzYHGk+1TB08JzDsnKt4AHDJW/+uqrV+qNijgjm3eZUdrd d9/9j3/8g6eLdvIg8dBR1yabbJIVlYEbb7yRt3bzdLFu+5e//OW+++7DPYs3h9BmnpkyJQ2jefio VQyijOzNN988ZcoUXmtfpidM1WShMTRs2WWX5RFiyCppykv85LDKrLLKKnnaQtylHB6wIMMDz5EN XR7z3f1XgF7fdNNNeO3QHR5yaqEZdJYG8KTx7pRwLyNZvPJ2pZVWIk02nm5282XJ9AYkMFEJzP65 uSayTMO77bbbD3/4w+5tMwigNdZYI9rD3+5LL730yiuv5JK/hugYCqypqSMqlokHQxFTUUoZXvfN FM4U8p3vfIe/oVEaf/jwgEbPkTi0TsT/8pe/ZJkMq1VclqVdddVVsY7GLQxRfJiqU8ogLPCpDGEX eS+//HL+qu68887lahdTFC7JuTcEZ0ySvf/9748snf8lV7zms0xGR5i/Wfhj0sp4/nxzRjNSKWPY X8YUyNk/5WTTTbJu+kVFJ554YsKJSukXh0G/853vjMtu0mRrM9CZOSLm9NNPZ5LL9ASgwbCW81l5 l/BDDz104YUXImX22Wefyi3epcrLxd797neHlEFMnH/++ZVTJfkWbLDBBuuss07qQh4whoYptiJl rr76alq43XbbhZRBWDAKjDXFfutb34pnYCgpc/HFFzNJk5HnM/3cw7OeF4nwydpRkCRmZ2JFyqDC yYv2qkgZxuWyyy4rO85jTCMrurNMQHqg8TVPKYOyOfPMMyseY/xBgAxfnzJva7j7rwBK5dRTT624 2NP+zTffnD9E6Bs6GOWjaCO89dZbx9B3/2VpbaExEph4BCaslGGoEB877LADf9a79Jth7o9ZGUHA HzJ+9FPI2muvzZ/+Oeecs5/Hnp+2TB78sd544435TczvY6Yf/hAfeeSR/EBHuPDDFJsBU8WvfvUr 1Ax/KOOXX9mp9ddfnx/TSAd+IvMTnAW1eeaZJxP84Ac/4C8vMwfzN3mZSJjJkInf/va3kYxx0A5/ xOMtEG94wxuwCQGT6Z+XWJ1xxhlZTocAUokqMAmstdZa1I524UcnkbSHVtG8yHvLLbeccsophDm3 kPkVAwmzHV3jV/hJJ5205557xjGJXSbrpl+0gY4glZjJwMs8B9srrrgCZcD8yg9lGtNNmta+d2AO W/QTo4a16Y1vfCOzPh2kRmgcc8wx++23XynaypIxHjD3Y4AhfWnhQGGg7YBDgkgPrjvvvJNRfsc7 3oEUJgHQGC/e1IGFj8e+LLbLMAKFKZ9aaDasOudCuSKPkDsYY5jRGUe0HXM5LcF/pXPetndpP3l5 KugjUz4GFbrDv9/4xjf23XdfrJJtc1UiYX788cfDmQf4rW99K6ZHOoVQQ/Pxx4TnjfIrWfKy+68A Ao5nDyWNPRXLFiOFXuE7hfrny0v7+Zahafj+AoTvQuxmwHAVdXX5ZcmGGZDAxCYwkaUMI8efVP5Q olH448682Hksw86BNeK8887jDyLTNn8++CvTOVc/3MWGhI756Ec/GpKLMFKDuZb1NcRc2m/4QY/N nEmOP9OtUiY8BsLaz8SGUMiuMUOEjtljjz2yCuYq/hbzUvFrr72WuRA5xRxGFsL8qo682AaAz8TA dJKlDRWI95NjAMsFDgLoBv6y59jR05/+9KeUUFpEmAZo/BFHHEEtLGrQ+C6TddMv6mKK5V8UYZ7y zLPBJMQ0Ca6QMt2kae34UMxpP7MmcyqikLe1R0aUAenRjugqlj6HsnVhWmCuZdGElYtSytBZ2kwJ oYEwz6BjWNRA/CVwJAXGCYaVOZWqO9h+WvsSMYgtBn2XXXbpJi9fT3Rw2ksYOKZq9A2Cm58QpbVv qOoq8Xxt0cFsM4x4HnIkNXuteX6wsL73ve+tpG97CRm+IFCibQgX0vDFwY6FIQSktG0oKTOirwBf KIaDZUr0Sjbjgx/8IIYudCRfUipF5RBAyrBARjiTEejmy1KmNyyBiU1gAm7Gbh0w/kTuvvvu2267 LcYJ/nq2JogY/qDz5579SkxUJN5rr70aoWOi8QiI0nREF4hnMkgdE8libuP3X1x2+S9zNinxei6r ICZ+OvNrlamXSR1rFj/xK0cIYhujbcNWxCRERnRnTquRJWpE0MQlf+gxvFPLeuutV5bJdMhExTIE 0wPxXSbrpl+UFn7WiAPmqqwUgwpPCPaSiOkmTeYdNkD7mcPoJnagMjHKIxYHsUKV62tlGsKoEP6l wYihvMUl4VxCxTjHJcwrwJmnEWf0FIWaebsPkHHLLbfsRsdQJu1MHRNVIHwxdCEayqXM7mvHxlPx zccBKBhSYDwbw5aGjCMNz1LomExPOUTyzeJpz8gyMKKvANixe1WWqxivWMXLB74sP8NdflkyvQEJ THgCE9wqU44ff6P5MAHwF4epAq86jLd8+MPELzA+LK/wp2T//fcnXGZsRLhiZeEvOM2O+bVsf6v/ bHl3qDDTKrew8YQTYpmMimCItRy3YuKxW7RWgZzC9aGcVssSIkw5qYGYDimQSvkxXTr6kDL8uJGk 0cGyHH6O52WXybrpF1MOBipagmLjseFXPsqY9S/W1PjdnDV2kyYTDxuI09tY2ig9hCIXhhN+o7Mc A/ChToOkhTQb/w/sLoTJyGOP3Yg2p7QNRG3FOmlY3oo2DNvUSgKECFaZSuRQl2GUqtwlkmb3Vjtw WonF08L0j6mym7YFmdIzOlqIsuls1xnRVwDyCR8zDJXyNLK6xLepAqT1sssvS2tGYyQwUQkMkJSJ IcRIgFGXzwQb0XSTLPvVNrJM0E0YhRcGgIsuumio9KRhnuBu20UBLCu4KQz7N5rf4hgbsOGzbYQw pdF+5h58PrLeDrVkGgLdJOuyX2gCRBKrNniQILD4yR6/2tExLIKwPysgd5OmbGHnMCqEBFTdNhnx rICQZigpQy4MHowXMEPK4OqBQMQDI6xc9D1+97etIiKjDW0b0CGyS3tMlFAxe5SRMYIdKmp7q22B pETTo40oc1gpg8EyyLR9kttWmpEdnrq2XwG0C88SqpGfVVEI7UeKdWM07ebLkg0zIIEJT2DgpMyE H9Ex7yDLHMzW2FRY2mi1uER1/N2PHV5D2fD5Tdy5YfxpxssVVx4sB0zDeGwwoeIdgu8L3qmZN9YH mZUzpm2gm2Rd9ivKD5MeP52ZeGgSFg7EBD7OuK3kL/Vu0rRtbWtkbB6u7G3JZDHX0v6MaQ1gJcKp CLcPmseaBT/3SZOrS7k5mSpy204W0k35JG67ztKla23U1baDETnUk5aNbFv7UI9Zl2VSeC5AD/uM ZUsyMKKvAL4yJ598Ml8rbDNoYh511tqQXMcee+ywUqbLL0s2zIAEJjwBpcyEH+LRdpCJkO0z/OLk b25lGassOn7Kt10XSPtHmb4SZtJFx/CrFC/U2A8VCSozVtTS9ic7fk6IDJYYWKHoMlk3/SrbyXzD h7OkmRoRCniA8sHHuVQD3aQpy2wbDg+SWOmoJGAaiy330cfK3bykSfidoGCYMln0YWmMRTHaFgkQ CqDGGMCaCBAyVwRioSTLH8q2l7aEMvtQics0Gaai1icqrEFp3RmqwLa1tyXGYMXCaJaZDWgNIBBB x4oPz1hloRmdhAcuWfD9aqu0gliXXwGc2dExbCyoeH1VHvjWFhLT5ZelbV4jJTAhCQzpAzshe2un eiOAPiBj/LIvS8BCfuCBBx566KH8hCUNs06ck1amIdyNCyeLSqRELZU6hpjcuxRlhnsK++TzBJ2I Z4I/55xzONckzEJdJuumXywqHXTQQWyPioriX6waTELhocmc102aMvuw4YCJyafSfTLijctsxyw7 7MQczr+sMbHbhSxssC/rjb63nlPAhB3+SQigSB9CrVzmI56hrwxBWXiXYfbYV1LSThpMJMIrboXv S+sOODaWV/JySat4AivxFBjEWl3HKinjMh4e1jord3GW4gFDMbfVMSSOUevmK4DdhWeGLLkxPurC HtZWjVVa0uWXpZLLSwlMYAJKmQk8uL10Labniombnc8s9rPfpzw0DPnCrnXcaNjwwl0MCTiOUOVp p51WTnJYBeKkwc6tiRmL+bI07DNtMHmQEaUS2fEOQe7wc5az48KDJ+6SjKPksPBzl5guk3XTL4wW SDR+alcckGkqrQIXW1q6SRPtb/tvK3NghvLgfKOwkURGFrbCMNC6m6y1ZLxkkDtM+bSc2TdPO4yU HO7HqOECz/ZpeEYkBgwOAYIkPcrdv6GZ0KMIgkhGAg5CzFytVXcZw2pdeZwd5bN/EJ8q1itzLSxM HdjbkClZLDoDy0RelgFW/UovH+Rg7t7PxaMyfWs4jhLgUIbY8xUJEKyx362Dm133XwGkMPApOURJ VMGXju9OaPFcqI1ng3Epvxddfllau2aMBCYqAReY+m5kWSwfyqjOabZ1NzdmDlxcmS0If+hDH6JG JjN2ohLJmR94sfCzFYs9axb8go9b0SrmV/40M+tzNB+/6ZkOuWQuIQuR/Dnu0HhOqWFOJTHnv7EN ipL5IU52HFAwKqAbMLrg9sEEgMsOJ4Uwt331q19lcwoxzNbh3rHFFluEvwIVdZOsy35hgEFSMHmj CegLswuTZRwkw2JTTDbdpBmq+22ZB0w6fvTRRwMEmIRZg6MQmJSn/gxVLE8RhhlGDbcehFH6x0R6 +g4iTlrjNCDmbMYL5oxpKEJIRr9IjCcHZjCkAxuLWLxj8YVmoDbYzIU38VC1dxOP4kSZUTv2DHQM 5SOCUV0cDJO10zDEIg/DUUcdBQeaTXd4ThAcoerKivDqRXOQkgJZTYMYNhJEAGo7tVGZvm0Yg1C8 jxZhgdWK2qmOSknM6HNoXttcEdnlV4CHlgceehxHDkYcjGg23afXtJxnm0OhAAJt1gFJjMo55JBD MMXxmCHWu/+ydGiqtyQwkQjMecABB9TUn1if7tKoW1MbGlQsNoaw9vNbn99kbT9MSMzZmEb4/Ze/ DuOvHjuZy/3J/GXErg78yrICsz5/lNltG5tf+KVbKY2DZ5AdzGf4IvCzm4M0giF/35lUyMv0gMLA VMBdzOMcIpKenvgZMMUy7sz0lMwEgJcMf3Y5Nh6fEnrEpJhSozI0FEKnyEJeVlWoiJl40003ZW5g fsUaTwxHufDDmhUoamHOwxTPDEdFEGMO43gx6spiu0zWTb+YzGgbDaM6WsjsSPdhi88Edp2osZs0 2bZKoC1zlAdjBzTqinrpMoIGTcl5JEOJ3UrJiCT2yDBSHNjT+k1kYmZeBCAk6RcBsjPrc0phebYe fWcSRb7wiDIKjAUPD2MKBxrGc0gCMmJiIQZTEPqy0ozWS061QdpyfiPdRCdRO88VnY2SedLKLAwr d6mXD88ezwAHGvG+ArpGw2ITPg3j2Ubr8MwQRg1QJsR4DDi7hWPoEARZJk8j4gCdF49u5ZJkfEFQ QpQDE2rk60B2nl7KKb9lWWAGuv8KQJ4vKd81quCBp6k0HiDAZCWXbx9jTQydRTWShq8S3yy2iPOo d/9lyYYZkMDsJcATTgN4mGtqxiR+itVUNH9KKDn2gtZUhcWOPwHmG/7+8vOR38dDOQ3QKiZ+UjIf lFPIsK3llyjTFb/7mYPTl5aZmJks9qmWJRDPZMCcROIwuZd3M9xlsm76xVzC8gcFMoO2KoOosZs0 2bYuA0yl/CEAZuddS62lAfOwww5jpD75yU+23s0YtCBqhtEkJXNnxpcBhoY2oGaYStNkUiYYUfjg gw8GFK1i7KidJ4rsuAB3KBkRj6pjFu/mryHDRGtRAyFWRtS2MnE4r/B0MdwjepIppJuvAE8vzzDy CAWT5FEtfBjujCmblOERfVkylwEJzBYCYVHm51NNtStlagJrsRKY/QRwE8FRiVWJyjaZ2d6yUsrM 9sbYAAlIoG4CdUuZ9r/A6u6V5UtAAvURCBdRTB0sWfKLPx1466vRkiUgAQnMRgK6/c5G+FYtgVoI cGYJW5Pi5BVMMh1W32qp3kIlIAEJjC8Bpcz48rY2CdRPAFcenFrwFGHbTr7Zqv5qR1ADjr24iXTw tRpBWSaVgAQGnoC+MgP/CAhAAhKQgAQkUCcBfWXqpGvZEpCABCQgAQk0nIBuvw0fQJsvAQlIQAIS GGwCSpnBHn97LwEJSEACEmg4AaVMwwfQ5ktAAhKQgAQGm4BSZrDH395LQAISkIAEGk5AKdPwAbT5 EpCABCQggcEmoJQZ7PG39xKQgAQkIIGGE1DKNHwAbb4EJCABCUhgsAkoZQZ7/O29BCQgAQlIoOEE lDINH0CbLwEJSEACEhhsAkqZwR5/ey8BCUhAAhJoOAGlTMMH0OZLQAISkIAEBpuAUmawx9/eS0AC EpCABBpOQCnT8AG0+RKQgAQkIIHBJqCUGezxt/cSkIAEJCCBhhNQyjR8AG2+BCQgAQlIYLAJKGUG e/ztvQQkIAEJSKDhBJQyDR9Amy8BCUhAAhIYbAJKmcEef3svAQlIQAISaDgBpUzDB9DmS0ACEpCA BAabgFJmsMff3ktAAhKQgAQaTkAp0/ABtPkSkIAEJCCBwSaglBns8bf3EpCABCQggYYTUMo0fABt vgQkIAEJSGCwCdQoZSZNmgTbWbNmDTZhey8BCUhAAhIYXAIhA0IS1EShRikzefJkGj19+vSamm6x EpCABCQgAQn0OYGQASEJampqjVJmypQpNPrhhx9+9tlna2q9xUpAAhKQgAQk0LcEEADIAJoXkqCm dtYoZaZOnYoKe+aZZ+67774nnnjClaaahtBiJSABCUhAAv1GgEmfqR8BgAxADCAJ6mvhpBkzZtRX Oh146KGHZs6cWV8VliwBCUhAAhKQQN8SQMcsssgic801V30trFfK0O7nnntu2rRpTz75JIKGcH09 sWQJSEACEpCABPqEAH6+iBjWlbDH1OrzS39rlzJ9wtRmSEACEpCABCQwIQnU6CszIXnZKQlIQAIS kIAE+oqAUqavhsPGSEACEpCABCQwMgJKmZHxMrUEJCABCUhAAn1FQCnTV8NhYyQgAQlIQAISGBkB pczIeJlaAhKQgAQkIIG+IqCU6avhsDESkIAEJCABCYyMgFJmZLxMLQEJSEACEpBAXxFQyvTVcNgY CUhAAhKQgARGRkApMzJeppaABCQgAQlIoK8IKGX6ajhsjAQkIAEJSEACIyOglBkZL1NLQAISkIAE JNBXBJQyfTUcNkYCEpCABCQggZERUMqMjJepJSABCUhAAhLoKwJKmb4aDhsjAQlIQAISkMDICChl RsbL1BKQgAQkIAEJ9BUBpUxfDYeNkYAEJCABCUhgZASUMiPjZWoJSEACEpCABPqKgFKmr4bDxkhA AhKQgAQkMDICSpmR8TK1BCQgAQlIQAJ9RUAp01fDYWMkIAEJSEACEhgZAaXMyHiZWgISkIAEJCCB viKglOmr4bAxEpCABCQgAQmMjIBSZmS8TC0BCUhAAhKQQF8RUMr01XDYGAlIQAISkIAERkZAKTMy XqaWgAQkIAEJSKCvCChl+mo4bIwEJCABCUhAAiMjoJQZGS9TS0ACEpCABCTQVwSUMn01HDZGAhKQ gAQkIIGREVDKjIyXqSUgAQlIQAIS6CsCc9Xdmueee27atGlPPvnkzJkzCdddneVLQAISkIAEJDDb CUyaNGny5MlTpkyZOnUq4VrbM2nGjBn1VfD0008/8sgjiJj6qrBkCUhAAhKQgAT6lgCCZqGFFpp7 7rnra2GNUgYbzL333kvT55xzzgUXXHCeeeaZYw7Xs+obSkuWgAQkIAEJ9AuBWbNmPfXUU48++uiz zz5Lm5ZZZpn6bDM1agvWlYLooosuiokp+hBrTP4rAQlIQAISkMAEJoDxYt55511sscVCCaQkqENq 1Shl8I+hxQsvvDDGJUYLKeO/EpCABCQgAQkMDgGWZZABiIGQBHXoGMqscYGJ1SVGa6mllnJdqabB s1gJSEACEpBAnxNgpen+++/HnMEaU01NrdEqg46h0eqYmkbOYiUgAQlIQAL9TyBkQEiCmlpbo5Sp qcUWKwEJSEACEpCABJKAUiZRGJCABCQgAQlIoHkExuOIvOZRscUSkIAEJCABCTSEgFaZhgyUzZSA BCQgAQlIoB2B2qVMePr4rwQkIAEJSEACg0mgnfwYy7japcxYNtayJCABCUhAAhKQwP8lULuU8WQ8 CUhAAhKQgAQGmcD/FR5jf1XjEXn33HMP7eWIvLFvtSVKQAISkIAEJNAQAhyRR0uXXXbZmtpbu1Wm pnZbrAQkIAEJSEACEoCAUsbHQAISkIAEJCCBBhMYDykzmA7b9loCEpCABCQggSBQq1DSV6ZWvBYu AQlIQAISGHQCdfvKeNrvoD9h9l8CEpCABCTQaALjscDUaEA2XgISkIAEJCCBfiaglOnn0bFtEpCA BCQgAQkMQ2A8pIxOTxKQgAQkIAEJDDKBYcTI6G7XLmUYuUE+4tC+S0ACEpCABAacwOiEyvC5a9/B tMQSSwzfClNIQAISkIAEJDBBCfzzn/+kZ572O0GH125JQAISkIAEJDA6ArUvMI2ueeaWgAQkIAEJ SEACnQjULmUG2cvJvktAAhKQgAQk0EmGjMW92qXMWDTSMiQgAQlIQAISkEB7ArW7/S6++OLtazZW AuNL4NZbb/3ud7+bdW6xxRZrrLFGXtYR+Nvf/nbqqadGyVT3yle+so5ahirzlltuOeyww+Luhz/8 4fXXX3+olBM7/q677vrmN78ZfcxB7xM4fdKMif0A2Lt+IPDAAw/QjPrcfmt/cUE/QLQNEoDARRdd dN111yWKyZMnj5WUOe200x588EFKXnLJJbfccsus4qGHHvrZz34Wl+utt944S5mnnnrqzjvvjNr/ 85//ZKsGLfD444/nuDMK0f1xhnPHHXdccMEFUfWmm276kpe8ZLY0Iyr1XwlMPAK1LzC5RiiBfiAw Y8aMq666qvwC//rXv2aCH5O2oVfOef5z5ZVXUkWWOccc///7RTjjyzT1hTnHIvs7/rXX16+RllyO QpztkVgiEAlqHZ1//OMf8YTwL6o363KMRjqapm8ogfiu1fevVpn62FpyHxHgd3nFMvHMM8/8/Oc/ f8973jP6VuaEVM6aoy92lCVgItpxxx2jkFe84hWjLG1iZM8BWmqppcYTTtZbwegYVYB4KYHeCIyH lMmfIDTRsARmC4HLL788viGsK6E8MNJwedlllyFlRt+elDKVJzxqLP+lrqeffpqFJ+awYY0BLILg 5/GCF7zgxS9+8VxzzdVNO9Fn/OhfeOGFycVsvfPOO0ftM5//dFNC2zSPPPIIjaHNbe9Wet2ahsr/ 9a9/TZkyZYEFFmi92zZm+vTp5Jp//vnb3m2tcdj0wSFLa4XTp0Tr/AAAQABJREFUWiYx//73v2fN mvWiF72IIc68bVM+9thjTzzxRJBvTRm1x7/xtESa1ma05qVr5WPQtvbWXDSGJi266KJdPjmtJRgj gbElUH4Lxjw8HlJmzBttgRIYEQH+rP/qV7+KLG94wxuYS375y19y+fvf/56Jf7HFFquUtueeezIN ELnCCisceOCBeZdIbsXl29/+dnxpTzjhhL/+9a/33ntvRDLlfOpTnyL85S9/mSkkM0YAL+DDDz+c 9M8+++zcc8/9qle9at99911mmWUqybj7ve99D+11//33x5+SOeecEzWDF86GG25YJqauOEMTF5Bt t92Wxvz4xz9GpX3nO9956UtfevPNNx9yyCGRfvvttyfNo48+utdee5UltIaPOOKIRRZZJOKRXMce e+zvfvc7pAwxCAusO4i/ddddtzVjawxzME264YYb7rvvPjpFAgTWmmuuSQlvfOMbMz3Lc6ecckpc fvvb377pppvIFV4+bBpYa621EGTIoJ7TZ8Yy0AqnvMsY0Qb+jY4jf1/2spdttdVWa6+9dsW+Qmvx Jb/77rvjgaGQpZde+m1ve9tmm2220EILcckjgdNx3iWGkn/0ox/hhb3BBht0aEb3j8Ef//jHo446 Ktp/wAEHIL+okYeNGJ4cHrOddtpp1VVXjQT+K4EJSaD617aOTvLnOH7T+K8EZgsBFpLCDMPjzTTD AxlShsAVV1zBFFVp1T333MOsT+J55523fHqZXf7+97/Hd4QJgwC7om688caI4d9p06Zdf/31BMiV kRFAEPzkJz9BVMUlthlmwV122QXR85rXvCZrodiDDjoIjVVmp16m9q985Stk2WeffbJVaJ1QUeQ6 9NBD6Uvkitqpiyk2YmIqxWaT7S/LL8PYQrikBMQfZZarcvjP0js+u+66K9CyzRV6EQ/DT3/604iY snBG4ernP3T8Ax/4QKSkimwVsga1l1nY9YA4QwxBCVfZ3tKTKwuMMP8++eSTJZwoOf4988wzUVSw ylwwQXN87nOfQ4Ttt99+2d8TTzzx+9//fiaLAF1GieI1hSjEKBLQyjR//vOfuVxppZX4t3WMog2I yC9+8YsdHoNPfOITqOFoCX25/fbbo4rf/va3xx13XAwiMTw5CJ29994brYOayZaX/TUsgXEgEM9n ff/+f7fEmuoYB0Z+PyXQmUCuLvEj9c1vfvOb3vSm/G3NrbZ54+vArcrd/JpQFM82Fh3WCNIAw893 LvlErkxMgAmSeQvrQnk8AdKH3+jld+Tggw8uJzBsNmkjoZBLL70UG0CZPqrAEyh1DDHRtuxj25jI 2PovuSgfbfSlL30pdQzWFBZZMvG3vvUtNm1VyJStIox/a+oYUmLVYHUpS2C6ffjhh6MEWpvxRx55 ZIYzQDnomyx/pOmpJYvKNpeRdDnj//CHP2CISh1DXSiGzM4muIsvvjhaAqIf/vCHeYulJWx4yRwl h8ohJbqT56GkR5iYWGvL9JQToxYtwZzW+TE46aSTss3ZBgLYY9AxPJBhE8pbX/va1zJ9kjRGAuNG IB/FmgK1SxnazTfHfyUwuwjwAxdjBrXzYfc1YmK++eZ77WtfGzHY4WMto3xK41b8O1R83GX56bzz zltxxRXjkvUXLvmU022Wxi9pfqyzKZdf8zlB8qMZC1DUgiJJGw9lnnvuuQgCbDlM/KkDiGRRKdJn yXiiEGYRCrMBa0mZOBNEYMEFF7zw/37OOusscmUyFiNi0j3++ONZHop4LChM4XwwM+QEecYZZ8R8 X/LJMP4luV+MtSTq/MEPfoBn0jbbbJN1YZyo9IJbWBE233xzRADVfeYzn0mNCCVMa72lL3NlC7MZ BOKvOQHuotLyFgtbl1xyCR3Zf//9MxI1GSlpD92MeJQWfTz99NNp9jzzzBORWOwIoOF4Hj772c9G JP/GM8OCYMaUAdqA3QvjSkR2eAzYFUUa0pd6CIB77LEHupaWM4gIqSgHaRUWwZKAYQmMJ4HyOR/z 8HhImTFvtAVKoHsCrFnE15UsOCgwAfPnPs8XIZIE3ZdWSclkloXHLS4rMRHPjM6SCrMml6usskrp u5COFLhQZPkYRfC6iKJe97rXpY8Ov7nRN5ksAzhekP3zn/88qz+lIScTEGDOw4yUHwwJRx99dC7u cHoVRhEMMFSB7IiM+NzssMMOaCDy4imyySabRDxOJKz7lIWXYTyQUI00iQ9KiHWW6Egpm2ImLnMR xmCGA9DLX/5ysuBukm7L3Lr22msriXtI31pCGXPbbbeF/oiS2eKEexByipNgXv3qV0dKDrWLxUoo RQc/8pGPrLPOOvDhYUAlQzVSZgf/54H4v4tcXKYMKhsQ4dE8BjxmuHDFEuRqq60Gzyw/PboyxoAE JgyB8fCVmTCw7EgTCeTqEpMNU05MKjiuYnKP7pCASau3ruHyUmakcBwXypgM477KFMj8Rww2G2Zr fnzH3VzO4CC1iOEwPVYrsIvEhEd6HH7xF4nLMCNlyVEgCoAOUhRt4FPezTDxZfMQLuEzRAKMMccc cwzmHCplDs6JFqMCliTEH3lpRs7TZLnmmmvwoc7Cy8ASSyyBq0foNixGv/jFL1gk+stf/lKqxrhb 5iKMVKIuKEV1zMQs90SaVAZllpGmL/O2hsvJnvGiGdES1AyswqoBmTC5bb311sg+CoE5RiPcexGF HFaUy2pRPulhTjlZHeFyFDI+Az0/BpSASs7HjOdhueWWy2JDgeWlAQlMJAJKmYk0mvalSoAJJrZy cIMf1kyTuGESxqkFe0PcYr0Gp86VV165mnlMrxEBOZ/RjJgFo4ZQHjimhK8xkfhSsPk59QTpmfix tWDt4G7aUbKBbJNmXaPzBFnWRZg3KuBRG5H8iGeqptJYVConY5a3+GRFZSBbW0ZGmEmUzrKoRBVt JQjJ2koZDFGpDpEIWHFQV2G1wse5taKRpm8toYwpq6DknPtpyQtf+MJYtqPZeDhF+7HQsFaIuYgE ZTmjCY/mMaBeTGv5mPH88JxnY9oCz7sGJNBoArVLmfgz3WhGNr65BHKhhC7g0YkrSdu+kAw3kba3 ygc4tQUpiS9vZd4ysgwzkZSXZThKyymcS8wAyJcskwDzU05LTLGV7FOnTiV7JbLMzq3yLtYR3I0j ATYG9kbh5ZNGoG4kEXmZv8syy+poLVaZtIdxix5h4EFN4mSTKSN7WQhyobwEQjoVUUJv6bO6CJTl Z0xEhsyNyFijybzASSkQiXHL/eQnPxmmmkiGWmVZjY1RuUrVWlfWmCVngMR8engMyJWFICLLyzJM mspl5jIggaYTqF3KNB2Q7W8uAf5wl/t6OnQE106cJWPhgGQ5aVV+bQ9lYOhQct6qzCKVS5JhdMHT IqbGOC0m8xIgfZhkCOcbfCoJyssOYbaFo10ywX//93+zmIJ8SaFWvvINf1VW5TJxGWDWLC/LMC6x qWOY3XFxff3rX48hijWmUsqUWSKMQYilt4zHWTV7jeUp4zMw0vSZsW2AdbGMx0JTHpGMqMohi+eE neoxWPQL/yS8rzDkkJ2zgrKQHgLj9hj00DazSKBvCQz5x6hvW2zDJNAlAZaNWjVB27wsYZROrKwm RLJyxYGYdGJoW8joI9MrlpUL9iqXBf7mN7/JhYO2UqZM3CHMihunqKVE22233bBUpT0mMmYzuGQx i11L+cFqgnUkPmklaq3uT3/6U0SSEp8kfFGZ75FKrV4+lbzlDmRuoboyAetfGc7ASNNnxraB8rjC ylhznM87nv/gtIRVDPtNLvOxLYsPOgatA1jkV9vCu49M/vU9Bt03xpQSaAQBpUwjhslG9kKgXF36 2Mc+xskulQ/7lrPctCIQk6eAYKvAuTXSoIpOPvnkTN82UK5QtE3QIZKJcOONN44EqBaccNNXg/3k 7MfOvEMtk2WCoQLII46tyzWRLbbYgt03rGhUFrPYr55qCWIszJGFDz4ihx12GGcMxie2Jbeti6Pt Mh6GSCXy8jn//PMzPo0cGUOAU3NydYbWnn322Xm3rYvxSNNnaW0DeFvnehbbxNILmGN/ceyNLCxE IstKiQxARopugojt9HnyXtsOUkjnh2QcHoO2fTdSAo0mMB4LTHw5w1HAfyUwbgRQAyxzxJeTStlP 27pFeaONNmIujDRIFjxtmclIvPrqq+dRNJwCgpMHzzDzWWXKJ2M82ywMRSH8ImfdAaMOu4gxSHA3 4iNlpi/jI0GUg5ThbJL4uc/eou22244NKcyU2B5y/mMhg8jSdaMsIcqJfyO+/Jdz7XK9hniOqOHI kzIBYfw/sD5wpgubqLmECasnbB1n1Ynzf1OjsNwTG33LGjOMEoo3RWCl4NC/d7/73Rg5WMWDYVaH kaa1nXR29913xyzBjnFsEuiDSM/ZuOgnGsPoZAkEuklPLWUWwm1jKBmb0/vf//44+I66kL9sg0eB IeayBCIJl2twHBREazFc8QhxlHEWHgt20cd8QsjLqTkII54xjFVZbAZIz7asymPAedC0p/IY4HhE 97O6sgT6EvWWdyOc8WUawxKom0A+nzUFtMrUBNZiZzMBtjrn9M8BGxwQwo/m+Omc/3LwLnueo6FM FWmA4USTNPIjX7ATcJ4bAQwD5ZyUPeQE4QgzT2CrwJaQfieZpssAB8Pkhmd0A7YiNE12hAPTOGcv V5q6LDOTVaQYOoOiKp9QGBwhiJCKjCRg9Q3dkzoGURiKLUuuBNBkmC4ikvYjjOKVRvjNZMo41i8v I4BLDQHEHDWmjsFKhANKpfG9pa9UV7mkCsxUOfQ8EgiyUscgs6KFNCnfh8WeI14LwMAx9NDLE2jC FhVVsD8uVy1ZZQNmrsFV2sAlT1HlMcC+OIaPQWuNxkig6QRqlzL+CJDAbCFQHmGCmSF2/TBX0Zj8 l7m8PCsP3RA/TdA9HGfCnJSOwJhYOHsmTn/P73z2i1mNw/cynkD+xMnIjIlcGU8gy0E0UCnbpFt/ r5P9fe97HytcyAiaHaWVhVTKp8zybtSS3ancKi9JQ15mcaZtFrlypSnTQIwW4hIboqe1XmJQAxzx l5qMvEzkaKOvf/3r6fLC8bgs01TaiVBDBlFCVodJjJdNIkaBE3XlLQLdpC9LI0vQLgshnCWzcQmr SesSHnvE8JWmC/EgkQXzFa8ULcuBCe8TwK6Tkfl6AZ4fDv4p7YLBOVNGINpGFd08BiX/LCdKKP/N W9FH/5XAbCGQz2FNgUl8bWoqOtzfyj9nNVVksRJoJcDkwbQU8WiX/IlfSYmVJXfi8DMalUACYvjZ zReeGZ0TYPFvZW4mJeWkGmBm5W6UhgWClSkuOQMX2w+XLDdwq2xDFh5ZSJ92C7IwLUU85dNsqua3 Pu8I5EMyjDFYjzg5hmR0hIkqEjO/kpJw2w6WtbMSwTedEjr46kaZ9IKuEY4WUiNfZJaH6Nryyy/P YTyIEhpAM7LNkbH8l14AkC6zkoIth+UhFAlUS4C0h1aRK16JENkRSVSBtzXYSY/zCsf+cqukN9L0 0ZgoP3vXCicSwJOB5l9OzaHXfLjEP4YHgMjAGCkDJm7UrJpRGnYszkTmFlhoeaRhcSoHC27cwsE8 3lOBXIbwUM0Y0WNQFlKCog3xZEZjGDL4R9h/JTDOBGIfQ7kyO7YNGA9fmbFtsaVJoBsC5ZwdAqVt Lm6lpCBLpGTKQV4wGTNd4aYQGWPqzWWCsjRyMfeQODcMI0TKBN2HQ5QwyVERpgg+mbcUTxlZX4Bp m36hqzDMlLYZIhEEOUO3bQC9YE4FyJprrpkJAmDKL7DTo4oeolIisdyk8YYEFFVJlmWONH1mHCpA vxh6+KNLcJThkylTBkUMVSNuOE6XT8TQa9LEkxAxlENMhANI7AUjJpVc3K382z+PQaVhXkqgPwko ZfpzXGzVaAkwc3RTBBMSn9aUMaURz8xEOD5cttUoMd1yN3+OR4HM+m3Tc3eoerkVpTFNUlrUTgxz W5RZ/suP/vKyEm6tnWk1Z9ZK4raXVEoV0QzawyUtAUXbxJVIakcTkJdPZIwEndtMLbSQaZ5cpCdj 5+q6SU8hraPQCifbT420gQECPs2gy/HJBBEgGc8YCUhGDAVGU0kcZq1KehIETNrMLZJFrta2RUYS UD6JowoKJ4a+VIrtXAgk+bRmMUYCE4xA7VImvt4TjJrdGRwCzEDdd7btTNN99jJlTF0jqr3MPoZh OtVbv6ILI2oJWfh0X+NI03ffGEoOtdE5S/dNjXJGSjKa0Q+PQWcO3pXA7CVQu9vv7O2etUtAAhKQ gAQkMLEJ1G6Vmdj47J0EJDBKAuzW2XvvvaOQcJfuXOBI03cuzbsSkMAEIFD7DiYOTsVGyoqv/0pA AhJoJYC3de41w5uEZZ3WNGXMSNOXeQ1LQAKzhQBbIBFMDd7BNFuoqZwkIIGmEEC74GYbreXPxbB/ MUaavikcbKcEJjCBug0/tVtlurEY191Jy5eABCQgAQlIYHYRqNsqo9vv7BpZ65WABCQgAQlIYAwI KGXGAKJFSEACEpCABCQwuwjULmVY+aZv/isBCUhAAhKQwGASqFvi1C5l6u6A5UtAAhKQgAQkMMgE anf7jVesDTJi+y4BCUhAAhIYZAK8RZXu17cZW6vMID9d9l0CEpCABCTQeAK1S5nBXBe01xKQgAQk IAEJBIG6tVLtUqbuDli+BCQgAQlIQAKDTKB2X5kFFlhgkPnadwlIQAISkMCAE3jssccg0GBfGU5i pgP+KwEJSEACEpDAYBKoW8nV/mZs1sliqcx/JSABCUhAAhIYTAK1qpnafWUYM0So/0pAAhKQgAQk MJgEatUxFF67lKm7A5YvAQlIQAISkMAgE6jd7Xf++ecfZL72XQISkIAEJDDgBB5//HEINNjtd8DH z+5LQAISkIAEJFArgRoXmMJPm3XBWjtg4RKQgAQkIAEJ9C2BkAEhCWpqZI07mCZPnjxjxoyZM2cS qKn1FisBCUhAAhKQQD8TQAbQvFqVQI1WmSlTptD6p59+etasWf1M2bZJQAISkIAEJFAHAQQAMoCS QxLUUQVl1ihlpk6digqbY445HnzwwenTpytoahpCi5WABCQgAQn0GwEmfaZ+BAAyADGAJKivhTXu YKLRzzzzzF133fXUU0/V1wFLloAEJCABCUigbwnMM888yy233Fxz1ejQUq+UgSy67JFHHnn00Udd aerb58yGSUACEpCABMaWAMaYueeee8EFF1xooYUIj23hldJqlzKV+ryUgAQkIAEJSEACY0igXqE0 hg21KAlIQAISkIAEJNBKQCnTysQYCUhAAhKQgAQaQ0Ap05ihsqESkIAEJCABCbQSUMq0MjFGAhKQ gAQkIIHGEFDKNGaobKgEJCABCUhAAq0ElDKtTIyRgAQkIAEJSKAxBJQyjRkqGyoBCUhAAhKQQCsB pUwrE2MkIAEJSEACEmgMAaVMY4bKhkpAAhKQgAQk0EpAKdPKxBgJSEACEpCABBpDQCnTmKGyoRKQ gAQkIAEJtBJQyrQyMUYCEpCABCQggcYQUMo0ZqhsqAQkIAEJSEACrQSUMq1MjJGABCQgAQlIoDEE lDKNGSobKgEJSEACEpBAKwGlTCsTYyQgAQlIQAISaAwBpUxjhsqGSkACEpCABCTQSkAp08rEGAlI QAISkIAEGkNAKdOYobKhEpCABCQgAQm0ElDKtDIxRgISkIAEJCCBxhBQyjRmqGyoBCQgAQlIQAKt BJQyrUyMkYAEJCABCUigMQSUMo0ZKhsqAQlIQAISkEArAaVMKxNjJCABCUhAAhJoDAGlTGOGyoZK QAISkIAEJNBKQCnTysQYCUhAAhKQgAQaQ0Ap05ihsqESkIAEJCABCbQSUMq0MjFGAhKQgAQkIIHG EFDKNGaobKgEJCABCUhAAq0E5mqNGtuY5557btq0aU8++eTMmTMJj23hliYBCUhAAhKQQB8SmDRp 0uTJk6dMmTJ16lTCtbZw0owZM+qr4JlnnnnooYcQMfVVYckSkIAEJCABCfQtAQTNIossMtdcNZpO apQy2GAeeOABdAwdWHjhheedd9455nA9q28fNhsmAQlIQAISGDMCs2bNmj59+sMPP4xRAzWz+OKL 12ebqVFbsK4UOmbppZeeb7751DFj9oBYkAQkIAEJSKC/CTDpM/UjADBnIAaQBPW1t0Ypg38M7cYe M+ecc9bXAUuWgAQkIAEJSKA/CSAAkAG0LSRBTY2sUcqEiwzrSjU13WIlIAEJSEACEuhzAiEDQhLU 1NQapUzsV3JdqaaRs1gJSEACEpBA/xMIGVDrFuYapUz/87WFEpCABCQgAQk0nYBSpukjaPslIAEJ SEACA01AKTPQw2/nJSABCUhAAk0noJRp+gjafglIQAISkMBAE1DKDPTw23kJSEACEpBA0wkoZZo+ grZfAhKQgAQkMNAElDIDPfx2XgISkIAEJNB0AkqZpo+g7ZeABCQgAQkMNAGlzEAPv52XgAQkIAEJ NJ2AUqbpI2j7JSABCUhAAgNNQCkz0MNv5yUgAQlIQAJNJ6CUafoI2n4JSEACEpDAQBNQygz08Nt5 CUhAAhKQQNMJKGWaPoK2XwISkIAEJDDQBJQyAz38dl4CEpCABCTQdAJKmaaPoO2XgAQkIAEJDDQB pcxAD7+dl4AEJCABCTSdgFKm6SNo+yUgAQlIQAIDTUApM9DDb+clIAEJSEACTSeglGn6CNp+CUhA AhKQwEATUMoM9PDbeQlIQAISkEDTCShlmj6Ctl8CEpCABCQw0ATmGpDe/+1vf7v33nsfeeSRueaa a6GFFlphhRWWWmqpLvtOxvvuu++f//znC17wgsUWW2zxxRdfZpllusxba7LRdKrWhlm4BCQgAQlI YNwINFvKXHrppYcffnjAeve73/3xj3+8Am7WrFlnnXXWeeed969//atya/nll//whz+89tprV+Lz 8tlnn/3FL37xox/96Pbbb8/ICJD3fe973/rrr4+4qdwa6vLxxx+nGbfddttf//rXGTNmLLLIIq99 7Ws33njjZZdddqgsQ8WPplNlmbvvvjuNiZg55pjjhz/84cILL1wmqCm8wQYb0AUKp9Kf/vSnvdXy la985Wc/+1n3eVdbbbXDDjus+/SmlIAEJCCBphBotpR57vlPsCZYgf7www8z4d10002V+Li88847 v/CFL2y00Ua77LLL3HPPXUmDjvn85z9/3XXXVeIz79e+9rWLLrroq1/96jzzzNM2TRn5m9/8Bsn1 73//OyOnTZt21113XXjhhV/84hdf//rXZ/ywgdF0qiyc7qOrMob+ogy23HLLjBll4BOf+MQTTzwR hRx99NElpRy11iEbUaUjyh7iaUTld5/4yiuvPP300yP929/+9i222KL7vKaUgAQkIIFREpiwvjI3 33zzxz72saF0TFJDTGCceOihhzImAkcccURFx7AyVUnz5z//+eCDD0YEVOIrlzfccMP+++9f6phM MHPmzM997nM33nhjxnQOjLJTZeGXXHJJeUkYE1clZjSXCLU7/vdTq4wYTSPHKu9jjz32v329A605 VsVajgQkIAEJdEOgOj13k6d/0mDP+PKXvxztWXTRRbNhzzzzDFYT1nQyZsUVV3zd6173yle+8qmn nkIQYCZ58MEH4+7dd999wgknfOYzn8nEOMeU8zqWmw9+8IN4ybAwhCXjlFNO+d3vfheJf/3rXyNE 1lhjjcxbCZDl61//ekayMvWe97wHI9DPf/5zJA7xJEDNnHrqqfPPP38maxsYZafKMimqdXUGDn/5 y19e/vKXlyn7NsyA/uc//ymbh+dQyogXvvCFr3rVq8q7kC8vDUtAAhKQwIQh0Gwpg8cJn9bB+PGP f3zPPfdkPG40e++9N54ZEfOOd7yD9Z0DDjjgT3/6U8RcccUV733ve3Py++Mf/5h5V1ppJfLGJZ4x r371q7/0pS+xJoXcichbb721g5TBF+T++++PlMy+Rx555Lzzzsvlu971LsRWmEaefvrpq666apNN NolkQ/07yk6VxV5//fWPPvpoGRNhBFxTpMz7n/+UXTjkkEMYx4hBuDBM5V3DEpCABCQwUQk0W8rg 8IFdJMYGobDmmmsSxtr//e9/Pwds3XXX3WefffIyAlOnTj300EN33XXXVDzHHnvsN77xjUmTJpEA 40SmZ79ShiOATeVNb3rTueeeG5elx0klJZfl3W222SZ0DPFUtNNOO1122WWx+EKgs5QZfafKtpWr S0gCPKPjLj4fqLTJkyeXiRF8qe1WWWUVxFx5F4H15JNPRsymm26Ke/U111zDJdamTEb5lDnnnHO2 9cWZPn06Eur3v/8928SWXnrp5ZZbDm9odpll9jEMsBpI8xgU/J2Rs694xSvQr3gEt/V3hjlAWKNk cZDECy64IMkYelzF090bfymMf7fccks2kofntNNO43LVVVdNcZx3DUhAAhKQwJgTaLaUYU466aST Agqml5AyLNykwym3ttpqq7bUUCRMvbn6Q1H/+Mc/Yoc2E2pmoTQWg9ZZZ51QORH/0ec/maZDALGV d1/2spdlmABTI9WFdQe3Gxa8WMMqE5Th0XcqS2NHeroBoTC23XZblttYXSIBSzbXXnstnc3EBBAZ J598csR85CMfqUgZdnjl7jC2JtHfHJEsJJQl03+rlGGkcCRKKYDHyS9/+UscmFh0q1SUpfUcQLbi Bl7qVAb9/PPPn2+++XDxZkNZWTLNYO2SlbiMjJHiYWDgKIf9/Nw655xz/v73v2caAig/PgSQqkqZ koxhCUhAAjURmIBuv+XU8tKXvpQVoqHYsdJUOvPGdE7icgbCt4alCgwq3/rWt1AAaYEYqsxKPL/m MwYn3wxHoPSHTd+dSpq4HH2nslhWYdJV+Y1vfCMT+Vvf+ta8WzoJZWRNAbq/7777po7JWhBbrL6N aINS5h0q8Ic//AGDU6ljMiVyCk8pDGMZgxZh0FPHIDE5SSi1LGtz++23X+fxyqIMSEACEpBA3QSa bZVpS6ec9V/84he3TRORLPfgLIwxJi7JyNROeOWVV+bMmHS8IAbDA7+/+eBwgzcJv+DXW2+9bjxJ OTYmfWWYIMuz9dg2xbF7UTX/tt3ilHdH36ksqlxdetvb3kY8a3Bpd8FCg5LoeX1n9dVXP+644ygT jZK2MTZjYwNLX6VsCQHO7HnLW94CdjQlwHO5EBMIKzt4apeJew6z2oWXUqx50QyMQ7STS3yfsb4Q QNsdc8wxa621Fv7C1MIiVKrMPffcM9b+6A4Ci/QkwHzFmUOszR144IFkx9Wp3IxNPGnaLlr13AUz SkACEpDAUAQmoJRJ4wp97rBkE0RIUEqZxMRMzI9ypquMiQAzHH6+fNhzxMzHRu4llliikqa8ZFEp V3PIwhLYi170IhIwdzLl53xJDAKizFgJj0mnKBMfkVzzwmEoHJYRWNiu4rg8mnT55Zf3fDIKNh6c lqioFC64v0yZMqXSo7jEMPapT30qwqhDDCesMcUl27nHSsqceeaZ6aaNEzdrkVEF3UdrhozD/MZi E+Y3brHHLRLwbzpL0bWdd94ZB5q4FeMVJxymLxG3FlhggSCQJRiQgAQkIIFaCUxAKVOu4+Bq2hlf maDMiGNHbHE644wz8FMpb2WBmBCQBZxA00EwcSgwh/zGtmE002677YbTKNYgjB+VQ4Rz0SfLLwNl A8o2l2kyXCYoM5KgNMngE5MevsiIPPmXpZaepUy2octA6ezMCg7qMKVMZzNVl+VHMhyAIoDRBYee Mi974znmOCjhwhxSpjSosDGKQcRuhEBB1mCYKbMbloAEJCCB2U5gAkqZl7zkJblw88ADD3RGXHo8 kLGSGM9TPmyxYbGD82P45I6nSEn5eIziRlPJmJdYPrDccChwKBUOPmG+jLuxVoWBJy7Lc3EyewbG pFMshZSrZiyiZflIGQ7XiUv0GbKmg49R5hp9oPImrFJD5PrUKGvBzpQ2LQiwYFQpEOUXUgZDCxvj WQvDVnT11VdHMpqB2zIfBCg7njjKCDFaOoZXSvNSAhKQgATGmcDElDK5ppPLCm2xMrGVWmcoxxrm MLbg8qEQNgzjGMuCRVo7OJkN+0EsG7WtBX8UZj62w+RKFsmYL//7v/+bzUEpZTqYdkiPlBl9pzAj lcfKYY1gzSvbjIUmO4XxZnykTOVgwNzknK0afYAhZvEoykGpsGupQ5moGVYMGetPf/rTaLs8c48s oWgRtSeeeCJvJ+CFX3W0tkPbvCUBCUhAAm0JTEwpk11lkzM2hqH8c3EKycmbLGGV4Rd8unBiOMFp pnT7QJRsv/32rIPstddeWQuH/5YWjozPAL/mv/vd7yJ6EC7sgUIl4DvMLM7aU6YZVspkyh46FXnL 1SVimJWzzEogDpgpt3dFgtK5J2JSJVRK6OayBNtN+t7SYBjLjKhSTnzOy9ZA7lpCgLIAxzogpjh2 P6WDEVnYWsUaHCnZRt5agjESkIAEJDDOBCaglMFXlJcX5hSLLilfSpB8McmcffbZeYmOiVUDFAYS J+PxGsFrNS8jwHRIYiw0cdlhKYQJj08kCwWTRaFpsMrEJXumOm8aGmWnqIUNUzj9ZO2dAxz7hgkn Xhteet6Ue8spga6VZp7OZc6uu/jHsG4V9hUsTxwJ02VLSPy8Me5/rHEAwSrGFjb0aGTngBmOXkQb dVmaySQgAQlIoCYCE1DK8CoDXpmEFSSQ4R3C3pM99tijtAEgPjiErdzhjENuzNlICgwk6UPDKgw/ vvNMkSiTk0XK1aIOh/1ffPHF7PKNXJwvF16lcXnBBRekyuF824gc6t9Rdopi0WdpU8Evhw3YrXXl WXncYh0tpAwnwmVKdhVlmEC+i6qMbA0j2obawdSauI4YxGhIGRRJq5UOE1SMJvYb3JCRa5wEHc3g hKGtt96aMAIXBxpsb4xgFAVMtui3LkqyDlVHFyxTAhKQgASGIjABpQxd5WAPXn6UagPRwMoOhg1m Jqw1bLXlJUSllwxzdrnvl0NHfvKTnwQyjgxhcsI2w7ZqfoKHw8Txxx+fsoAf/XHwa1vELEWllMHD hl/5sdrF4k4e5cI0ydkqbbOXkaPsVHn2HbuROeS3LDzCTPmHH354hOM9TXFaf6YM9+dghdr7zne+ k7cqgVI4oqJ4xRVGjtYVq0qumi4333zz3/72t1E4B8x84QtfCBsYvtgsFeWmpFAtCBo0bjw8HKm3 4YYbpsGM9LkiiT7OU4LKzoIIDy1uoVNnV39rwmixEpCABPqTwMSUMvhj4uPC8WW5IMK6QC4NVEaC pSJexlRGxrGwuVmalQU+JKBYlqXKlFhrWL3qMGNh/8DlIs6nwRT0sY99jNcYcTZJGoQwBdHUbhxI R9MpTtQt914N5dnz5je/+aijjgpbEdM2J8ghAtjDxeweJHETwR+WeZpmU2BsyyqBZJgDV/IIFvxk eZsB7eeNBJlgPAOcH5OjgKjdbrvtWCLEUMQCXy6QIU3YdB2tYus1a0mEMb/hFIWphu7g3B1vXIo0 vGIpFUxqGm6hgfCm4tYOO+ww1EszogT/lYAEJCCBMSEwAV9cEFyYabCd8G9nTNgn2EpdcbnF+sK5 9ZV9wpRT0TEoGKRJh9diR9Uccl9623CcWqljWOeKvVGd2xl3e+5U6fCLD3Jr16J8JAsWqWxJnOUP DWwqGYmaQcSw0oSO4Y0H8d6rvJuBODc5L8nFJy/HP8AKYxreMK3hzMt261LHcH4Mp9tFw3bccUc2 XUeYjf08SBwyhDkndz+xrlS+o5QVxrTcRK402o1/T61RAhKQwKARmLBShoHEInLYYYehNlgbYnWj HFp+gr/mNa/hSJihPDfxTcGQgAWi7e4nbBKsO5xyyilxRH1ZcmsYKcDJ/fhY4Ixc3uXItS9+8Yvd 65jI20On2IGMj2pWPZRJJhJwwEymxC4Vpim8fDBclQzZTL7ZZpvBJxyMMksGeDkAxomKRsy74x9A auDwyw7qSpNoP5uVGKByZxMGpIMOOoj3QYYneNlaVgMx3nBQUOlCxONEDKJ2KBplCYYlIAEJSGBs CUyqWBrGsPRY0ejgRzKGdQ1bFCYEbCGsMTEH847JJZdcsuLJ26GEeFkSv87RBJz3Sl7+7bCoNFRR oGbTE69kYqakkHJVYqgsneNH06nOJbe9S3U0nmFlQxAMu5y2WVZjcQraOBWh6tqWPM6RtAfnXxaP kDWIFWxRHRrAkPEAcN4Myeg4o1ZKukpG1uaw9OCPhWzFxpMrUJVkXkpAAhIYKAJxjHu86aWOjg+K lKmDnWVKQAISkIAEJDAsgbqlzEReYBoWrgkkIAEJSEACEmg6AaVM00fQ9ktAAhKQgAQGmoBSZqCH 385LQAISkIAEmk5AKdP0EbT9EpCABCQggYEmoJQZ6OG38xKQgAQkIIGmE1DKNH0Ebb8EJCABCUhg oAkoZQZ6+O28BCQgAQlIoOkElDJNH0HbLwEJSEACEhhoAkqZgR5+Oy8BCUhAAhJoOgGlTNNH0PZL QAISkIAEBpqAUmagh9/OS0ACEpCABJpOQCnT9BG0/RKQgAQkIIGBJqCUGejht/MSkIAEJCCBphNQ yjR9BG2/BCQgAQlIYKAJKGUGevjtvAQkIAEJSKDpBJQyTR9B2y8BCUhAAhIYaAJKmYEefjsvAQlI QAISaDoBpUzTR9D2S0ACEpCABAaagFJmoIffzktAAhKQgASaTkAp0/QRtP0SkIAEJCCBgSaglBno 4bfzEpCABCQggaYTUMo0fQRtvwQkIAEJSGCgCShlBnr47bwEJCABCUig6QSUMk0fQdsvAQlIQAIS GGgCSpmBHn47LwEJSEACEmg6AaVM00fQ9ktAAhKQgAQGmoBSZqCH385LQAISkIAEmk5AKdP0EbT9 EpCABCQggYEmMFfdvb/jjjvqrsLyJSABCUhAAhIYWAJaZQZ26O24BCQgAQlIYCIQqN0qs8IKK0wE TvZBAhKQgAQkIIGeCNS9PqNVpqdhMZMEJCABCUhAAv1BQCnTH+NgKyQgAQlIQAIS6ImAUqYnbGaS gAQkIAEJSKA/CChl+mMcbIUEJCABCUhAAj0RUMr0hM1MEpCABCQgAQn0BwGlTH+Mg62QgAQkIAEJ SKAnAkqZnrCZSQISkIAEJCCB/iCglOmPcbAVEpCABCQgAQn0REAp0xM2M0lAAhKQgAQk0B8ElDL9 MQ62QgISkIAEJCCBnggoZXrCZiYJSEACEpCABPqDgFKmP8bBVkhAAhKQgAQk0BMBpUxP2MwkAQlI QAISkEB/EFDK9Mc42AoJSEACEpCABHoioJTpCZuZJCABCUhAAhLoDwJKmf4YB1shAQlIQAISkEBP BJQyPWEzkwQkIAEJSEAC/UFAKdMf42ArJCABCUhAAhLoiYBSpidsZpKABCQgAQlIoD8IKGX6Yxxs hQQkIAEJSEACPRFQyvSEzUwSkIAEJCABCfQHAaVMf4yDrZCABCQgAQlIoCcCSpmesJlJAhKQgAQk IIH+IKCU6Y9xsBUSkIAEJCABCfREQCnTEzYzSUACEpCABCTQHwSUMv0xDrZCAhKQgAQkIIGeCChl esJmJglIQAISkIAE+oOAUqY/xsFWSEACEpCABCTQEwGlTE/YzCQBCUhAAhKQQH8QUMr0xzjYCglI QAISkIAEeiKglOkJm5kkIAEJSEACEugPAkqZ/hgHWyEBCUhAAhKQQE8ElDI9YTOTBCQgAQlIQAL9 QUAp0x/jYCskIAEJSEACEuiJgFKmJ2xmkoAEJCABCUigPwgoZfpjHGyFBCQgAQlIQAI9EVDK9ITN TBKQgAQkIAEJ9AcBpUx/jIOtkIAEJCABCUigJwJKmZ6wmUkCEpCABCQggf4goJTpj3GwFRKQgAQk IAEJ9ERAKdMTNjNJQAISkIAEJNAfBJQy/TEOtkICEpCABCQggZ4IKGV6wmYmCUhAAhKQgAT6g4BS pj/GwVZIQAISkIAEJNATAaVMT9jMJAEJSEACEpBAfxBQyvTHONgKCUhAAhKQgAR6IqCU6QmbmSQg AQlIQAIS6A8CSpn+GAdbIQEJSEACEpBATwSUMj1hM5MEJCABCUhAAv1BQCnTH+NgKyQgAQlIQAIS 6ImAUqYnbGaSgAQkIAEJSKA/CChl+mMcbIUEJCABCUhAAj0RUMr0hM1MEpCABCQgAQn0BwGlTH+M g62QgAT+H3vnAWZXUbfx7emb3rPpPYGQ0HtvojSVIkU/kCaCArZPBUXUT7AgVRBBadKr9CahBkJC eu+9bHrf+v02k0wm55Y955bdc+9975NnM3fOnCm/OffMe/7znzkiIAIiIAIJEZCUSQibThIBERAB ERABEQgHAUmZcPSDaiECIiACIiACIpAQAUmZhLDpJBEQAREQAREQgXAQkJQJRz+oFiIgAiIgAiIg AgkRkJRJCJtOEgEREAEREAERCAcBSZlw9INqIQIiIAIiIAIikBABSZmEsOkkERABERABERCBcBAo Ckc1EqnF0qVLa2tr6z2zSZMmHTt2rDdZ1AQrVqyoqqrq3LlzcXFx1ATZGllTUzNhwoSFCxeuXLmy TZs2Xbt23W+//Vq3bu1p77p167Zs2eKJdL+2aNGibdu2NsZntja9n8D27dtnz55NTfr379+tWzc/ p8RJ4/a4ucBodatWrWKdsmbNmm3btjXb+Vm7dm3Tpk07dOgQK3H64umm6dOnw6G0tLSsrGzYsGGR nZW+0lOb89atW12Snq+pLcuT25IlSxYtWlRSUsLVXlSUqfdG9xr2NDBbv65evXrq1Klz5szhDjB0 6NBevXrl5+fX29iNOz8k46yCghQ/1W/atGnDhg0tW7bk/llvTZQgeQKZ+nOl5eeddx6jSL0IRo0a 9fe//73eZFETXH311Qznjz322ODBg6MmyIhI1NiqVasKCwvRZH4q/Oqrrz744IPc093EzZs3P+ec c7773e8yWtv4O+6445VXXrFfIwNf/epXf/3rX5t4/9lG5hMr5osvvvj5z3/OyEcCt6xY6euNd3v8 l7/85eTJk0888cT/+7//i3Xid77zneXLl1955ZUIiF/84hdHHnnk7bffHitxOuLfeuutv/zlL+Xl 5W7mKKtvfvObF198cbpvo5BHSlIKl4dbgWTCH374oUvS8zWZnOOci8imu4Fp0rz88svJy+I4xaX1 kHsNp7WgMGT+n//8595770XKuJVBQJxxxhnXXHNNfD3KrWPMmDGcyG+WX66bQ6Bw1Bvs888/f9dd d3HP/MlPfhIoNyVOjEAGSxnU944dO2yzMQ/Mnz+fr8S7Ertv3742TW4GFixYgOzj1swNul4Czz33 nBm5eTA99NBDGaUwPKAYxo8f/69//WvZsmW///3vPZlgAGAg90Sar927dzeBBLKNmqEn8uabb2Y0 3XfffQ866CAexTxHk/x6yimnIGU++ugjRmtXwNlseRBEx/CVlIRtfMMEKisrETHPPPMMxfXu3Xv4 8OEIbp4FJ02a9Omnnz7yyCMff/zxP/7xjzgmpeTr+Yc//OG9995DraIjk8+tEXN47bXX0DEYEelK LFspVGaN2KjsLrqiouK222578cUXaWaPHj1GjBjB9b948WKu/1mzZj3++ONTpkzh+oxlksd29dln nxlEZJKMlAl0g83uTmnE1mWwlLn//vtdcF9++eVll11GDDaYqAOPm9hn+Ac/+MHmzZuZXvGZPtOT 8fO+9dZbacXPfvazb3zjG7Y5l19++dtvv81DDLf7I4444itf+Yo9ROCQQw753e9+58Z4woll68kk 8uv69etREjx4MaKnyvzg9jj2mD//+c9Y/lAGxx57bGQF3nnnHSL32Wcf7qQYvX7zm9906tQpMlma YugpbsE0HxvG1772NbeUadOmXXvttXPnzv3xj3983333uYcUjkrAKNEzzzzzuuuui5oggyLdaziD qh20qlz2//3vf7n+Mad5lDSTrUCYOHHi//zP/zz77LNRhwOe6/BPwGry0ksv8biCXbNRpoaDtlrp YxFI8QRhrGIyNP6oo45i2M5ct4Og2JGDWNq7dOni6hiTCeP66aefTphxPSTZmunF1M5Guz3erl07 jD009t13343aZCNlTj31VI6id7lUDjjggKgpUx6JAdLY2LCNe3QMZWGYNPNcmNN4Qk156dmXobmW kKRZ0DT3Gs6C5kRtAp586BgcYpjj9ugY0g8ZMgQTMvYYHqKefPLJyBy4y5mfD1IGe0x1dXX8ifLI HBQTNgIZbJXxg5Jr9IUXXsBczDBDeObMmUyUIE3MzBRjMy5+nnyYfOUoT+Ht27d/8803sdifcMIJ 5qHfGDN5dMNd7PPPP+fnxKwWE1gM8wz/nnwojodjngwYS5j7YFDk8R0dgDPpMcccU+8TgCmCCmN4 6NOnD7ZTcnC9jznE9Ae+rswEuUXzePH+++9TYarNL9k8cJAA90keUAhgRIl1y+Y5ngSuo66bM0ww yXqmpd0EscKJZYt9+IMPPsChle6gOagEDELmAYtJJeY18KqjRI6adjEdZuez4pzLKVGvCpjQL54e Z7qB2XSqgTXbc6mY2SWMMSeddBJ54jFKSmbxDjvsMJcD1w8TPTwmYt4bOXLk/vvvb418VIMrikdD c7HZs6j8jBkz6IXjjz/eRhJgEoROPO6449BYd999N7djupJWu2lsmIuNKSeywpw2cOBAG0+AmnPl cP3gUjNo0CCcyTzzg36ucwYSZh65mMkQwcQcHPMyoIjD1tSh3tLdqsYJxwHLWfVWw+bMD4SfCXME xCDlGR3Nb8cmqLfCBibXJ9N8XJncYbgz/OhHP7I5RAbiX5+k99MFkdmaGM81bG4UTMJyGdAW2sjV hfmQy4NrKVYmUePrrTb+cIhCfjXMfnLZUxB3SJzQuUdxp3Lz9J/SPcuGcUMhTP0PPvhgG+kG+CV+ +9vf/tOf/oSmOeusszyPo9zH6HQUD13GowjPJNhmSO9xFqYX8IOJHCbw3+K+xC8dTwY/N1iK4xTu zNQqAexuuxSORSDLpQy/KKZLcXflemV+xDxe47vK4Mf0BEOC58fMwy7uF9yUjQWCuSrcfrn4jJT5 4x//yLV++OGHM5PF0GWZ4iSLtd/9UfED/ulPf8rYZtP87W9/u+GGG8aNG4fO6NevX3wpM3bs2Btv vNHjy8kPDy8Wq0LI3LiVeaQMFaPJDFFImXnz5hE2daC9Joyzi83EVs8EOIsA4y73Yk+2xKMkEnt2 CZotvcbMCPcIt3p0GXrunnvu4a6Ey45tF7dOE+a2hZSp91zyjHpVXHHFFUgZT48Twwo4BAQa9Oij j3brY0wyxp2IeAYJqsETnitlGNXoR+565kRulwSY+sEhlwAyCJ3N7R41g5euScPfBx54gGEA0UaJ 1m+RJVo33XQTkTyDoqtQV6Q0+dgTPQEuS+SOe3dGcHANm2rYxBSBo+iFF15oU/q5zh9++GEGNpMJ VwUfRgWkTBy2Pku3FYsTiA+WE+NUw5Pt008//cknn5hI5k/5DBgwgN8OMT4rjKrDM4mO5jrh3kLv cG4sKePn+uR0P11g6hz513MNmxsFEy40EwXspudyZQrV9Sx0j7phn9Umfx51uL3wW7B3SB4OyYpJ am6b9hrzn9KthgmTM4+IhBEfkUdtDM+c/JR44Bk9erS5n9tD5idw2mmnEcP9nFsKTjbcnD1WVXqB JyUuBs9jzBNPPMGjLOh4trQ3oqg3WH7a//u//8vjhC2agH/s7lkKxyeQ5VLGNp7bOjoGDYEgOPDA A7lJsS7p9ddf90gZHmg4hacKz7Vr80Gks1yFx1muYOwxDGDcChn7uegJmJsCaRgXGaJ69ux5ySWX UCKWFX48XPqIJJtVrAAS/vvf/z6/AaQDIxzDM4ts+U1SCuMNI3p8GeRmS3uZSGb5Enc31BjZcpTZ BzeNG4YMmSOhuO8wbYG1gN921Jlm96x6w0GzBRQ6BlPW17/+dZ4mudHw4EskSFkXwPw3TGgX9w5u iJjcrr/+eupgBFO957q1da8KjBPuIRNm9or7DqqFi8cjZYws5lKJPMvEUGcuFS6JSy+9lEy466FQ 6Yg777wTEXPBBReQjMuPRqGTrJTBnGBu01yiaAUrKLkqSI9OojuwcnF58BWRbcqK+pdS+LiHWNPB QzmNomKYiFCBSCJ+CFjpkUpoLJu43uucXuAUrkbqzzhBN5GtPZ1AJFv/pbv5RIb9gLVnRVbDHjKB 888/n15gugF3UXqTC94+wQeqML8a3JIAzs8WM6qnFPvV//VZbxfYPP0EsILwnEavMXIjXrnR4YmP qQDpFucatjn7rzansGaH+ydijqsXeYeEQupx5XO9oahsnoFSumcZExo//Di3MtLzS8E2yZ2Ex1H3 dO4bPE/SUyeffDLx0ECsQAMbjEfKuGdFDdd7g0XEYD5MGHvUQhUZlUBOSBks4fyQGPC4bZnHAgZs 7uBc5Vxn7hIPfthgYiFfVFhEcn9hTOKR1Ggd1AxDAvKfXxerl3kwJQ0jH/d3htuHHnrImHO44rmD YBbyyPPIUniMxsuBgerss88mvUlAtoyFDD+MbdwuGcUjT4wagzmKurHdAs3nl084ajIbSW3JH1C0 Be3Fhx88D6kM8wyi/I2q8BhlGa1tJjbApB5ahK9BszUGj7/+9a924oMAEzQsWGC8IUMmX2gLAhEp Q5XcdtV7rq1e5FVhD7kBbvTkyZDPgyldbw4xdYhliHslZhs3sQ3Tjxjq+IsNzDzicwixxb2S9dtA xuhNjzCIspSUCRquK2OAQbbSUpZjIGiIt1LGWPgQl+Rjbs1QJQdbYr0BWoGOoc6PPvqoBUv+6CHG nn//+99cctZcV+91boQdoxSXOheGx18hkm2g0uO0xSdYk0NkNSJzNjN0mCG5tMBur6WgFWaxGD9z Hjksw8iyiCFb/sa5tu1Z9XaBTeknwE0A33wzeJOeTmdE51kOi4UfKeO/2mSOfEdB2hWFXB7MMWFn feqpp7gDu67x/lO6bTRShhusGxk1zIQO8R4pgwURtihOO5OOzR4pw5y1ZziImqcbWe8NFsjJYHfL Ujg+gZxw++XCZcz41re+Zc2b/MzwWmBwMs/WhhE3ZYZwxhs+cahhQ3ZHdO5cTHyQ3s4jGEczLChG x5isKBpTTZxszSHsltx0eMA1FhSbnhHIrK1AXvB7s/EpDyCbeNRmsoa7Hj91jARgYZyjPjx80zTG Ek+h/FwZdyM/SA2b0n+2PLphN+aRzg63JhMjIxjmbZ6RgUDnRl4VkRkSg4ajOyjX2EVMGnNnR1jQ L1HPYgYEbjw1Wh1jknGpMHJQT2P/AwsfnlyNRCMNVm7+YswzVhybOVIGrYOiJQYzG3+t8cCmiR9g eSoJLrroIg9YfhrMjULDrOu2mdR7nduUkYFItkFLj8zTxPgEaxJHViNWtpHxQSvMzYS56fg6JtD1 SZWS6QJPizAUWR1jDhkfL3MteRJ7vgatNg8wVseYrPil8MjH1BtWVTdz/ynds8zMO76MbmTUMC4E xHvc+7iFEsmDlj0FCYsHG9XDHc1GpiSQDPaUVCB3MskJqwzdGbkkh8dihg2eS+xzmDGZeGZVIy8F rBSeSDNtxIyAiUeLEGBWxZOMQctM33ji3a94t/CVZ6bIqSh+b+x7gReOcd9xz0ptmEcljA18MA5R FvZ8ZkCwYHEHQeLwSMRSbbdEnm+iLmH1jLU+s2XyjuHW5M9QxLw4TKgDbiVuoVHDQc+NvCois0W2 4n7L7Q/5QktNAiNlzNqlyFOIMdcAQsf4b7ppaBRfufa4AgmgJLDeQZiHV74yVFMiFw+2cVrNVD3O OuQGfOwHZhLHbJVhpbObeZyw2XXJdeWxiYlEqJlrz0bWe53blFEDHrZBS4+aJ5H+wZocPNWIlW1k fNAK031YZSLzcWOCXp9JdtRgzjUAAEAASURBVIFbtMf1m0PGGm3vWlgK3WcPcy7zQaiBoNU2gtst nTBmPIyCnmvMf0o3N+M47+f6NyLGOtqTCc8M9Cw/TKZEeQaz2bLsC6MRP/Nzzz3XRiYfqBd78kUo B0MgV6RM5NMSQwhjLSMKPwmzDS6zSzwKxxmfDDLPCO25ksz+p0RG3ZqJJwnzSOE5y341e+ziZGNj 3ADP08Z0FN9Jwj0lmTCWpJ1Wg974zWA5YMaEGXdsNlga3EllBJbnISx+ofVmy+MRroKoTOZxjBMl MohxgsmX+DlzNNC5kVdF1Px5nOUehykeFYJpxMwuYbIyS7WjnmJs4OgSPlETcJ2YeCtl8L1FO3K7 5yaLmoEw56JmCLizS5xlzCoMQtyLXcufpyCmI8mNejL7g1+LMWh5TDLmFHO94fno5hD/OndTRg27 bBMoPWqeRPoHa3JwqxErz8j4BCrss6BA12eSXeC2q96seFbh3uKeQhhHXWPYCFTtyOWcZGUiPdeY /5RuxczdJlJ4uWlM2Kyw4yZmDxmTDL8dz5SoScBqU37d8V1wbFZ+AvVi95OJ0vghkCtSJtJVltGC qxkz8htvvMGMBmMGvw2MrpHmED8cbRqeYEyYkYMx3sabALdIT4znqzkF3eCJN18xyRCIzNZNHDkB 5B6NE+Zudcstt5CAlVaRAyRuGWzqyvwXDzo4FrhSJk6eHAqaLYZ63C2RmMg+vDcQbYy+2Gkp1PVL jVpo0HMjr4qo2dJYY06j+RgwjEmGS8V4t0Q9xVxFnOiZYLKJ7Tw9U048NTKKoEtgyyJ8wxbDDB5O uMvwFSmD/sNOZk63coT6mGkCm60bQHTiFsBFzsdellxakZ3r57pyc/YTdtmmsHT/YE0l3Wr4qbZJ k0CF/RQU9Pr0X+HkUzKlay4DNyvTqKDVZkLKzcSEzT3NMyHrP6WbofGqRo5gSnTXjbppCLN2iZsG AStlqIPxhuQX5PGIJxkPmdy0MaPWK2USvsd6aqivKSSQK1Im8sIFIhZ+pAxP/0gZ47tQ7+xSvei5 CfL751fBMhNj7LGnEOmZtbWHbMA8cJhHTxtpAtxQcDUlbNIwtnkSmK9+Hlainoi245fP6Yy+ntU6 Jj0l8iPHOBHfsOTJPGi2TPOhY3hcwzvVjvfk6ef2EfTcqFeFp/58xSbE1kGswMSzykqZ+NY7c7dF NPiZ4MAww3WIXjEWb7y4KBQNx32fRU8sf8C4wvSieT7mENcYXuQs2AZRLCmDAQmMJDa5kRVIzQYq xheSQ/ZjrrdYtkCbLFDAZZvC0gOBpcJuNfzXP4EKc5HUm3/Q67PeDFOYwDqYR+YZtNpcTqab3KyM vdmqcHPIf0o3K+6rzEyx/IrlF3GkDL5fyB3uxvYZAB2DeMJ+FnW2GunPulQGAtY9cAFQYsrvsW4r FE4tgfp/fqktL1S5odZxRmP2Hbsij9rc6+NMGfivuXF6MLspuGfx+zFraN1IT5jJBX4/TA3w8Rzi l4kTLr9MY8o2z9bU3JMMQ7Enxv9XFhqQGGf+qLqByrP4nARx7npRywqULQZeMsEvxNUxxGA2i5q5 G5nMuW4+kWGzyoM1nPQLgpIuiD/Hh6cLYxvqxOzj52bI9jDcW5mYt5FmXRKJmVHiHmpyZq6TiwHg uNHgMYPcsekJXHXVVfxlfb7Hj9KmYYEeqhTRY1boEG96LXLzU27uxqGH34I9PeWBVJUeCGwyrUhV hd06pO/6dEtJeThotbmBeOrAjct41HJJu4f8p3TPIswqBH5fWCXNhJHnKF/54fATIMBiC6NLCJvr HCNlZHpieFzBzoppCulmEkS9x/KMah4po2aiyMYikNNSBuhMYfAXMY6lgUvcz6NVvV3Fpizkw++B hT82MWKf5ZqxZL5NhroyS8GZzXHXEDLOMd1AMsYwM69hnqGxoxhHSJMDEwr2d2jzxG+UMD9R43Bq 4yMDrLpiBGWFLaV7TC+MprxjiEhGx6CCL1C2ZnYZiebWlrXQbE1BhZmuiqy2jUnmXJtJ1ABqjAdK dAkLwklQ7/pVtA4WPuzVCBfmjGye9CP3dPrCtXtxf2c2zUgZwnSBSc8cExDwx+SrkTs2H6alzIIU FnuznNtlhQxlh1NzFnOFZo6AE1nMz5VD57JQ1kpqTO6su6FbqbBxQ7ZF+AlgciNZpFyLPDdVpQcC G1kN/zGpqrBbYvquT7eUlIeDVpsr2X1BHjqGmWuWSrEM22P29p/S0yg854y9k5y51LFY2wRc2yyr RsHw6+NnYktEgpjnQ7Mznk1vAzTT+PVbV31jQ+JpgSaYZCzv/+1vf2t/PibS/w3WlqVAygnkygRT LHA87LK7nVkKay/6WIl9xiNHMFHyjkM+//znP/k5oTaYWuJZnCGnXqsJYoXHIMZydlFjMDNb5JnJ ApbS2Bfu8NTIonF2JWerBrQFvzr8Lfit4qnH5hZuVbHHMjoy3qDVGNh4oGHDezeBDWMP4CVt6BiG WySRKZ1z8YzmpsMAzPMNO7zZmQ57YvxAoGy5m6D5eKhCANEuxlpQAIS2M7+D5y+DN/ugRPVT8Xlu /NrGOop0oGLmCTX+7JLJgbEQock0EHKZzsINHKML91OOsuDLdXhE+HJtmCdU4yhjcjBhLh7jT+Op GN2E4wi2OhZAMT/FTowk4zIDHRNJJEYT29V5fEUEcFmy1xkbT+Mfhg0GewwTWOgY8mGzWiuhPAXF +Wr0NLtOY4MkbHRe1PQpLN0/2Kg18RmZwgrbEn1en1GvbZtJwweCVhvLGbcgHt6YFUVYMz1qNmFi 31ujfW0T/Ke0p9gAG9VwZ2P7b36VzDQx9831j1sx5luzXQXPG9zN7AyjESj8ptwFTTY3E2CFNpZX 9pVg5ovb+HnnnccPBIM9P2SePfB05D5MofxaSWbP9X+DtacokHICuW6VQVAbkc6wHelDkDBufgM8 K6MYkPNMEFAK27ny2gHzGzNPObEy5wGdp2oGctx7mQ9mRoDfD4KGGwFriFy7EcMS1eYRAfc3JnoZ k9g9zx29TBHcPvhJkwOuGMgd10gQWQfkDsYk3GVQXTzBM1LyFQ3Bcw+HqFhi0xD+s2VI5kmLkZ4h nKK5AfEkhEGItiMIsMrwkOR5KrKtSOZcm0msgLXEUIqfFVuoRkzc7JxBbbnxQRIdwwBJ69jiyFOK nT8yri3mKAWZTfA8JhlzFOXByzEQdtzBucy423Kp0FPoGDwVuMWjTjyl8PI8TDJYmLjjgxEvMeQp AxVuQG65nrPifGXlKqcjcOkszzrbyLNSVXogsJHV8B+TqgrbEtN6fdpSUh4IWm3uNrxSA1WNwGXN I/YYbI3cOiKXXvtPGdkoLNz4OKLLUSfc4tAfTNpyy0KgU2E2jMB8ggnZnMjti6udMDeiyKxsDDU0 a9SN7kG+cNflN8itlScNnkLJmRu75wYe6AZry1IgtQTy41vskynMrLtjP9xkMmmAczGw85Pjurdj VWoLxc5ptgNhSONpnl8FPwk7fRu/LBIzMvF8YHKImpj8mYriod/dRjNqykCRZMtSRrOaEWHBM3ec OvjP2We2jM0UjfaiXLviBoBYZaiMWcYSq9Bkzo2VZ5LxmLW4oVNzhuF6JxkTKIs7NToJz0qKQGZ5 brWRGZIe5cFFiDHPFceRKdMRk8LS0w3WND+FFSbDEF6ffnrZT7W5v6FgUMn8bM01Sc5MBkUa/Pyn 9FM37gzcA9HTPI6yGU9kcX4yiZUGwxJWJZ5CeSNmanOOVWJWxptHHTNnl44G5rqUYWRFwXCBYnI3 U57JUyYrLDEYIT0P08w1sOUU5k2UU/KlKAcREAERCBUBV6DEr5j/lPHz0dFMIZBuKZOjvjJmhQ5a nhfpsWAPg3+qdAwXFlZNzKo4RmDnx6BiLjWeGJhgIszaWhOjvyIgAiIgAiIgAskTyFEpw8QN0/xI GawyzMuY1xQnT9PkwJ4fWHqwzeAfg+MbTmHG+In3CYfivKsyVRVQPiIgAiIgAiKQOwRyVMowo4Qz Fw5i7LDEgtV6fQsCXRAsQMBNFdXC0mh8O/Cox4MB3zT8izGrBspKiUVABEQgUwiwpRb+bX4cAf2n zJS2q56NSyDXfWUal75KFwEREAEREIGsJ5BuX5lcX4yd9ReQGigCIiACIiAC2U1AUia7+1etEwER EAEREIEsJyApk+UdrOaJgAiIgAiIQHYTkJTJ7v5V60RABERABEQgywlIymR5B6t5IiACIiACIpDd BCRlsrt/1ToREAEREAERyHICkjJZ3sFqngiIgAiIgAhkNwFJmezuX7VOBERABERABLKcgKRMlnew micCIiACIiAC2U1AUia7+1etEwEREAEREIEsJ5Al72BasmTJokWLSkpK9ttvv+rq6tWrVxPmPZFZ 3ntqngiIgAiIgAjkPIGMlzI1NTW//OUv33rrLdOVL7/88sqVKy+77LLBgwc/9thjOd+/AiACIiAC IiACWU4g46XMa6+9ho5p0aLFKaecUlpayvuus7zH1DwREAEREAEREAGHQMZLmalTp9KcM88887rr rnPapaAIiIAIiIAIiEBOEMh4t99t27bRUT169MiJ7lIjRUAEREAEREAE9iaQwVaZjz76aMWKFQsW LKBFX375ZX5+fps2bU444YS9G7jnG/abyZMnz5w5s1mzZoMGDRo1alRZWZk9PGXKlBkzZnTp0uWI I46wkXgQv/DCC3w9/PDDu3btauMp9IsvvvAktkcVEAEREAEREAERaDACGSxlnn766U8++cSQwl2G z4ABA6JKme3bt//xj3986aWXXKxFRUVXX331hRdeiAYift26dX/4wx/atWv35ptvmhgiETdEErjq qqsuvfRSezpF87niiitc3WOPKiACIiACIiACItBgBDJYypx//vnHHXccS5YmTZqEz+8BBxzQunXr qOCuueYazDYtW7a88sorR44cyZzUBx98wPqmO+64AwVz7bXXctbBBx+My/DatWsx27D6yeQzfvx4 E8AG40qZTz/9lPhjjz3WHNVfERABERABERCBxiKQwVLm0EMPhdqECROQMiNGjMDzNyrEd955Bx3T tGnTRx991M4osf3M8OHDf/KTn/z73/8+++yzcbVhHxpmkd5+++0xY8a4Uqa4uLhfv34UUVFRQRqK WLZs2eLFi8mqf//+UUtUpAiIgAiIgAiIQIMRyHi333pJPf7446S56KKLrI4xp2DRwRJTVVX1zDPP 2BgCSBnzlR1r0ED77LMPs0g7duzAz8bEmwQyyRga+isCIiACIiACjUsg+6XM/PnzQXzYYYdFgjaR 8+bNM4ewymB3wcxjVkXNnj178+bNzFvxIQFzTCaZkTIoocgMFSMCIiACIiACItDABLJcyuAKgxyB qcckYyj37NmTALNF5iu+Mocccgh2GqNajKMMOmbfffdF4phI1jR9/vnnHTt2HDZsmDlLf0VABERA BERABBqRQJZLGdZdG7hbt26NpLxlyxYi2SnYHjK2FuPVO27cuCZNmuBSg45BzTDBxEqoadOmoY2O OeYYu8rJnquACIiACIiACIhAwxPIcimDty+7v4DVbD/j4WsijW3GHDryyCMLCwuZQqqtrTWOMsbV F9sM1pqJEycalaPZJQ9JfRUBERABERCBxiKQ5VIGrCxW4u+TTz7pQYxDzIsvvkgky7PtIZZz77// /rxk+8MPP9ywYYPxkuGodZdB5ZDGPcWeq4AIiIAIiIAIiEDDE8h+KcNeMuyGx2Z6Dz74ILYWg5j5 pptvvrm8vJxl2GeddZbL3Vhc7r33XiKtlGGaCQPP+++/z6bAWG7I0D1FYREQAREQAREQgcYikP1D MmLl+uuv//Of//y3v/3tjTfeMFvkjR07Fh3Dm7RvvPFGdo5x6eMHww6/c+bMQbugYMwhtAvWHa1d ckEpLAIiIAIiIAJhIJD9Vhkon3POOZhkWHPEYqXnn3/+9ddfx+GX3WKeeOIJppM83dChQwc23COS v6715cADDyQSP2J2o/Gcoq8iIAIiIAIiIAKNRSCfTWzTVLZZ5Ny3b9805Z9AtpWVlewig7mFtdkF BTkh4xKgpFNEQAREQAREIIUEzP5tUXdFSUkp2T/B5GJiLol3YrsxCouACIiACIiACGQ0AVkmMrr7 VHkREAEREAERyHUCkjK5fgWo/SIgAiIgAiKQ0QQkZTK6+1R5ERABERABEch1ApIyuX4FqP0iIAIi IAIikNEEJGUyuvtUeREQAREQARHIdQKSMrl+Baj9IiACIiACIpDRBCRlMrr7VHkREAEREAERyHUC kjK5fgWo/SIgAiIgAiKQ0QQkZTK6+1R5ERABERABEch1ApIyuX4FqP0iIAIiIAIikNEEJGUyuvtU eREQAREQARHIdQKSMrl+Baj9IiACIiACIpDRBCRlMrr7VHkREAEREAERyHUCkjK5fgWo/SIgAiIg AiKQ0QQkZTK6+1R5ERABERABEch1ApIyuX4FqP0iIAIiIAIikNEEJGUyuvtUeREQAREQARHIdQKS Mrl+Baj9IiACIiACIpDRBCRlMrr7VHkREAEREAERyHUCkjK5fgWo/SIgAiIgAiKQ0QQkZTK6+1R5 ERABERABEch1ApIyuX4FqP0iIAIiIAIikNEEJGUyuvtUeREQAREQARHIdQKSMrl+Baj9IiACIiAC IpDRBCRlMrr7VHkREAEREAERyHUCkjK5fgWo/SIgAiIgAiKQ0QQkZTK6+1R5ERABERABEch1ApIy uX4FqP0iIAIiIAIikNEEJGUyuvtUeREQAREQARHIdQKSMrl+Baj9IiACIiACIpDRBCRlMrr7VHkR EAEREAERyHUCkjK5fgWo/SIgAiIgAiKQ0QQkZTK6+1R5ERABERABEch1ApIyuX4FqP0iIAIiIAIi kNEEJGUyuvtUeREQAREQARHIdQKSMrl+Baj9IiACIiACIpDRBCRlMrr7VHkREAEREAERyHUCkjK5 fgWo/SIgAiIgAiKQ0QSKMrf2y9duq83LK21W3LJZzFas3VSxvbK6aXFhs5LCdVsqCLRrVeK/yavW b6+qqe1Y2qS4KGM037Yd1Z6WNnwrIuvgn7n/lMvWbqNb27YM0KH+M09Vyq07qtZvqUxhPRu+N1OF QvmIgAiIQJoIZMwIHdn+3z4144I/fv6XF2dFHrIx37t3PGleHbv80xlrCPzp+XiJ7Vk28KMHJ3HW /JVbTExVdc2KddtXb9hhE4QwENlSTytSW+eoTCLrkNpCTW4X/3ns3a/MSUfOKczzv5NWcwnd88rc VOXp6c2o/FNVlvIRAREQgYwgkMFS5oQRnUDMqLmjsjoq6xmLN65cXyc7jt+vLmXyn8Wrt51/22fX 3j8h+ayyJgcxadyuFP/G5a/SRUAEwkAg5tRMGCoXvw7H7NuRh/LtFTWfz1p75LCOkYnfn7yayKE9 S7u1a1aQn//zcwZ3bN0kMlmcmCu/0nfL9uoubZvGSRP+Qw3fCpgnQDv8JMNQw4bvzTC0WnUQAREQ gTgEMljK4CSxf/+2Y2evGz25PI6UOWGnSQY5koAiOWxIhzjsMuVQw7ciMdqZwrNx69nwvdm47VXp IiACIlAvgQyWMrSNmSOkzCfT11RU1ZTs7ZlrZpcKCvKO27dudmnpmm3jZq9jiD1oUDsLBafgt79c uXDV1m0V1W1bFg/r2frI4R3cfN6buGrztqqj9+nIHNaYGWvLN9VNV+HI+fKYZQT2H9C2e/tmNrfI ACnfmbAKVxsKwuOYxEcN79C7cwubcuGqLRPnbejeoRmabOL89VMXbZy/YguVHNyj1ah+bZs1KUwg pT3FBmwrWrcotpEEKHHGkk1zlm3GKZW6nTiyc6RPdJwm4H8ai0lU2pS4aVvl+DnrZy/bjMtRr07N B3ZvSTM9LtU4NpHytAO7knjcnPWTF2ygDr07tcAI17lN/eaxevvUJUB42qKNEOjYpsmhg9vbQ9U1 ta9+XlcNrhZXAS9atXXCvPWexNMXb5y0YMPc5Zsx/u3Xtw0WKfcSsnkSiN/FJmW99be96eea9F83 t54Ki4AIiEBmEchsKXPEUJTHbITI2FlrDx+6lwXFzC4dNKCdGb9nLtl0+0uzGa6slHlr/MrbnpvJ oGU77IVPl3V8o8ldV+5nh8x/vbNgcfm2wWWt1m+u5HSTcuPWKhO+8bwhcaTMZzPX/OaJ6Vt37OXH 8693F/z47EGnHtDFZDVl4UayOn5Ep6kLN/7znQW2JgTKOjb77UXDe3ZsHjSlm4kJ21ZYKbNle9Vt z878YGq5m/jBt+dffnLfbxzRw0bGb8KClVtjMYmkTZ7j5677/VMz1myqsPkTQM3cdP5QF+OdL88p yM87eFC7H9w/Ydna7Tbxo+8tvPnCYWg+GxMZ8NOnnrM2bKnrWYTscz8/ND8/3xydvbTuaiF8yYm9 Lzqulz3lhTFLX/x02XdO6GV0D2ICf97/7BQ9Js3D7y6kLbdfNiJyKvORdxfG72Jy8FN/25vxr8lA dbMNVEAEREAEMpFAZkuZFk2LDh3SfvTk1aOnrPZImdFT6sbpE/brHLVXMBv84dkZDFwXH9cLSwn2 j4Urt6IzZi3d/Nsnp9915UjPWX26tPjR2QNZu8RYVdq86PJT+pIAieNJZr+yUPzXj0/bXlnz1YO6 HjCgbf8uLTdsrXzukyXvTVx958uzTxrZubBw16jJKViV3p24CtvPift1YiDEaPHMR0v4+717xj98 /YHtS/f49/hPaWsSGaitrb3+HxNpaYfSkguP7TW0Z6vyjRUfTS1/7YsV97w6t1ObJkcNr3M8qrcJ gZiMm7Puxw9Nqq3NO2RwuzMP6da1bbO5KzYzulONK+4a98gNB7kGIRbAX//ARGxFv/7WUIw3mI5e +HQpKe94efa/fnhgAUpn5+elGw8rcjAG7VOTCaY1Clq3uXLO8s0Duu3q0InzN5ij2GBcKTN21jri j9rtmEUXj5m5tn/Xlhcf37NXpxYQe+ajpbT0hw9MuPvKke4qcT8dF7T+8fn7r5tpqf6KgAiIQOYS yGwpA3fWMSFlPpm2prKqxk5VYBVgCqNpccHhQ/fMGrid9OXc9Qyrw3qV/s+JvU08swPDe5ee/btP meVhUsmzVw0P2Ux5MPuDlGnepIiwm1tkmBEOHYObzg1nDTRHu+c1G1I2hOkVdhlhFB/YfY8Mwqp0 xiHdfnjGAJOSGagjhnVgzS1zH4+9v+gHp++K56j/lJFVsjHYq5AF7VuV3HPVyE47p2wGdMvDzFBZ XfP2l6ue/2SpkTJ+muCTSU1NLdYLgH/toK7X7wbSs1Pzw4a0v+6BidMXb3rwrfk//vogW8Oq6lq6 8t6rR5mZGoDs07v1hX/6nNU6S8q3caJJiZC1pxAI2qfmXIpAXbFkGpniSpniwny0AmYzO3fJFYXa QGsSz7kfTys3OuZvV48sKqxbCYgJ7eBB7X/1+NQPppS/NAbjTW9TBH/9dFzQ+se5JgPVzVZSAREQ ARHIUAIZvBjbEGfCqEXTwi07qr+YU/fEbD5mdglB0LRkj7vJ7oN1/2N74C9OEvNWbLbxrZoV/+Pa /e///ij3Wd8eDRTo0b7ZlafuNVnD6YzlJmfmd9zcGE2ZyHBjsBN896S6mFc+X85MgT3kP6U9JTLw 7MdLiTzz0G5Gx9gE3z2pD5H9u7VEeRAZqAk2k6gBDBU4DNFNl53Sx03QpLjwe6f1I+b1cSuQj+4h bCFGx5hIBARTUYRXb4y5qU/CfXrksLqpSZyuTFk0f9KC9bi8HDKoPToGQWnix85eS8AkJoDljL+X ntTb6BiThr9XfaWuRZi4DEYT76fjEq6/LdoGAtXNnqWACIiACGQogb2eazOxDQwSRw/vyMiBbcZ6 bhopc2KM2SWaOapfG6ZXmFi57K5xBw5od+CAtsN7tx7QtSXTBCmBcODAdvwzWeGNsWj11nkrtuCw SYmR+WMNKm1e7Ikf2a9t05IClpovW7PdmAFI4D+lJzf3K77GfLWs7CGUjWsBCtQEm0nUAI7VxA8t K0UsehIM79W6eZNCPIpAhHqwR/vttHzYrwSMnWx7xR5h5x4lnHCfIlmKi/KnLNyA7QQRSU+xAh8H Xv498t5C5pgIkP8XO2eXrJQhGZELV2/1eP8QSccxF8lmxD067DIg+em4hOtPiZ5PoLp5ztVXERAB Ecg4AhkvZSB+3IhOSJmPp69h51Mekc3sUpsWxXFcREn2j2sPYFsanGw+m7mWf+TDYHn08A64j7iL VhLuUewQz360BIOE2aaPfDq3aYKfDV7Dnjw7t46+MKdLm6YLVm1lUsNKGf8pPUXYrxu3VjJO8zXS L9WmsQH/TbCnRA0sWbONeBZqRT3ao0MzJrxopitlIrVd1HPdyIT7FE8p5CzuLBPmrsf1asL89WQ7 sl+bIWWlSBzmfb5zQh7u4ePmrkP+DtnpILV+c8WmnWak+16b59bBDeN/02O3J7qfjku4/m6hhIPW zXO6voqACIhAxhHIBikzsm8bnEZZxYonCvNNxiRz7L4dXdfayI5hOc8vzh2CLwtjFatkv5y3ngH1 1bErPpxajs9m2e6lQ5En+olh7c/PH57CRA32nq8f3qNXx+asSEIhXf23Lzdu3eTJAWOAJ8Z8Nauf mhTvmQT0nzJqhkQW7vaZxR8lVhoTH6gJ8bPC7kICXswUNZmRViZN1AT+IxPuU2wtSJnPZ69FyrA8 HlMfOoa/w3u2nrxwA3N8c5fXmWqw85lVTs2bFgGS/mWCrMneuwDY2poJI/PVZ8clXH9bKIGgdXPP VVgEREAEMpFANkgZlrQgXJ77eCkmFitlYq1d8nQSzjSMXvwjnk040B+45T7/6VJ3qsVzip+vrChm nLv8lD7nH93TTe+u/bbxzK3YsA0w8JuZC9eY4T+lzccTwFUWexVtxAriLhoiGXM3zKfg0MNiY7xY AjXBU4rna9nOeZaolcdZe/m6OpuNSeM5MbGvCfQpDshsQfTF7HUs78JRZtjuvWGwzaBxcf5lexsq w7ZDpkqonC7tmjL3d9DAtn4mJaO2PWoXk38C9XdBBa2be67CIiACIpCJBPY88Wdi7W2dzfuYPppW jpMmK026tW/qzlbYZDZw+4uzzvrtJ2+MW2FjCPAgzkoiAgzzbnzQMHu7mQ1RWHTtnou3r/EacSMJ 49kwdeGu1b/20NsTVqJ7WGdkN7kJlNLmExkYsNN/1tN2kjFJ98ToxR9PL0fHBG1CZCluDCvF2LGF lUrWhdYeZaVPTU0eooous5GJBZLpU+azcIhheRSv9GIGEAVj6mC8ZLDboXKYHBzRe1c8R/fp1Zq/ rKL31JZlbqf/5uPzbh3DdKc95KeLk6m/LcgEAtXNc66+ioAIiEDGEcgSKTO4rJRFLgxCd/5nDn1w woi9NERkr/Tr0hLLxNMfLsF3xB6trq5lCxO+4qBqI90Az7t8ZfNZUrrxnjCuoyzlJdLkZo5S0G+f mr6jsm54Y12M55TfPzNjSfke2wxbFf/jzfmkufDYnnZKyJziP6WnCPv1O8f3Jvzm+JXvTtgzDOOj +vSHi4lnvz7++m+CHyasUj51/7pdAW99duZixwTFxoZs+EZ85DogIoN+EutTW4rZLebBtxYQYxQM ATxjWNKPRMZih6O0O2V58fG9WI/GJfTh1LpXfZkP8oXNb3CjYTMhfF92R9f9X2/HJVb/qPyD1s2t p8IiIAIikHEEsmGCyUBnDGZ+BJ9fvpr3LsXpDN548PJny+au2PKt2z47ZHB7fGARKDx8s7cvFoKT RkVXQuxYj0ZBMJ176xiSMX90wIA9r0GwxTGGsb8I49/NT0zDCaNDqyZL126bNH8De6UM71XKbMWj 7y3CVcXu6denc93uapfdOW5Yr9bsCGee4Cura3Fb9mxg4z+lrUxkAHvV1w/r/twnS5FW7NrHDjeM 0/gJkZIXJlxwTN2MmP8m+GRy6Ul9Zi7dhMcJS8Z4WUHXdk3Z6d/sRMcWhaeM2rX9cWRt/cck1qc2 /yOGtv/rS7OBj3OS8e01HNjSxqzTpp42MQE2Irrs5D73vT7vpsemkX5At5ZMCOKthVsMFqbLTu7r JvbTcYnVPyr/QHVz66mwCIiACGQigWyTMvQBG5DU67SLy8htl+zLzmy8I8nOESBT2HL3spP6MBJE 7UuegNnhDcHEUlvGrci1SPasn35jUMHzeXgQs70vkSyE4RUKN5w9kJ1sfvbwZHbhY7bFSpm+XVrc cNaAu16Zy3In/pEenfTVA7t++/hedmdbk7P/lLYmUQPf/1p/Jn0w/FAN/pGGtp91aPeL6iwNu2wJ Ppvgkwktuvd7ox58cz4TZ0zimFohaM47quz0g+sm9ZL/JNantlx2VTZCk/XhFgJHmWxCyrC++oD+ Xtl6zpFlKJi7X5mLgDYYcbg5eVRndJt9R4TJ30/HJVb/WPz9180SUEAEREAEMpRAfkVFlJ1OUtKY xYvrJiz69t3r8TQlOacwExansFia9autmhez+Nl9g2PypTCptGzNNrw4kVZ2noiy1m2pZE0TMoVX J/7p+VnYk3553hCKQyHh6MMA38F5WYGphv+UgaqN+w4eqaXNilld5c6e2EzqbYJN6T/AWrOV67cz 68Tg7f8s/ynT2qdRq1FRWTN/1RZURbd2TTHcRU1jIuN0sT0rtfX3XzdbAQVEQAREILUE5s2bR4Zl ZWWpzdbmlpaxxOYe/gADD2Mq/9JRVZxJI/dHadOyhH9Ri2Oey892L5zrP2XUgmwkYgJnZ/s1MhC0 CZE5RMZgoeFfZHyqYtLap1ErWVJcMMh5E0XUNCbST8eltv7+6xan2jokAiIgAmEmsJdnYpgrqrqJ gAiIgAiIgAiIQCQBSZlIJooRAREQAREQARHIGAKSMo3ZVWyEzzIlfELrrYT/lPVmpQQiIAIiIAIi kE0Ect3tN5v6Um0RAREQAREQgRASSLfbr6wyIex0VUkEREAEREAERMAvAUkZv6SUTgREQAREQARE IIQEJGVC2CmqkgiIgAiIgAiIgF8CkjJ+SSmdCIiACIiACIhACAlIyoSwU1QlERABERABERABvwQk ZfySUjoREAEREAEREIEQEpCUCWGnqEoiIAIiIAIiIAJ+CUjK+CWldCIgAiIgAiIgAiEkICkTwk5R lURABERABERABPwSkJTxS0rpREAEREAEREAEQkhAUiaEnaIqiYAIiIAIiIAI+CUgKeOXlNKJgAiI gAiIgAiEkICkTAg7RVUSAREQAREQARHwS0BSxi8ppRMBERABERABEQghAUmZEHaKqiQCIiACIiAC IuCXgKSMX1JKJwIiIAIiIAIiEEICkjIh7BRVSQREQAREQAREwC8BSRm/pJROBERABERABEQghAQk ZULYKaqSCIiACIiACIiAXwKSMn5JKZ0IiIAIiIAIiEAICUjKhLBTVCUREAEREAEREAG/BCRl/JJS OhEQAREQAREQgRASkJQJYaeoSiIgAiIgAiIgAn4JSMr4JaV0IiACIiACIiACISQgKRPCTlGVREAE REAEREAE/BKQlPFLSulEQAREQAREQARCSKAohHXyWaV169b5TKlkIiACIiACIiAC8Qm0bds2foLQ HpVVJrRdo4qJgAiIgAiIgAjUTyCDrTKZqx/r7xalEAEREAEREAER8EdAVhl/nJRKBERABERABEQg lAQkZULZLaqUCIiACIiACIiAPwKSMv44KZUIiIAIiIAIiEAoCUjKhLJbVCkREAEREAEREAF/BCRl /HFSKhEQAREQAREQgVASkJQJZbeoUiIgAiIgAiIgAv4ISMr446RUIiACIiACIiACoSQgKRPKblGl REAEREAEREAE/BGQlPHHSalEQAREQAREQARCSUBSJpTdokqJgAiIgAiIgAj4IyAp44+TUomACIiA CIiACISSgKRMKLtFlRIBERABERABEfBHQFLGHyelEgEREAEREAERCCUBSZlQdosqJQIiIAIiIAIi 4I+ApIw/TkolAiIgAiIgAiIQSgKSMqHsFlVKBERABERABETAHwFJGX+clEoEREAEREAERCCUBCRl QtktqpQIiIAIiIAIiIA/ApIy/jgplQiIgAiIgAiIQCgJSMqEsltUKREQAREQAREQAX8EJGX8cVIq ERABERABERCBUBKQlAllt6hSIiACIiACIiAC/ghIyvjjpFQiIAIiIAIiIAKhJCApE8puUaVEQARE QAREQAT8EZCU8cdJqURABERABERABEJJQFImlN2iSomACIiACIiACPgjICnjj5NSiYAIiIAIiIAI hJKApEwou0WVEgEREAEREAER8EdAUsYfJ6USAREQAREQAREIJQFJmVB2iyolAiIgAiIgAiLgj4Ck jD9OSiUCIiACIiACIhBKAkWhrFWylZq7fPMn09dMXrBh1YYdqzfsILuOrZt0at1kn96tDxvSvl/X lskWoPNFQAREQAREQATCQSC/oqIiTTVZvHgxOfft2zdN+UfNdvSU1Q+9tWDR6q1Rj5rInh2bX3JS 76OHd4yTRodEQAREQAREQARSQmDevHnkU1ZWlpLcIjPJHqvMinXbb3ly+rRFGyMb6YlB6Pz68WlD e5beeN6QLm2beo7qqwiIgAiIgAiIQAYRyBJfmUnz1195z3g/Osb2DYk5hUkoG6OACIiACIiACIhA xhHIBqsMOuaGBydVVdda+gUFeQcNbDeoeyv+Dexe5xkza+nmmUs38e/zWWtranYl3LCl8vp/TPzz pfvu26eNPVcBERABERABERCBDCKQ8b4yzCthXEGUWOi9OzX/2TmDETE2xg2gZv7w9IwFq/Y407Ru UXzf1aM00+RSUlgEREAEREAEUkUg3b4yGS9lrv7bl3ZeKT8/77yjyr5zQu+Sol0TZ8wf/f2NOm+j y0/py/Il0ysVVTX/emfBkx8srt1tx8Fv5p6rRsbps/WbK7ZWVDcrKWzbsiROMh1qXAJbd1St31KZ cd1UWVXDmrsZSzZtq6ge3AM7YqsWTes3l27aVrlpWxXAu7RpWlCQn3Lyy9du4/eRpsxTXltlKAIi EGYC6ZYy9d8xw0yH9UpWx1BPdAySxa0wOmbKwjpHYAJ3XblLrCB0TLInRtetseJDJmQVZ03Tfa/P e3P8yuNGdLzxvKHmFP0NIYH/Tlr9p+dnHT+i0y/PG9Lw1auqrinfWFFYkM/Kf5+lr91UcdtzM8fN WedOj3Juvy4tfvz1QYN6RLcsmsxveWL62NnrCP/+4uGHDmnvs8SoydZtrthRWdO6eXGzJoU2wXdu /wLR/+IvD8NsaSMVEAEREIEQEshst1/WXVumzCthj7Ff6w2QmFNsMjcrG6mACPgnsHj1tvNv++za +yf4PAWT4eV3jfts5tqigvz9+ra58Niel53S5/Ah7ZEOc1dsuea+L//z+bJYWa1cv/2LOXU6hs+r Y5ebQMJ///ribGr+wdTVCeegE0VABESgEQlksFUGm7zdPwY/X/xj7LySBYr15Z5X5/LVY60hhsSc 8r17xxsvYLIiQ+2eZ9EpkFYCs5Zu+uEDE7j2hvUs/d3Fw13LR3VN7R0vzf7P58v/8sLs6uraMw/t HlmT179YwfTomYd2e23sik9nrsG6066Vpj4jOSlGBEQgJwhksFWG/XxtF5n1SvarDeAfg0sv/6yj jD1EANdgTrQxboY2UgERSAeBv78xHx1zwIC2f/nuCFfHUBZTVNefNRAjDeF/vbsQByBPBWpqapEy RJ51SHd2ryafN8bVfdVHBERABHKTQAZbZdwtYWKtV6q3UzlxzIy1JpmbYb0nxk8wffHGSQs2YObp 1q4Zcwe4FUdajEiDeFq1fseOKtwUikb2a3vo4HZNinc5K/Bo/urny/FdOHFkZ8Jzlm2eMH9993bN jhjWgTDOPUN7lfbv2nLG4o0TF2wgpkNpkyFlrY6qbwtj91wyIc/5K7b06dwCSde/W92qdZ7vWa8+ af4GfKh7dWr+lQO7toxwQcXhdPyc9bOXbWb5GGlY7j6qX9vi3a7WZELOFETDe3Zqjh8GuUHjmq/1 t9D88LGJ3UB8aG7KifPXT120kdaxNg1fWmroOoLYlPW2xRDr06WFRw0D6qOp5aiQo/fpuGr9dq6i 8k11r8hAebw8pm5iaP8Bbbu3b2YLcgNfzF6Lfwwx3/tKv5Li6I8TFx3X67UvVlAK/umXnNhnr9Pn rOONHGAH7wn7dXp/8mpSnn90WT595nyYeMKoc8oBXTzX3qfT1/A2j4MGtYPMh1NXr9tUuWztds77 cu76HRU1LZsVHTeik5NNHj34zoRVmJGKCvN7d2pxzL4dO7fRxpIuIYVFQAQamUAGSxnu5hZepJSZ uWTTXf+Zw2BGGmz4jKNRnSjdE90Mbc5BAzsqq+95ZS6zA/bEh99dyJB2+2UjrDcoK1ZuemzqmJm7 JJRJ+fJnyxmc/njJvqXN67ws8SG9/aXZnMJY9Zsnpn0wpZzI75zQCykzdvZanumvPLUvmuOBN+bb gggcOrj9by8aFmc9izn3ilP7jp68+rH/LrLnsqTrziv248QfPzRp49Y9ZoDH3190//f3d1eqj5+7 7vdPzVizaa/3XVDzm84fakfuD6eWMwD/+OsDWZJzzf1fVlbVLRUzUsYPH1srN+AHmk3/yLsL//nO AvuVQFnHZr+9aDjvrHAj/bTFEGMqxyNllq7ZRgehJpEyC1ZuJWxyhp4Js5e0BeIWShgXcv4eMqgd CslzyH5Ff3z98O7075vjVnqkDMKFZCeN7Mzfgwe1K21eRGUmzt+AdrSnE7jz5Tn47VI9j5R59pMl KFGuE7oVz/fpizeZs6gV/wDlSpnJCzfc9uxMs1TKJHv0vYU3Xzhs//5t3bIUFgEREIFGJJDBUsa8 J9KwYyj1QLQ6hngEDV/vjrbc2j3RzdCTm/+vvBIBjcIId/HxPXt1asGK1mc+WsojOI4Rd1850qzl vvuVOaQp69Ds9IO7DetVWtqseNrijUSyj99/Plt+wc6ZBVvio+8tQsf07twc1TXC2cqPUWfh6i0X HNOTwYzH5Xcnrnr5s2Wfzljz3qRVJ+xXN8jF+Tz38ZINWysvO7kPExyYfNA02Id+8ejUHSwGLivl +b5zmyZsvXPXy3OQd/e/Pu9X39q1bouGoHXw0jhkcLszD+nWtW2zuSs2oxuo+RV3jXvkhoNcj401 Gyv++fYUpkv2H9QW442pjx8+UWvuHxptgQZD+In7dUJMYD165qMl/P3ePeMfvv7A9qW7lhcFakvU KtlIFMmPzh7I9YNsRVgYx6zBZTHXHy0u38a5I/vtpTxsbjawf7+2D+TNpwvQf9ZcxxZKH08rxzmM hVqkLCosoKVcNthgPFLG5hMnwPXD8nWuHHrw1P27cDV6jHB/fG4m72G94ayB9CDLxV/4dCkp73h5 9r9+eGAcxRynRB0SAREQgZQTyGApE5+FES7H/u9ok8yYZ+KfkvxRxhijY/529UjGGDLEDHDwoPa/ enwqcuSlMcvMGqvRO00s//ftfbp32DUBQWDz9ioeoz31ZH7h4XcXXH1aPx7QPdMH81du4bnfPkAP KStlkGMigIG8XinDmuE/XrLPAQN2+Qn94tzBZ//uU8rCfEW8KahHh+aoHJQHMwuGDC4aGJzQMV87 qCvOHCaSOQ7cNa57YCIP9w++NZ8lxBYjj++M8XdcsR+zbCbSJx+bgxvwDw1T0BmHdPvhGQPM6b07 t8CU9aMHJzHt9dj7i35wel180La4NYkMYzw77cCuTGYhZZo3KSIcmcaNWbzzdacWi3vIDVtjGNIH cWwOvTl+BSu3sei02b3F0Yn7dUbKsJsATWN6yM2h3vDhQzuQ5vOZaxEoI/q2PnlUF88pTFzee/Uo Y9eBJKapC//0OWu1lpRvo+s9ifVVBERABBqFQPR5+kapStBC7XwNJ3IjDnq6Se+e6GaYWG48/XPi pSf1NjrGZnLVV/oRZl6AEZSB9vyjyphtsTrGJCveKX22bN8zuUM8YgL3l28c0cOjYzjEU7LVMSaH 4/ate0z3Y1vat3drq2M4hdHXDKtfObCLW5AZPrHfmPwxY6CfWjQtZM2wiTF/MRh877S6Br4+bsXm nZu2mfjK6tqffXOwO2D74ePmbMOBoDHuXnJib3suATbN++5JdTGvfL4cCweBoG3hlFR9tu2o3rqj rg5tW9bNJMb54IiD9YVPuTOXamaX8KCyJw7vVYoVjVm8t7+sm7dK7QeXHXd+CiuXMWSu3rhneje1 JSo3ERABEQhKINgzXNDc05oeu/fC3e8f4HUEie0Sxom2kmRow4kF5q3YwokLV2/1uJIQ2bSkAJGx bO02rB3nHlVm8scrc+nabQtWbsFgwCgbtVAMDFHj+3X1ulmYJ/LtFbtfMRX1tJ2RkS4aVI8jHnfO Jnt7pBraQ8tKWzXzjsHDe7Vu3qSQEZo17fg4m5JH9GmNQ7FbC5983FNMGC3iH9rw3qXG38jNB69q 2gicZWu20/ygbXGzSjKM9zGTULjUrN64l79RZLbYycxOAdY8M3XhBmpOvyBf3Jd1YBh74dNlr36x /KzDoqzcjszZfwyb9XkS777M6tSYPiIgAiIQBgIZLGWwdZvdTuHoKpJAWN0TPX6dgfIhMS83MN6R 971W96qEqJ91myt7dMjDGZPVs0wGzViy0bjEsu88oz4bo0We1a1d9NUikaN15LmxYvZe6bInVfzt 75esqfPw8BiT7Mk9OjTDxIX/qZUyrj2GZP752DzdgH9onVtHJ8Ye/DgAUUOkTNC2uDVJPlzWoTkz ifhRxc/KJKBTrPuwMcmwM++5t34Wee7c5Vvwdo/q3h6Z2GdMMpeZzyKUTAREQASSJJDBUoYn0Yfe XmDaz1oeRIm7HMkPF07hRJuSDG04gUDzpuzamldTm8dsSxNnZbKbVae6iYCanzw0ifUmzC+cflA3 nEN7tG+GgzBLwX/6r8luYhNu3ypZW1FknonFYHfhROZHop6+ZXtdvEljErQv3WvTNp98omYeCBqz UVEzMdM6xtQUtC2RGdbYN3hFHqsvhslBpAxeTecfXbd5TKzPJzPqdk7q1r6ZWegOeXy6iUHZmIkn 98S1Gyu27KjG+bdeKWMsPe65CouACIhARhPIYCnDzrw41ZoNf7k7877r+6/Z353Xj98xPOVzir2t k1WSW/1SdJd2TZm/OGggC3a8ZnlbGRwa0DFMZt3//VHWc5Oj1TGGxshBy2bVwAFsCZRod1h2S0dq LF9XZ2Mwacyhgr2NPz75uNnaMFun+IcWtYboADPrZ6xK/tviOg/Z+hBYuS5xZ5HTD+mGfYW3g6Ff Y9kC2Z/mpU/r9qexM4zoGCbIurVv+tiPDnJrYsJsZsMicJZuoaSbltSJzr3x7zmDlx7s+aKQCIiA CGQ+gQx2+wX+JTt9OU0vMHfA5iieHmFJjo1hNdP3//al/UpiTrFf3axsZNDAPr1acwrDiedE1rac /puPz7t1DLvFMAXAUTYoc3UMMbjLeM4K21dW6jI6slIpsqoszkIUshKbgTZOtf3wiXp6IGh45OBT 4snn7Qkr8aFu36rE+AP5bwsvWSQrNsrzZDhm5p7Npj2H6v2K+fDYfTuSjD0CmHeLTI8TFcvZsLLg JXPGwbucpcy7lk6JWGRkTmfnOtbkY3lC9pmYXTVfvlfNcdxmY8PIEhUjAiIgAplLILOlDO+ytp4Z 9AHbsvEGbMwttj9YKGTVjNkoj0MkIBmJbTIyifNabJus3sDFx/diOHn6wyVsomoTI1/YhwM3GjZx YWVTq+Z1ljCGRoYrm+aT6eVP7ayPW3l7NCQBDFdsPUJlbn12pllObCo2dtZaIyIjl255au6Hj+cU 8zUotN8/M2NJ+R6dyp7I/3izbi9B3gbAPjcE/LcFHyDSY0FBj5rK8BdXJ97Cbb+agLEIYk1xe9aT xn699KQ+LZoUstvN1fd9ibyw8QQ2bq38+SNT2DcI4XjlV/qa2SXSmL3s3LVL7lk4tRwyqG6G1Cge AqbmuJOj4UxK/Ih5c3ik+c/sOOxujejmrLAIiIAIhJxABk8wGbLsrXLlPePNag7u0exeyr7svCfS +M3gN+DZGQ//GOaVXHsMS17JxE8/fTil/IxbPo6akgUyv/7WUBxd2Xfuvtfn3fTYNF4jMKBbSyY1 2FkV7w3MFZed3JdzDxnc/pH3FrLb2GV3jdu/fxsOzdnprXnU8A7sPcOOc395YZbZ+yRqQY0byQAM QNxLqTyvAujarikvZ2Dqh1pR/1gGA1tnP3xsYjcQCBoO1DjMXnbnuGG9WuOVYow0rAxng1p3xxef bWECiEXpc5ZvvvTOL2hy9/ZN0R+oim8f34tdZNxKdmzDsvR8BMG5t47BQHX5KexAuOcNX25Kwvi7 MB/KhkPAvOSvXzDhiKEIDx58aFijxJXMKicuS5uDEShsgmdXM3ky5OuJIzt9NK0c1bVo1VY2fTn7 sO7j567HSMNbIw4f2n7D5kreU8GOA0cM7UAy93TjVsxeiLzaiZ0b2czXPaqwCIiACIScQMZLGe7s v7lg6A0PTmLfMMMamcL7rs0LJhE0ZhsMFtcwBhs/X+sfQ3qMKJweZ3hw+4/hsNLZ1N89ZPeDOefI MhTM3a/MZU7EPEbj7HLyqM4MnOatgVTpF+cMYdjgOds8jjO6/PycwTxtX3v/BJwneOmB2ePfzT8k YUboe7836sE35zNfw87CplYImvOOKmPnYj+VrJdP1EwCQevbpcUNZw2465W5bB7DPzKk2l89sCvi w92g1n9bfnfxMAxRyIKdGeYhO9jblwvMI2WwyrBzIDqVVfdI2HqNHAiIe64a+cCb8z+buZYd51bt NvMwCza8d2v2RbQbHeGKZPaMOWX/PdvJRILitRWslGZrH3TPVaf1Y/u7684cwHo6jDHsoVdclM9u 0b88dwgmSc+5iB4uV649Lsgq9+fhSaevIiACIhBKAvkVFVGm6lNS1cWL62Zw+vatM0Wk+zNp/vqb Hp/m7rThp0S0xS0XDovld+knhzhpKipr5q/awvDGamq767xNj80fywEVZpsZI3E4VFtby3pstjuL 3LjFnhieAAMkDqTM1LSIeN+kn0rG5xM1h6DQkBT4haC02LI2aoY20k9bUKtMq/HeA6sw7OnJB9jr efbSTZjoEG321QrJZ0sO7Mq4Yv125jf7dm7hvvIzJZkrExEQARHwQ2DevLonqLKyMj+JE0iTJVKG ljNo3fLk9EiP1FhQ8I/BgO/THhMrE8WLgAiIgAiIgAjEJ5BuKZPxE0wWH6IEcz1vonnorQVRl+Pa lBgSWK+UEj9fm6cCIiACIiACIiACjUIge6SMwYdA4R++qOw/xtw/bxU27yRiUgAXB+aS2Acvyf1j GqWfVKgIiIAIiIAIiEBUAtkmZUwjESvSK1H7W5EiIAIiIAIikGUEMntfmSzrDDVHBERABERABEQg KAFJmaDElF4EREAEREAERCBEBCRlQtQZqooIiIAIiIAIiEBQApIyQYkpvQiIgAiIgAiIQIgISMqE qDNUFREQAREQAREQgaAEJGWCElN6ERABERABERCBEBGQlAlRZ6gqIiACIiACIiACQQlIygQlpvQi IAIiIAIiIAIhIiApE6LOUFVEQAREQAREQASCEpCUCUpM6UVABERABERABEJEQFImRJ2hqoiACIiA CIiACAQlICkTlJjSi4AIiIAIiIAIhIiApEyIOkNVEQEREAEREAERCEpAUiYoMaUXAREQAREQAREI EQFJmRB1hqoiAiIgAiIgAiIQlICkTFBiSi8CIiACIiACIhAiApIyIeoMVUUEREAEREAERCAoAUmZ oMSUXgREQAREQAREIEQEJGVC1BmqigiIgAiIgAiIQFACkjJBiSm9CIiACIiACIhAiAhIyoRHGAb7 AAAjrUlEQVSoM1QVERABERABERCBoAQkZYISU3oREAEREAEREIEQEZCUCVFnqCoiIAIiIAIiIAJB CUjKBCWm9CIgAiIgAiIgAiEiICkTos5QVURABERABERABIISkJQJSkzpRUAEREAEREAEQkRAUiZE naGqiIAIiIAIiIAIBCUgKROUmNKLgAiIgAiIgAiEiICkTIg6Q1URAREQAREQAREISkBSJigxpRcB ERABERABEQgRAUmZEHWGqiICIiACIiACIhCUgKRMUGJKLwIiIAIiIAIiECICkjIh6gxVRQREQARE QAREICgBSZmgxJReBERABERABEQgRAQkZULUGaqKCIiACIiACIhAUAKSMkGJKb0IiIAIiIAIiECI CEjKhKgzVBUREAEREAEREIGgBCRlghJTehEQAREQAREQgRARkJQJUWeoKiIgAiIgAiIgAkEJpFHK 5OfnU5uampqgdVJ6ERABERABERCB7CBgZICRBGlqURqlTHFxMZXetm1bmqqubEVABERABERABEJO wMgAIwnSVNU0SpnmzZtT6TVr1lRXV6ep9spWBERABERABEQgtAQQAMgAqmckQZrqmUYp07JlS1RY VVXV0qVLt2zZopmmNHWhshUBERABERCBsBFg0GfoRwAgAxADSIL01TC/oqIifbnTgPLy8srKyvQV oZxFQAREQAREQARCSwAd06FDh6KiovTVML1ShnrX1tZu3rx569atCBrC6WuJchYBERABERABEQgJ Afx8ETHMK2GPSavPL+1Nu5QJCVNVQwREQAREQAREICsJpNFXJit5qVEiIAIiIAIiIAKhIiApE6ru UGVEQAREQAREQASCEZCUCcZLqUVABERABERABEJFQFImVN2hyoiACIiACIiACAQjICkTjJdSi4AI iIAIiIAIhIqApEyoukOVEQEREAEREAERCEZAUiYYL6UWAREQAREQAREIFQFJmVB1hyojAiIgAiIg AiIQjICkTDBeSi0CIiACIiACIhAqApIyoeoOVUYEREAEREAERCAYAUmZYLyUWgREQAREQAREIFQE JGVC1R2qjAiIgAiIgAiIQDACkjLBeCm1CIiACIiACIhAqAhIyoSqO1QZERABERABERCBYAQkZYLx UmoREAEREAEREIFQEZCUCVV3qDIiIAIiIAIiIALBCEjKBOOl1CIgAiIgAiIgAqEiICkTqu5QZURA BERABERABIIRkJQJxkupRUAEREAEREAEQkVAUiZU3aHKiIAIiIAIiIAIBCMgKROMl1KLgAiIgAiI gAiEioCkTKi6Q5URAREQAREQAREIRkBSJhgvpRYBERABERABEQgVAUmZUHWHKiMCIiACIiACIhCM gKRMMF5KLQIiIAIiIAIiECoCkjKh6g5VRgREQAREQAREIBgBSZlgvJRaBERABERABEQgVAQkZULV HaqMCIiACIiACIhAMAKSMsF4KbUIiIAIiIAIiECoCBQtXrw4VBVSZURABERABERABETAPwFZZfyz UkoREAEREAEREIHQEcivqKgIXaVUIREQAREQAREQARHwR0BWGX+clEoEREAEREAERCCUBCRlQtkt qpQIiIAIiIAIiIA/ApIy/jgplQiIgAiIgAiIQCgJSMqEsltUKREQAREQAREQAX8EJGX8cVIqERAB ERABERCBUBKQlAllt6hSIiACIiACIiAC/ghIyvjjpFQiIAIiIAIiIAKhJCApE8puUaVEQAREQARE QAT8EZCU8cdJqURABERABERABEJJQFImlN2iSomACIiACIiACPgjICnjj5NSiYAIiIAIiIAIhJKA pEwou0WVEgEREAEREAER8EdAUsYfJ6USAREQAREQAREIJQFJmVB2iyolAiIgAiIgAiLgj4CkjD9O SiUCIiACIiACIhBKApIyoewWVUoEREAEREAERMAfAUkZf5yUSgREQAREQAREIJQEJGVC2S2qlAiI gAiIgAiIgD8CkjL+OCmVCIiACIiACIhAKAlIyoSyW1QpERABERABERABfwQkZfxxUioREAEREAER EIFQEpCUCWW3qFIiIAIiIAIiIAL+CEjK+OOkVCIgAiIgAiIgAqEkUBTKWu1VqaqqqjVr1mzdunXb tm3bt2/nrwmUlpY2a9asadOm/DWB5s2bE9jrZH0RAREQAREQARHIagL5FRUV4WwgemXFzs/q1atr amp8VrJly5Zdu3bt0qVLu3bt8vPzfZ6lZCIgAiIgAiIgAhlKIHRSBhvMvHnzli5dumHDhmSYFhcX I2i6devGX2maZEjqXBEQAREQAREIM4EQSRlMLwsWLJgxY0ZqDUVt2rQZOnRop06dwtwNqpsIiIAI iIAIiEBiBEIhZWpra5csWTJ9+nQcYhJrRr1ndezYcdiwYciaelMqgQiIgAiIgAiIQAYRaHwps2nT pi+++CLJ6SSfxJlvGjFiRJMmTXymVzIREAEREAEREIGQE2hkKbNy5cqxY8fiH9NgmFjldPDBB7du 3brBSlRBIiACIiACIiAC6SPQmFJmzpw5U6ZMSV/bYuVcWFh4wAEHsNApVgLFi4AIiIAIiIAIZAqB xpEyePhOnDhx4cKFjYgJX+CBAwc2YgVUtAiIgAiIgAiIQPIEGkHKoGM++eST8vLy5GufZA5lZWWj Ro3SUu0kMep0ERABERABEWhEAo3w4gLsMWHQMUBfvHgxy6Yakb6KFgEREAEREAERSJJAQ0sZ/GMa d17Jw2vWrFmsA/dE6qsIiIAIiIAIiECmEGhQKcN6pUbx843fGePHj1+3bl38NDoqAiIgAiIgAiIQ TgIN5yvD/jGjR4+Ote56+PDhvGpg8+bNy5Yt27JlSwph8b5JtpPh3ZMFBQWolqg5k+boo4/Wqyij wlGkCIiACIiACISZQAO9GZv9fNkHL5aOQcT069fPuN+yJy82krlz5yY/79O5c+cBAwa0b9/eOvYy vbVx48bI/uCF21TvyCOPjDykGBEQAREQAREQgTATaCApgy6Js59vhw4drNoAVtu2bdn3pW/fvpMn T3anfkiD4aSkpATpw4evlTs/vLMJLVJdXW1B837sffbZByljY0yA1xdElTIcXbNmDQYh7DeeU/RV BERABERABEQgzAQaQsqw+jr+QiEMJ5GM2rVrd9RRR7HIaO3atbw7iY+ZJIpMSQxWHyaw1u/8tGjR ok+fPkwnRaakIOw9kfEmZtq0aeyb54qqWCkVLwIiIAIiIAIiEBICDSFleN91/PdEYmKJigNV0XPn J+pRN5KUCB0+JHfjPeFYBZlkeOosWrSoV69enrP0VQREQAREQAREILQEopguUltX/GNmzJgRP8+i ooZQVNSh3oKwHrkTVfGrraMiIAIiIAIiIAKNTiDtUmbevHn4ssRvJx4v8ROk6mi9BeFzM3/+/FQV p3xEQAREQAREQATSTSDtUmbp0qX1toGZnXrTpCSBn4LwzklJWcpEBERABERABESgAQgUvfLKK+kr BntMrK1c3EKZ1sGfxo1JU5i9fXEirjdzlk2xTqreZEogAiIgAiIgAiLQ6ATy4zvkxq8f64biJ8jo o0GXMgVNnz444alJ+tqonEUgWwlk7n01c2uerddS8u2KNZrE6ms3faw0plZuygTq6Tm9gfxtE6io ThEBERABERABEchQAh61kdZWJChl4quttNZYmYuACIiACIiACDQAgUwZ69Pu9tsArFWECIiACIiA CIhAzhJI0CqTs7yiNrxhzGgNU0rUBipSBESgwQik75ee7idsU/N0l9JgHZGVBQW9uvz3ZtCcU4s3 QSmjSza13aDcREAEREAERCBsBGIJFP8SJ00t8lQgQSljKkcjPdmlqdINlm2sbmuwCqggERABERAB EchoAq4waJhRNSkpk9GsVXkREAEREAEREIEECBiB4kqWBDJJ8hS39GSlTBYYZhpGMybZZzpdBERA BERABJIhkPLBzk+GRnD4SZlM05KVMsmUrXNFQAREQAREQAREIAECrjzKMCnjVt01LiVAQaeIgAiI gAiIgAikkECscTndtpkoUsaVC6aFsSqXwvYrKxEQAREQAREQgTQRiBzZ01RQo2RbVG/z6tUxJofI ZG7OkUcjW+umjzwaGROr3MiU6YsJWuf01UQ5i4AIiEAYCOiuGKsX/IyDsc71Ex8G8m4d0t1el8ku q0y6i3Sb5xavsAiIgAiIgAiIQPYRaMhxXy8uyL7rRy0SAREQAREQgRwiICmTQ52tpopAqAj87oNC /oWqSqqMCIhAJhKI4vabWDMa0pTk1jCyXP+TZZHnujnHDydzbvycI482ZFmRpStGBNJBABFzy/u7 7j+/OKo6HUUoTw8Bcyfxf4f0nK6vSRJInr87Frj96MYnWckMPb3IxZGhbVC1RUAEMovALaOLfjd6 lz3GCBqpmczqQdVWBEJFQBNMoeoOVUYEsp+Aq2NMa1EzmmnK/o5XC0UgbQS8UgY7lfmkrURlLAIi kLsErI759bFVhoIJSM3k7jWhlotA0gS8UibpDBs/g1hSbLdI2/N/YnWNlX9iueksEcgdAr/G+rJz Xun3J1T97Mhd/jEE+AoEqZncuRJyuaV7RqDgoVzmFr/te7n9AjZ+ah0VAREQgcQIoGP+sHO90u2n Vl114F5+vtcfVt2sOO+614vkN5MYW52VgwRSPl6v2pL3wcLCz5cWzCzPX7A+v3xr/paKOq4tSvI6 NK/t3aZ2UIfag7rXHNWrulOL0PHeS8rIBTgM/ZPyCzQMjVIdcpyA0TGFBXn3fa3qohF76RhDBnFT Uph39StSM1l1pTS7pSnt2Xbj9qxqVXY1Zs22vMcnFT49tWje2vzDe9Yc0avm5P7VZaW1HVvUtiiu a+qWyrzVW/IXb8yfsqrg6amF175W3Ldd7TnDqi7Yt7p9s7CwiPLiAgmasHSO6iECWUHgjjGF2GPQ MQ+eWXne8JpYbbp0VJ2aufI/dWqmY4u8y/ePonhinat4ERCBoASWb8r765iixyYVndSv+qajK4/v W1MYbWKGX2XbprUD29ce36fmBwfnVdfmvTev4N+TC//wYfF5+1T/6LDKbq2Clpz69HtZZVKffePl mFrbRmpzi0WlYUqJVbriRSBNBL61b/VTUwp/dHjV2UNi6hhTNAab4sLaez4v+sZQ6Zg09YayFYG8 qpq8uz4ruv3TovP3qfr8su3dSwMwQe6c2K+Gf8s2Vd4xpuiQB5ped2jV9w+uKm4Qz1t3lHTNLvnb tm3zNMI97DmUs19dfOmD0DClpK/+ylkEAhFo+psmpN9+045AZylxkgQa8g6vCaYkOysdp89Zm3/R 8yWdW9b+5eTKvm1r4xRB99U7OThvXf71bxav2Jz/zzMrhnSIl1ucgnweijNENoiO8llNJ9nSpUtX rFjhRCiYDQRmz549c+bMbGiJ2iACIiACGUjgPzMLjn+4yf+MrHrxvAqrYxZtyJ+wItrcUrQG7nSs 2fO+ETIhq0tGVp30SJOXZzaaomi0gqMh2hW3bNkydAxqZtWqVXGS6VBmEZgzZ86GDRs2bdo0a9as zKq5aisCIiACWUDgwfGFP3yj5Plzd3gc0cYuzf/p2ztdfH008s+fFHVp6bW+kOHL5++47o0SivCR RyJJ4phkyC50Umb5zg81KywsbN68eSItzpBz6BjPJ0MqnmA1W7Xa5Ru2ceNGqZkEIeo0EUiagOe2 k8KvSVdNGaSRwN/HFaJC3rp4x/7dvELkjME1s9cWTC/3GmYiZ5c+XlynGY7qFcXpbWTXWjL/0ydF FJTGZsTIOoqUMVd2jPTpjUbGYJKhDHRMv379WrZsmd7ylHsDEujcuXNZWZkpEDXDZFMDFq6iREAE RCB3CbwyqwAd8/pFFf2iOccUFeTdemIlvsD1fg7tUfPyt6I7t63emkfmb1xUQUEUV29WqU0QohVM TCoZHVNQUNC/f3/pmNT2dBhyQ83gcrhkyRIqw2QTambAgAFhqJjqkCQB48DrJ5P4Tr6pysdPTZRG BHKEwIzy/KtfLXnp/B29WtfZY5AsaBfP55v+1gwW5Of1iLbc6dlphcUFtVh3KOKpb1ac8UST/u12 DE6zF7DbhIgG7T4Yy+q4+3iK/zfOMWQqHZNisiHLrkuXLt27dzeVMmomZBVUdURABEQgewhU1uR9 +4WSXx1TuV+XXfNKLDj63Qcps2Jsrcy7+tXi56YVomMMNQr69TGVFErRKfn4mSkK3B4ypXKpXc63 cuVKnHzJFh3DvJJ1qkgJhSQzMe1NMhOd7hLo2rUr14+xwKFmcAfGCOcmUDhDCcS3uPhplJ8c/Ftu /JSoNCKQ3QTu/qyoW6vaS0bu2qiJEe2mY6pOfqSEVv/y6D27NyU2pk9dnf/t50vWbMsfe/leGzr/ z8jql2cWsnXN9YfuemtsYpD9j78xrTKJFZzAWSxTMjMORseUlkazXiWQr04JMYFu3bohaEwF169f j5oJcWVVNREQARHISALLNuX95dOiP59c6da+Y/O8Ny+uKGvtxiUSfujLwqMeajJ1Vf69p1V0iFii 85dTKtmCjwo0zKeRpQw6ZvHixTQV8dW3b1/pmIbp9TCUwjSTq2bmzZsXhlqpDiIgAiKQNQT++HHx +cOr7P4xtl2omW/vt8ckY+N9BjbuyLvo+eKrXyneWpF3yajqUwdEmUnq06aWom/72O8ab59Fx0rW mFJm9erVRscYe0zr1kmrxFitVHwoCaBmcJ0xVVu7dq3UTCh7SZUSARHISALlW/OenFL4w+SmeCJb Pm5Z/qH/aPLs1LoV17xXkqVPkWlMDC80eHpKIdVogE+jSRl0zKJFi2ihdEwDdHNoi+jRo4erZubP nx/aqqpiIiAC8QlgXPd8THpPZIN9jV/brD/6xOTCU/pX+3zXo9spscjgNnznZ4XHPdyEd2iTpu4F sWdUtqzzutnzwdX3+ekFCzfUJejaKo+XbFONPYcDhvDg8enE0zhSpry83OoYzSsF7NxsS46aYZG2 adWaNWukZrKtg9UeERCBxiDw5JSib+2zaxbpqamFHyxMarjHuPL1p0p++lZxxW5H3hsOqzqkx15T S09PLRx8V9P7vyhav/vVjlTgqamBVxclQCvBMlBwtjCfosmmZ7hauHAhX8kEHdPo80puW2wlFWhI AmbrPBayUSiXBz3Su3fvhqyAyhIBERCBbCKwakve/HX5x/XdJTUqq/N++Hqd28qL51f0ahO4oR8t KvjOiyVLN+w5cb+utb84areo2R09rFPNKxfscF8qSQW+/UI+zr8+jUO7c9rrf1djxBqvE5Qye5UT 5AsD1YIFCzgjJDomSN2VNo0EUDM1NTVMO1IGRjv+Ss2kEbeyFgERyGoCoxcWHtGrpnC3zeHCfav5 x2sHgi5cqq7Nu/Wjot9/UFTt2F+aFjO1VFESMXE0rOOurWssWipANT5YWHje8MS9jG1ucQIpkDJG Jbm6KVZ5Hh3Tpk1wcRgr60TjY0m8RPPTeYkT6NWrF1eR0TH8pWuISTw7nSkCIpDbBMJ2e/czSqaq x8YuLTiszFEfO/M9vKwmEJOlG/Mufalk9ALvzNTNx1YNjVAtsWp+eM+a8csLkpcy8WvurWKs2iQf zxIVO6/Up0+fMOiY5BulHFJLAEtMhw4dTJ52gVtqi1BuIiACIpD1BGaW5w9q75UygVr9xpyCQ//R NFLHHN275vsHeaeW4uRMNWat2W0dipMuuUMpsMr4qYDxj0GTIqwYrtq2bevnLKXJQQJcHlwnXDC0 3XjP2JdQ5iANNVkEGp1A8tsrJ5ODnw2gGx1RCCswd21+//be6R7/9bxldNH/fVhUG5FB66Z5fz+9 kjcx+f/0a1c7J/1SpiGsMsYeY3VMu3bt/FNQyhwkgNGuffv2puGoGbP5UA5yUJNFQAREIDECq7bk d24RoUT85fX67LrXaEd9GSQbB/fc+U5KfznVpWrfrJbK+E+fWMqUWWUi57HsvKA9RAyunUErak/n RJtn0EwaIL1bzwYortGLSGt7i4qK3PzdcKM3XBWIRSCxbmrIs2LVPE3xYb5f+W9yMnYRY49JJgf/ 9Qx/ysQu9cTatWlHXuumiQgIFl1/79WS/z2y6soDq894ouSzxXsyOWtozQX71u+92+yWpqbO226s ezETG89QmVgfl0kyv5eUSZlYFSWe6SSqyMIl/uIuQ9XtM3ecs3QoZwmw5xBvtDDN79ixY8+ePXMW hRouAiIgAkkSsBN8fjTlNa8V925T++Mjqll89OoFFd94qvj9+XWzN11a5d31lQo/NTEKxk1Zkn6h kcYSjNoyOstMKpndz8xibD9qxtVrhoubp0sqMqU5Gl/lxTrLzVnhBibAdJLVMWydJ0eZBuav4kRA BLKAQKsmebwpqbRJXVP8KBjT5McmFrw9t+CzyyvMKm4MKi+eX3na4yWfLMq/72uVHZrvsdC4iOKP s5sr8lrtvSOwOTdy/I2McUuJH24IXxlTA9SM3SkENYMDTfya6WgOEuAd6cbVl7Zjj5GOycFrQE0W ARFInkCnFrUrA3qoLFyfd8ObxbeeWNWv7S4nG/675/PCsUvzf3F09Sn9AzuHmFas2ZbfpmmCXjv+ OaTRKmMq4eos1tny1VhlzF/XBdhNGb8BQVPG14zxy9LRBiOwdOnSFStWmOK4VLSpTIORV0EiIAJZ RsCsGxrQzq+GqKnNu/zl4sN61vCma4Ni9da8S14snrC84JlzKk+Oq2PMiBxrnDVrqfyP2ol1RNql jKdazCvRYDxm+BupZjyJ9TV3CKBjli9fbtqLjrEGvNwhkIMt3fErX1PvOUhGTRaBJAkM6lA7c03+ qQP8ZnPXZ4VTVxd8ccUOM4c0emHBt58vZkuYMZft6F7qN5Oo6WauKRiYxLLwqHlGRjbcBJMtm4HK OHIaNbNu3Tp7SIHcJLBs2TKrYxC70jG5eRmo1SIgAqkicGD3mo8X+R3fp67O/9V/i+4+rbJLy7yq mrzfjC766mPFl+1f9dpFlYF0DKYd3o3gaQLVGNk1wckpT1ZxvnpLjZM0hYfsshTUDL7A69evT2Hm yiqzCCBikDKmzugYNpXJrPqrtiIgAiIQNgLsyfvRwgLeoOR+ppfno1rcGMIV1XmXvlj8jWE1Zw6u Wbwh75RHSx6eUPjahRW/OKpuEVOgz9JN+de8Wjzqvib/nrzr/UxUAClzdK/6l3AHKigycSNIGeQL H+vUSXjevHlSM5F9kwsx6BimlkxLcZySjsmFTlcbRUAE0k2gc4u8Pm1r35u3a4iftDL/pEeKT3us ZMpKrzz53QdF67bns/fdK7MKDnmgSasmtZ9dtuPIXnuLIH/VLSutHX/ljr+eWpm/u5D/zi9gaXcy r8X2V3JeQ/vKuNXq1KkTX1l8i5rBNoNbkF7M5PLJ+jBOvq6O6du3b9Y3WQ0UAREQgYYhcP4+1VhH TuxXN7nDCweuOKD69MGVxXubLz5dnP+XTwqfO6/ylveLHhhXeMvxVdccXL1bhyRYzaN67ZlO+vek wnPT/E5sU8tGkDKuJzMbh1APluAaNcNg1rp16wT5xT7NLTF2Kh1pUALoGPrdFMkmitIxDUpfhYmA CGQ7AaTM7z8oWr4pr2urvF6ta/nnaTE7vlz6UvFJ/Wtufr9o7da8975TsX83bxrPKXG+mnGWodym oeg35hTedlLdnr/p/uyt0NJdWrT8UTPdu3fnCO800ExTNEJZGMcmeFbHYIrr169fFjZSTRIBERCB xiPQoXneOcOrb/80psHiJ28VzVubz554fdvWsi1eMjomaiv/OqaIClCNBvg0vpShkV26dHHVzIYN Gxqg5SkpAh1qPynJMIWZ2IqlKZBwVdExvJrAnI4Rrn///glnpRNFIMwE0vTTs9mGue2qWxgI/PSI KuaY5q+PMmXEOyMfGl/YvCTvr6dWPXp2pdkXOLE64ybMJjSeD4X+e3LRTw6v9MSn6WsopAxtQ810 69aNAOapuXPnbty4MU0NVraNS2D16tVWx5SWlg4Y4Hvfg8att0oXAREQgUwjgL/t9YdWXfe61zDD OyOveqV4aKfaDy+tuGRkssuLFm3IP/mREo+aYePg6w6tagCHX9MnYZEy1KZr165SM5n2SwlWX+wx 7I5ozkHHDBw4MNj5Si0CIiACIhCEwDWHVK/YnP+vCbtWR5tTv/9q8akDqj+6tGJYxz2uLUFy3Svt jUdXnT205ub/7hFMj0wsXM7C7IOr9kqXzi97yk5nKX7zRs1glWGBLn4z2GaYemjVqpXfk5Uu3AQ8 9hjpmHB3l2onAiKQDQRYsvTY1ytPeLhkZJeaEV3qhMtLMwr+v727CY3iDAM4ntlNNmKCmJDoQSsR ohtTQ0vFgxpaT7YQG8GDigiChd7VQC6ircceCoK91ZuitPTUixBoayhtQVBUioqg8Qs/ISKYmHV3 po+Zsnl3Mu/MbOZz9b+n2fl43uf9TWCevDP7zs7+yq4P535nFL6fRz4ty9x69ufKY+Poby1j+2cc v5YK34pHhAyNythZysCM3GySZalmpqenPVJnU2MJVB+BkvKUOqaxzh3ZIoBA4wr0dloyk++unwvy wkj5yIuWXOuYBy+bZLpe38+1p8ZP/7pUDs2z6+RmkzR0cqgU/PVPvi3qdqg+NCYLLgnpDktsvTwC bD8IbE88k1i7NBSrgIyxyU2l9vb2YrEYa0MERwABBBBQBbavNQ9vLstMvvI0brfmJ0Vfnin8dd/l AWE1jixLyTI61lIdg1G3SnBpQhqS5tT1CSxnsZSRbtvVTAL9p4kkBWQwpq+vL8kWaQsBBBBAQAS+ 3lAZ2VKRO02XH7nUK+N33xYDg6ucwzKLjrc69NZ1WWs6TblL5VgvYSW41DHSkGNTAl99npWRcZtq EurUN9WVLCCAAAIIIIBA9gW++qTS3WbtOFs4trUsy2rCMp3doc1Bn9L9blu5Y1FN0fPjpfw3vzf/ MPRmuFgTVm0i1mWfUibWtt+B4HZ5pxZ870Cn6AICCCAQicDrozORxCFIVALDRbO/u7Tvl5Zfb+a+ /6Isk+PZkXevr+OW0Mezjw/bB96eNA6elzmFjbH9JRmwUSb7rUlZt6Heq6duf+cYUU3js7O8SAb2 x7GJrwgggAACCCDQWALyFPD4gdKmD8zBU4XRsbdvNvD4eBSjcqAcLkE2rTTld91Sx3jEiXuTwa+E whPr6sTwkcNEyGZWYXrEsZkVaP22kHBuM8dKCbeYwebkn8wMZkVKjSLw8GXTiX+aT1/Nf95r7vuo srXHzM89UaLtRMVq+mMid/pK/vytnLwqcmRLeeWSuZ3D/016X7l0W42pqf8nHNbtMZcjSxqBbNJl MysNIasbW4BSJpXzF/6ykUraNJopAZn5V15ucO5afuKFMbjKlNGadd3W6g5rWZvVPvsfirx18ukr 486kcf2Z8ff93J/3cj1LrT0Dlb0DLu9XCv836X3l0m11KWXUXcOnlalzFlMyqlhMTRAWAQQQQACB +ASevGq6MJG7+DB347kxMWk8nzKkiJGPFDRdi62eDquvy9q4wvysx1zeVncW9dYSQa6q6j4uN5jU zfU2X3f/GvwA1arBu0L6CCCAAAIIxCIQppbQXWfV9fyCKZbTRlAEEEAAAQQQsAXUsiNMWaPzpJTR ydSsV09DzQa+IIAAAggggECqApQyPvwUMT5AbEYAAQQQQCCwgH1VDT82o0bwmVcmcG7siAACCCCA AAIIpCDAqEwNOmMwNRx8QQABBBBAIAaBqMZm7NQYlYnhFBESAQQQQAABBJIScBmVUe8/JZVG0HbU UZMs5xm0P+yHAAIIIIDA+yog1/RILuWMyryvf0H0GwEEEEAAgWwLqOMXHplSynjgsAkBBBBAAAEE 0hEIWMdIcpQy6ZwhWkUAAQQQQAABnUDwOkYiuDwro8ZVY0VyQ0sNvoDlLOSwgLQ5BAEEEEAAAQQc Arprulp7OA5x/doc/ADZU9eqa2hWIoAAAggggAACcQvUd4MpeN0Td97ERwABBBBAAAEERMDnBtN8 I8Zm5puwBgEEEEAAAQSiEnDcAvIdRqm7lJFEHUEdTUbVk1Ti6Pri6HIqudEoAggggAACCMwXWEgp Mz9KwmvUwkJXfCScEs0hgAACCCCAQOQC6hVfFzzlUiZIirrUWY8AAggggAACCKRcyoQ/AXYxxNhM eEkiIIAAAgggkB2B4IMd/wFhnqikGtd6qQAAAABJRU5ErkJggg== --001a1145784aebf3850529c5cd5a-- From nobody Wed Jan 20 09:45:25 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80901ABD8F for ; Wed, 20 Jan 2016 09:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbFJGR5Wlt6X for ; Wed, 20 Jan 2016 09:45:21 -0800 (PST) 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 6A5881A897B for ; Wed, 20 Jan 2016 09:45:21 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id x1so5990428qkc.1 for ; Wed, 20 Jan 2016 09:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=2e1u3opAGV/zqTdn1Uk5sOp9ttiisO4qda+4JMFBQa8=; b=WgcHvm6AwBM3Kf4+JXEa+54hwLueIIriDbGE6dHQScN/PDyqOXQjf5mj8PgIJ3qzMt BgZBcMVj+g83L3qxk21AmQyuDqb4N6XhDHKxFT/clIuQt7576b4TfupPrxmDqzWOXSSw AfeIoLQOvNHg1jjsBbNyQhCXc4QYs7AdpqIgV96stcJmTIPHz71ACWf59jLFWNyvCUAJ EOxBRFz5EVTzTtOMhd+OTsc0yj5RjSEh/blzL9jIkl+6qdhLyyo/J/yYow4brc78Qjy8 DlTgiPmDvVAeUBe0dYI9I2Z91PR+L3bZ5u2LT6BbBEkkqtkf4ms32Lh30RHcp1eKP1FU yPtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=2e1u3opAGV/zqTdn1Uk5sOp9ttiisO4qda+4JMFBQa8=; b=BQ0fmGjKmWIvrWj3ykNckvnlV+Cg4zOcr+wpnR6XCrkrFxoaYeC6TOLZF31F4Dl0dO LKTr9pqmDkHO00cHi2cfQ2EYbjxA4FqUHXcGV32pCvPN8m9QV6uIlDx1jeJD5AvxiU0r gJX1YKjywhOLv+A5PmSkAD+/x/UJRIEnFZoyCLX1F8x/QKCe8WrnQmJeDOEXcqzeNTha IlbJCN6rMQ+z7Inu5e6KjYlHnMUOyplkSL5aH+Os0cQJFdB0o09XiPfp8sz0niH5TZln LacmmQPUV/XGm+yBdWUMlSP01ZNRljxFDw5ZFYgdZ3lWRTH/kwFGUf/NoYPpo/Udo2mE wUfw== X-Gm-Message-State: ALoCoQk6XY7dcgBGGIdQ2wGid08K/GrTU0S7/M4/nnXKlDMq0W0YMhwhTA2tXRfjGvc//s2eaTpl8rXHmxx7riLXqLU94S94Ig== X-Received: by 10.55.207.152 with SMTP id v24mr46692033qkl.100.1453311920347; Wed, 20 Jan 2016 09:45:20 -0800 (PST) Received: from [192.168.8.101] ([181.202.164.7]) by smtp.gmail.com with ESMTPSA id b34sm14669708qgb.31.2016.01.20.09.45.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 09:45:19 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_E64773AA-4EED-42F4-9F1B-0E64C171B073"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Wed, 20 Jan 2016 14:45:15 -0300 Message-Id: <6ADAA1B5-7EF9-49EA-A3D9-6EFC57275EB9@ve7jtb.com> References: <569E2231.1010107@gmx.net> To: Aaron Parecki X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 17:45:24 -0000 --Apple-Mail=_E64773AA-4EED-42F4-9F1B-0E64C171B073 Content-Type: multipart/alternative; boundary="Apple-Mail=_D86BDBF1-9F02-4FAD-A7C2-2E96CFBA6A5F" --Apple-Mail=_D86BDBF1-9F02-4FAD-A7C2-2E96CFBA6A5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes, in July we recommended using the system browser rather than = WebViews. =20 About that time Apple announced Safari view controller and Google Chrome = custom tabs. The code in the OS is now stable and we have done a fair = amount of testing. The OIDF will shortly be publishing reference libraries for iOS and = Android to how how to best use View Controllers, and PKCE in native apps = on those platforms. We do need to update this doc to reflect what we have learned in the = last 6 months. One problem we do still have is not having someone with Win 10 mobile = experience to help document the best practices for that platform.=20 I don=E2=80=99t understand that platform well enough yet to include = anything. John B. > On Jan 20, 2016, at 12:40 PM, Aaron Parecki wrote: >=20 > The section on embedded web views doesn't mention the new iOS 9 = SFSafariViewController which allows apps to display a system browser = within the application. The new API doesn't give the calling application = access to anything inside the browser, so it is acceptable for using = with OAuth flows. I think it's important to mention this new capability = for apps to leverage since it leads to a better user experience. >=20 > I'm sure that can be addressed in the coming months if this document = is just the starting point. >=20 > I definitely agree that a document about native apps is necessary = since the core leaves a lot of guessing room for an implementation. >=20 > For reference, = https://developer.apple.com/library/prerelease/ios/releasenotes/General/Wh= atsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElem= entID_26 = >=20 > And see the attached screenshot for an example of what it looks like. >=20 > >=20 > ---- > Aaron Parecki > aaronparecki.com > @aaronpk >=20 >=20 > On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig = > wrote: > Hi all, >=20 > this is the call for adoption of OAuth 2.0 for Native Apps, see > http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ = >=20 > Please let us know by Feb 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. >=20 > Note: If you already stated your opinion at the IETF meeting in = Yokohama > then you don't need to re-state your opinion, if you want. >=20 > The feedback at the Yokohama IETF meeting was the following: 16 = persons > for doing the work / 0 persons against / 2 persons need more info >=20 > Ciao > Hannes & Derek >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_D86BDBF1-9F02-4FAD-A7C2-2E96CFBA6A5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes, in July we recommended using the system browser rather = than WebViews.   

About that time Apple announced Safari view controller and = Google Chrome custom tabs.   The code in the OS is now stable and = we have done a fair amount of testing.

The OIDF will shortly be publishing = reference libraries for iOS and Android to how how to best use View = Controllers, and PKCE in native apps on those platforms.

We do need to update = this doc to reflect what we have learned in the last 6 months.

One problem we do still = have is not having someone with Win 10 mobile experience to help = document the best practices for that platform. 
I don=E2=80=99t understand that platform well enough yet to = include anything.

John B.

On = Jan 20, 2016, at 12:40 PM, Aaron Parecki <aaron@parecki.com> = wrote:

The section on embedded web views doesn't mention = the new iOS 9 SFSafariViewController which allows apps to display a = system browser within the application. The new API doesn't give the = calling application access to anything inside the browser, so it is = acceptable for using with OAuth flows. I think it's important to mention = this new capability for apps to leverage since it leads to a better user = experience.

I'm sure = that can be addressed in the coming months if this document is just the = starting point.

I definitely agree that a document about native apps is = necessary since the core leaves a lot of guessing room for an = implementation.

For reference, https://developer.apple.com/library/prerelease/ios/releasenotes= /General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-D= ontLinkElementID_26

And see the attached screenshot for an example of what it = looks like.

<embedded-oauth-view.png>

----
Aaron Parecki
aaronparecki.com
@aaronpk


On Tue, Jan 19, 2016 at 3:46 = AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see
http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-app= s/

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

Note: If you already stated your opinion at the IETF meeting in = Yokohama
then you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 16 = persons
for doing the work / 0 persons against / 2 persons need more info

Ciao
Hannes & Derek


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


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

= --Apple-Mail=_D86BDBF1-9F02-4FAD-A7C2-2E96CFBA6A5F-- --Apple-Mail=_E64773AA-4EED-42F4-9F1B-0E64C171B073 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMjAxNzQ1MTVaMCMGCSqGSIb3DQEJBDEWBBRj0iieDvykWcyOVboHjKnd JW1K+DCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCf4Bwn/JG9OEUbTg/xjMQEso6STlRlLqRFYX1WkrUiQl0HpxrX+XMA ZnL18ffkKKcBKXYQk00Qtd3RXB2QRjsw4vHVayitgRGtNOESCzsdzzhuQ/Y7tr39bY8CAncPZnHf bEanqxPRroePlawRd+wMw7Wf5X2oCgyBl1fGKJtpihcdGGjIv+RrQFQM7V+JTYVtHoD7ZaEJNPR0 qVBO3/YyXODKlq7qPOPsXXWwENLGHLuoPuSNUiiLORG5Fe4/IbCr3bxA9F5M5XJm01tDmyeDr+m3 sEtyqlsBf3apEVm6FHH7rijNySPjnaV86AzpqJPLvd/v7p5c2A0Gr76gEL+7AAAAAAAA --Apple-Mail=_E64773AA-4EED-42F4-9F1B-0E64C171B073-- From nobody Wed Jan 20 10:18:58 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6E01A90CE for ; Tue, 12 Jan 2016 23:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKXzVdoTRd33 for ; Tue, 12 Jan 2016 23:52:30 -0800 (PST) Received: from smtp5.umu.se (smtp5.umu.se [130.239.8.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1971A009F for ; Tue, 12 Jan 2016 23:52:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,288,1449529200"; d="asc'?scan'208";a="84011055" X-IPAS-Result: A2DEBADKAJZW/84N74JeGQEBAQEPAQEBAYJffW0GiFO1EAIFGAqEPYEwAoF1AQEBAQEBgQuENAEBAQECAQEBASBLCwULAgEIEQQBAQEVFQICJwsdCAIEDgUOBgeICwgBDa8nkEABAQEBAQEBAQIBAQEBAQEBAQERBQSGVoIPgnCEPh85gl4ugRsFlxWCdIFlmAFcjXhkhApyhFECBRkHHAGBBwEBAQ Received: from umu-ex06.ad.umu.se (HELO mail.ad.umu.se) ([130.239.13.206]) by smtp5.umu.se with ESMTP; 13 Jan 2016 08:52:27 +0100 Received: from UMU-EX03.ad.umu.se (2002:82ef:dcb::82ef:dcb) by UMU-EX06.ad.umu.se (2002:82ef:dce::82ef:dce) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 13 Jan 2016 08:52:27 +0100 Received: from UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133]) by UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133%24]) with mapi id 15.00.1130.005; Wed, 13 Jan 2016 08:52:27 +0100 From: Roland Hedberg To: "Phil Hunt (IDM)" Thread-Topic: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation Thread-Index: AQHRTddYbQlj7Sd67kSeSjTNrc+QQg== Date: Wed, 13 Jan 2016 07:52:26 +0000 Message-ID: References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> In-Reply-To: <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.5.2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.239.200.165] Content-Type: multipart/signed; boundary="Apple-Mail=_A44ECF01-67F5-493C-86B1-474262DFF6D2"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Wed, 20 Jan 2016 10:18:56 -0800 Cc: "" Subject: Re: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2016 07:52:34 -0000 --Apple-Mail=_A44ECF01-67F5-493C-86B1-474262DFF6D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 And I agree with Phil=E2=80=99s agreement with Brian :-) I should also add that I during the last part of the meeting and on my = flight home afterwards implemented the techniques I felt we had come to = an agreement on at the meeting. That is the new authorization request = response parameters iss and client_id as well as the use of state_hash = at the token endpoint. > 13 jan 2016 kl. 05:31 skrev Phil Hunt (IDM) : >=20 > I am in agreement with Brian. >=20 > I understand what Mike is trying to do is safer, but I too am = concerned that the escalation in knowledge/skills for oauth clients is = significant. >=20 > This may not be the same concern as for OIDC where we can expect more = sophistication. >=20 > Phil >=20 > On Jan 12, 2016, at 20:03, Justin Richer wrote: >=20 >> +1 to Brian=E2=80=99s point, and points to Mike for promising to = address this. I wasn=E2=80=99t able to attend the meeting in Darmstadt, = but I=E2=80=99ve been following the discussion and original papers. = Let=E2=80=99s take this one piece at a time and not overreach with a = solution. >>=20 >> In particular, the whole =E2=80=9Clate binding discovery=E2=80=9D bit = would cause huge problems on its own. There=E2=80=99s good reason that = OpenID Connect mandates that the =E2=80=9Ciss=E2=80=9D value returned = from the discovery endpoint MUST be the same as the =E2=80=9Ciss=E2=80=9D = value coming back from the ID Token, so let=E2=80=99s not ignore that. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jan 12, 2016, at 5:53 PM, Mike Jones = wrote: >>>=20 >>> John Bradley and I went over this today and I'm already planning on = simplifying the draft along the lines described. I would have written = this earlier but I've been busy at a NIST meeting today. >>>=20 >>> John has also stated writing a note about how cut-and-paste does and = doesn't apply here but hasn't finished it yet because he's been = similarly occupied. He's also started writing up the state_hash token = request parameter, as he agreed to do. >>>=20 >>> Watch this space for the new draft... >>>=20 >>> Best wishes, >>> -- Mike >>> From: Brian Campbell >>> Sent: =E2=80=8E1/=E2=80=8E12/=E2=80=8E2016 5:24 PM >>> To: oauth >>> Subject: [OAUTH-WG] Mix-Up About The Mix-Up Mitigation >>>=20 >>> The "IdP Mix-Up" and "Malicious Endpoint" attacks (as well as = variations on them) take advantage of the fact that there's nothing in = the OAuth authorization response to the client's redirect_uri that = identifies the authorization server. As a result, a variety of = techniques can be used to trick the client into sending the code (or = token in some cases) to the wrong endpoint. >>>=20 >>> To the best of my recollection the general consensus coming out of = the meetings in Darmstadt (which Hannes mentioned in OAuth Security = Advisory: Authorization Server Mix-Up) was to put forth an I-D as a = simple extension to OAuth, which described how to return an issuer = identifier for the authorization server and client identifier as = authorization response parameters from the authorization endpoint. Doing = so enables the client to know which AS the response came from and thus = avoid sending the code to a different AS. Also, it doesn't introduce = application/message level cryptography requirements on client = implementations. >>>=20 >>> The mitigation draft that was posted yesterday diverges considerably = from that with a significantly expanded scope that introduces OpenID = Connect ID Tokens (sort of anyway) to regular OAuth and the retrieval of = a metadata/discovery document in-between the authorization request and = the access token request. >>>=20 >>> It is possible that my recollection from Darmstadt is wrong. But I = expect others who were there could corroborate my account of what = transpired. Of course, the agreements out of the Darmstadt meeting were = never intended to be the final word - the whole WG would have the = opportunity to weigh, as is now the case. However, a goal of meeting = face-to-face was to come away with a good consensus towards a proposed = solution that could (hopefully) be implementable in the very near term = and move thought the IETF process in an expedited manner. I believe we'd = reached consensus but the content of -00 draft does not reflect it. >>>=20 >>> I've made the plea off-list several times to simplify the draft to = reflect the simple solution and now I'm doing the same on-list. Simplify = the response validation to just say not to send the code/token back to = an AS entity other that the one identified by the 'iss' in the response. = And remove the id_token and JWT parts that . >>>=20 >>> If this WG and/or the larger community believes that OAuth needs = signed responses, let's develop a proper singed response mechanism. I = don't know if it's needed or not but I do know that it's a decent chunk = of work that should be conscientiously undertaken independent of what = can and should be a simple to understand and implement fix for the idp = mix-up problem. >>>=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=_A44ECF01-67F5-493C-86B1-474262DFF6D2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWlgI6AAoJEMHjX+0KUIOoJK0QALi/muvrHBeDcEyU4tViNuGG 0GG71dEKN3pajFxVVk5B7qNvSDX0ougNT8wypYXHn8Th/++lQWDZimuXq5s5WCBi 5C1ckUG2DpO+GS2VdiTL86s5Hyd/TLrs6/uBFYE3mZWZUc/rg3fjY8Tgtdqw+prk tZNDio9RRXLjRGb6fKWdBOPvYmGQj8BHVqjPllmyy3TpRdguXQT4r3tFcJ/jDX8k UV2B1V1DrzuEfs3cYhSQbfDKNS3A8H7D+S6lVdwt08YG7QbD9Zdtj+EdIcXE+Ah5 WEtdqZtUr33BKXbN5VyONMfA0uDvTHLYdkGQHrXaM4i52ZwmleAWOJMVPL8cZW1T ER18lY0g2Q9OeMFd/yixCkKwuXCiM19XcxwURU1x0gG6R8J50ehkvtxo2erSZ/mQ H/zAESHU01KQn3U7nDN1xPkqF0ucNeF2aEb8AGqqD/IltqyMmfxfP1vsdxltS44c Gsu7raED+YITuR1rk7w7fromvUTATpiGw6a0dLEZWZ2/eO5xHMuvopoYO2hiyWyI VU2Gqpm1nl5VMgzB50GxLvZDfhbajswopmPOHhFdZluHEUC6eBPWK/rrFjyHWAiD 1cztlEvGrvLN06hVT+HE3k/D934A4JzLEeHn+csy06zno+u3tPtQlnY9X2D4iN09 4OXt/LSb8Lpw819OwP09 =Qi3K -----END PGP SIGNATURE----- --Apple-Mail=_A44ECF01-67F5-493C-86B1-474262DFF6D2-- From nobody Wed Jan 20 10:19:26 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 819321ACCF9; Fri, 15 Jan 2016 03:05:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160115110553.16457.79703.idtracker@ietfa.amsl.com> Date: Fri, 15 Jan 2016 03:05:53 -0800 Archived-At: X-Mailman-Approved-At: Wed, 20 Jan 2016 10:19:25 -0800 Cc: oauth-chairs@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] oauth - New Meeting Session Request for IETF 95 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2016 11:05:53 -0000 A new meeting session request has just been submitted by Hannes Tschofenig, a Chair of the oauth working group. --------------------------------------------------------- Working Group Name: Web Authorization Protocol Area Name: Security Area Session Requester: Hannes Tschofenig Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: ace saag cfrg tls core lwig Special Requests: Please avoid conflict with sec area BoFs. --------------------------------------------------------- From nobody Wed Jan 20 10:39:24 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5CD1ACC92 for ; Wed, 20 Jan 2016 10:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7QEWXyFU1v4 for ; Wed, 20 Jan 2016 10:39:21 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9591ACC91 for ; Wed, 20 Jan 2016 10:39:20 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id ik10so106932965igb.1 for ; Wed, 20 Jan 2016 10:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aw8ECSlN7ARJnI0cxvSRJR4mJPRiOXOWTBQXQchobFc=; b=QdMoT/rRR9BsC5wDpjENae+I4brh1/Lf0K0+wd22FT51+1b88/nZrPH1H+DyckXUvR wv5hT6/snS99TeHomSpC6iJItM+Uzj8z/KDcH7gKA084U3g5mwBth75TjA88+Vcj5EzC Vn0GtG9zNZovPd5nEv7T9469hiRuZK16H1YqY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aw8ECSlN7ARJnI0cxvSRJR4mJPRiOXOWTBQXQchobFc=; b=f/emrxHH1AkRFEmnlaxZ26gkAlE5QEo9cgjXIzNRYMkqsIEC8Tu2NlOmMN7pPKBSEs 0ytUYGskIUPMlKZX2kQiHpiJuity56IkMaUdlFi8pZ7hhXNXigGuS/gfH45KzoWhI0Fn KtKHFacF/K7HGPsoXpGp2GDGjt3WAJWCvQIM1NI0av2d6rQ9r1gW7ytEHtx+cQ/kcH3T 6yDSPS/rnq67iPzYY8p70wsA68RZq7wFBrGdwlMPQKz/OraV7bPrj7wjyvHMPkrNmlA4 zOedmdTIBn5BXLybwbc18hehLen4J3XMJCzEGlIs1tI+WMOwgezUJy2sFP2UxQZ+8HhI KBcg== X-Gm-Message-State: AG10YOQF8uY4IdpR5yVYMUvdBtOmh8JB5WASkOL1Gt3lNlHn5WVnA+vM5/o1iiGQSZ6xNPkaFEVAbuYUvcfiWoOa X-Received: by 10.50.13.102 with SMTP id g6mr5388608igc.77.1453315160079; Wed, 20 Jan 2016 10:39:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.212.69 with HTTP; Wed, 20 Jan 2016 10:38:50 -0800 (PST) In-Reply-To: <6ADAA1B5-7EF9-49EA-A3D9-6EFC57275EB9@ve7jtb.com> References: <569E2231.1010107@gmx.net> <6ADAA1B5-7EF9-49EA-A3D9-6EFC57275EB9@ve7jtb.com> From: Brian Campbell Date: Wed, 20 Jan 2016 11:38:50 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=089e013c66d6dd1e860529c84db2 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 18:39:23 -0000 --089e013c66d6dd1e860529c84db2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#appendix-A which has some mention of SFSafariViewController and Chrome Custom Tabs. Maybe more is needed? On Wed, Jan 20, 2016 at 10:45 AM, John Bradley wrote: > Yes, in July we recommended using the system browser rather than WebViews= . > > > About that time Apple announced Safari view controller and Google Chrome > custom tabs. The code in the OS is now stable and we have done a fair > amount of testing. > > The OIDF will shortly be publishing reference libraries for iOS and > Android to how how to best use View Controllers, and PKCE in native apps = on > those platforms. > > We do need to update this doc to reflect what we have learned in the last > 6 months. > > One problem we do still have is not having someone with Win 10 mobile > experience to help document the best practices for that platform. > I don=E2=80=99t understand that platform well enough yet to include anyth= ing. > > John B. > > On Jan 20, 2016, at 12:40 PM, Aaron Parecki wrote: > > The section on embedded web views doesn't mention the new iOS 9 > SFSafariViewController which allows apps to display a system browser with= in > the application. The new API doesn't give the calling application access = to > anything inside the browser, so it is acceptable for using with OAuth > flows. I think it's important to mention this new capability for apps to > leverage since it leads to a better user experience. > > I'm sure that can be addressed in the coming months if this document is > just the starting point. > > I definitely agree that a document about native apps is necessary since > the core leaves a lot of guessing room for an implementation. > > For reference, > https://developer.apple.com/library/prerelease/ios/releasenotes/General/W= hatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElem= entID_26 > > And see the attached screenshot for an example of what it looks like. > > > > ---- > Aaron Parecki > aaronparecki.com > @aaronpk > > > On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> Hi all, >> >> this is the call for adoption of OAuth 2.0 for Native Apps, see >> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ >> >> Please let us know by Feb 2nd whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >> >> Note: If you already stated your opinion at the IETF meeting in Yokohama >> then you don't need to re-state your opinion, if you want. >> >> The feedback at the Yokohama IETF meeting was the following: 16 persons >> for doing the work / 0 persons against / 2 persons need more info >> >> Ciao >> Hannes & Derek >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e013c66d6dd1e860529c84db2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There is=20 https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00= #appendix-A which has some mention of SFSafariViewController and Chrome Custom=20 Tabs.

Maybe more is needed?

On Wed, Jan 20, 2016 at 10:45 AM, John Br= adley <ve7jtb@ve7jtb.com> wrote:
Yes, in July we recommended usin= g the system browser rather than WebViews. =C2=A0=C2=A0

= About that time Apple announced Safari view controller and Google Chrome cu= stom tabs. =C2=A0 The code in the OS is now stable and we have done a fair = amount of testing.

The OIDF will shortly be publis= hing reference libraries for iOS and Android to how how to best use View Co= ntrollers, and PKCE in native apps on those platforms.

=
We do need to update this doc to reflect what we have learned in the l= ast 6 months.

One problem we do still have is not = having someone with Win 10 mobile experience to help document the best prac= tices for that platform.=C2=A0
I don=E2=80=99t understand that pl= atform well enough yet to include anything.

John B= .

=
On Jan 20, 2016, at 12:40 PM, Aaron Parecki <aaron@parecki.com> wrote:

=
The section on embedded web v= iews doesn't mention the new iOS 9 SFSafariViewController which allows = apps to display a system browser within the application. The new API doesn&= #39;t give the calling application access to anything inside the browser, s= o it is acceptable for using with OAuth flows. I think it's important t= o mention this new capability for apps to leverage since it leads to a bett= er user experience.

I'm sure that can be addressed i= n the coming months if this document is just the starting point.
=
I definitely agree that a document a= bout native apps is necessary since the core leaves a lot of guessing room = for an implementation.


And see the atta= ched screenshot for an example of what it looks like.

<= /span>
<embedded-oauth-view.png>

=
----
Aaron Parecki

=

On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tsch= ofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see
http://datatracker.ietf.org/doc/dra= ft-wdenniss-oauth-native-apps/

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

Note: If you already stated your opinion at the IETF meeting in Yokohama then you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 16 persons
for doing the work / 0 persons against / 2 persons need more info

Ciao
Hannes & Derek


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


_______________________________________________
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


--089e013c66d6dd1e860529c84db2-- From nobody Wed Jan 20 10:40:41 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C441ACCDE for ; Wed, 20 Jan 2016 10:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJJ0uLK0okSQ for ; Wed, 20 Jan 2016 10:40:38 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7C71ACC8F for ; Wed, 20 Jan 2016 10:40:38 -0800 (PST) Received: by mail-ig0-x234.google.com with SMTP id z14so107034592igp.0 for ; Wed, 20 Jan 2016 10:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=B3HMTAMMyxYcWf36XKT3olOMz+q2XWRFOOuI9baJeko=; b=StYB2K4jcP/7MHil463dD5J9ja19hEB9SNPMoDc8fbfIalVEB0bnMcib1phmkwn+gU ej65ym41nqpRZyvNg51u0Q6oxdkwtntGt3DHxftkYd3ZYJAhvCSqY0TpHu3et+hPxJra kJ7qWhyxCqp+/De8LEL3OzEn8LOgzvF4wu+QQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=B3HMTAMMyxYcWf36XKT3olOMz+q2XWRFOOuI9baJeko=; b=MOqEumfCrMcbaMZmnH0OU3b67yR+vYdmVqoQIpRXOkfDt//Xxz0vJlom/Zd3drN+OR o0nzapAoCVBMnBcRHTy3rUUhgiqUq1X4Id8dpz8EejBnHnUprWUUO43zwEXxyfTsjygd i0KgZliePEK/Y7bMvA1L6fHHg1TfX1ksIj1HZZ6SO7M74tOUdjNziFuc72LRq5iJ8VBT t9uHmJg7jUh1JrzoPQPAinMa+rnq/SdxtBwdj/z+3bUVe5ODLl0daHwlHMybXK8f72qD LlolS0GqKVi/HcMnJ9I4pDzFqQje8Smv+A5q4yc9kB7sFZUBCN/Di4BDw7p+Mpql4FKd UE2g== X-Gm-Message-State: AG10YOTzj7Y7aQxaCc9I9p8VGUWeP48yylqLJPLaRTgtwAOd0EQUYQvkzQIwz5yy69jcW474LPFlwJcIiV8Zmziz X-Received: by 10.50.4.3 with SMTP id g3mr5220579igg.49.1453315237892; Wed, 20 Jan 2016 10:40:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.212.69 with HTTP; Wed, 20 Jan 2016 10:40:08 -0800 (PST) In-Reply-To: <569E2231.1010107@gmx.net> References: <569E2231.1010107@gmx.net> From: Brian Campbell Date: Wed, 20 Jan 2016 11:40:08 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c3bd188075210529c8520a Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 18:40:40 -0000 --001a11c3bd188075210529c8520a Content-Type: text/plain; charset=UTF-8 +1 for doing the work (I was remote for Yokohama so not sure if my feedback was previously counted in that 16). On Tue, Jan 19, 2016 at 4:46 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > this is the call for adoption of OAuth 2.0 for Native Apps, see > http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ > > Please let us know by Feb 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Note: If you already stated your opinion at the IETF meeting in Yokohama > then you don't need to re-state your opinion, if you want. > > The feedback at the Yokohama IETF meeting was the following: 16 persons > for doing the work / 0 persons against / 2 persons need more info > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11c3bd188075210529c8520a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for doing the work (I was remote for Yokohama so not su= re if my feedback was previously counted in that 16).

On Tue, Jan 19, 2016 at 4:4= 6 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> = wrote:
Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see
http://datatracker.ietf.org/doc/dra= ft-wdenniss-oauth-native-apps/

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

Note: If you already stated your opinion at the IETF meeting in Yokohama then you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 16 persons
for doing the work / 0 persons against / 2 persons need more info

Ciao
Hannes & Derek


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


--001a11c3bd188075210529c8520a-- From nobody Wed Jan 20 11:41:29 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7A51ACDCE for ; Wed, 20 Jan 2016 11:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZLS7mEXoHsu for ; Wed, 20 Jan 2016 11:41:14 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFD51A90B6 for ; Wed, 20 Jan 2016 11:41:13 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id s68so7359738qkh.3 for ; Wed, 20 Jan 2016 11:41:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=iqzCz9a6vzo+WCsEmkF76qcQatvYJNH1dEVALSd2vCM=; b=Ry0WyIxq7YwD6y8NIPDdJaMpzYfsEWFwQflrFH7uksmveVe2hD/tLAuyrB0SQ8IISk JkXo8B+jEleBfMiv7jGbIImPwsNLgi2nI1imEDUsSD0kCmACOICGb1lOtRwnBJbFZ52s lAMefqBtjvs8gQLIPiVTi6haegLI2NYJClq4u/8uO9VRb6oVV1w6ugeMDSqYUyV+ce2b kESOmNSfv5or2Yr3iTLXTO+/afWU3K+Cmp4N1wc45N9ML32/w6jDb5LH5L/hAmf2dHCq i2AvD6IpZ5vCz8XwdpJ1T1I+hx1i0tHQW4FVCUe5Lw1p8zb6j+PMiLj5W6pzDclkivHz Y+dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=iqzCz9a6vzo+WCsEmkF76qcQatvYJNH1dEVALSd2vCM=; b=YKdHOHMSibeoIGRamgA3udsE0nbf+NBI0IgDK2uwAslxK46cyodBjmBQUHSTFwqDFP oeVVhvMuTCGXm2jDcoK+2ZigEm0KwVL3JUl3H7RNg/zYxTkAAgScPPbR2Lhg0jrPxg2o kY5DqTDaFJdFQYcUQ5+yk2K65s7Qp+avrACgPv7BeOv6hruE+HFUz7zMUiFZjhDMYYZ5 mxYcvgu4KPqghvAPT6btxn120vvIQGXHeT5DE7jY6dUpbhWRTVh/+br8z5vVjdmVv3Yr sRJ8avK1OAWSvV1cTKXM9GZ3vwtr1xifKIzc2pp5KZA0LaCEcjO8Kou5B3YbTvBiY1VZ aLtg== X-Gm-Message-State: AG10YOQzuudnwFR9Vh3cb5+iL6NLQhL3FtUpXPvn4TPGSv8oGscnOOVEKNa/QK6bvfvxnA== X-Received: by 10.55.72.207 with SMTP id v198mr11278785qka.65.1453318872883; Wed, 20 Jan 2016 11:41:12 -0800 (PST) Received: from [192.168.8.101] ([181.202.164.7]) by smtp.gmail.com with ESMTPSA id h206sm14807734qhh.8.2016.01.20.11.41.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 11:41:11 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_1F34A277-F31C-4258-AD23-6919C3370F4F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Wed, 20 Jan 2016 16:41:07 -0300 Message-Id: References: <569E2231.1010107@gmx.net> <6ADAA1B5-7EF9-49EA-A3D9-6EFC57275EB9@ve7jtb.com> To: Brian Campbell X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 19:41:20 -0000 --Apple-Mail=_1F34A277-F31C-4258-AD23-6919C3370F4F Content-Type: multipart/alternative; boundary="Apple-Mail=_36E346A3-1AF2-4C5C-BF6A-CD4F90219F8F" --Apple-Mail=_36E346A3-1AF2-4C5C-BF6A-CD4F90219F8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes more is needed. It was theoretical at that point. Now we have = implementation experience. > On Jan 20, 2016, at 3:38 PM, Brian Campbell = wrote: >=20 > There is = https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#appendix-A= = which has some mention of SFSafariViewController and Chrome Custom = Tabs.=20 >=20 > Maybe more is needed? >=20 > On Wed, Jan 20, 2016 at 10:45 AM, John Bradley > wrote: > Yes, in July we recommended using the system browser rather than = WebViews. =20 >=20 > About that time Apple announced Safari view controller and Google = Chrome custom tabs. The code in the OS is now stable and we have done = a fair amount of testing. >=20 > The OIDF will shortly be publishing reference libraries for iOS and = Android to how how to best use View Controllers, and PKCE in native apps = on those platforms. >=20 > We do need to update this doc to reflect what we have learned in the = last 6 months. >=20 > One problem we do still have is not having someone with Win 10 mobile = experience to help document the best practices for that platform.=20 > I don=E2=80=99t understand that platform well enough yet to include = anything. >=20 > John B. >=20 >> On Jan 20, 2016, at 12:40 PM, Aaron Parecki > wrote: >>=20 >> The section on embedded web views doesn't mention the new iOS 9 = SFSafariViewController which allows apps to display a system browser = within the application. The new API doesn't give the calling application = access to anything inside the browser, so it is acceptable for using = with OAuth flows. I think it's important to mention this new capability = for apps to leverage since it leads to a better user experience. >>=20 >> I'm sure that can be addressed in the coming months if this document = is just the starting point. >>=20 >> I definitely agree that a document about native apps is necessary = since the core leaves a lot of guessing room for an implementation. >>=20 >> For reference, = https://developer.apple.com/library/prerelease/ios/releasenotes/General/Wh= atsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElem= entID_26 = >>=20 >> And see the attached screenshot for an example of what it looks like. >>=20 >> >>=20 >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >>=20 >>=20 >> On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig = > wrote: >> Hi all, >>=20 >> this is the call for adoption of OAuth 2.0 for Native Apps, see >> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ = >>=20 >> Please let us know by Feb 2nd whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >>=20 >> Note: If you already stated your opinion at the IETF meeting in = Yokohama >> then you don't need to re-state your opinion, if you want. >>=20 >> The feedback at the Yokohama IETF meeting was the following: 16 = persons >> for doing the work / 0 persons against / 2 persons need more info >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 --Apple-Mail=_36E346A3-1AF2-4C5C-BF6A-CD4F90219F8F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes more is needed.   It was theoretical at that point. =  Now we have implementation experience.

On = Jan 20, 2016, at 3:38 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

There is=20 https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00= #appendix-A which has some mention of SFSafariViewController and Chrome Custom=20 Tabs.

Maybe more is needed?

On Wed, Jan 20, 2016 at 10:45 AM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
Yes, in July we recommended = using the system browser rather than WebViews.   

About that time Apple = announced Safari view controller and Google Chrome custom tabs.   = The code in the OS is now stable and we have done a fair amount of = testing.

The = OIDF will shortly be publishing reference libraries for iOS and Android = to how how to best use View Controllers, and PKCE in native apps on = those platforms.

We do need to update this doc to reflect what we have learned = in the last 6 months.

One problem we do still have is not having someone with Win = 10 mobile experience to help document the best practices for that = platform. 
I don=E2=80=99t understand that = platform well enough yet to include anything.

John B.

On Jan 20, 2016, at 12:40 = PM, Aaron Parecki <aaron@parecki.com> wrote:

The section on embedded web views doesn't mention the new iOS = 9 SFSafariViewController which allows apps to display a system browser = within the application. The new API doesn't give the calling application = access to anything inside the browser, so it is acceptable for using = with OAuth flows. I think it's important to mention this new capability = for apps to leverage since it leads to a better user experience.

I'm sure that can be = addressed in the coming months if this document is just the starting = point.

I definitely agree that a document about = native apps is necessary since the core leaves a lot of guessing room = for an implementation.

For reference, https://developer.apple.com/library/prerelease/ios/releasenotes= /General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-D= ontLinkElementID_26

And see the attached screenshot for an example of what it = looks like.

<embedded-oauth-view.png>

----
Aaron = Parecki
aaronparecki.com
@aaronpk


On Tue, Jan 19, 2016 at 3:46 = AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see
http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-app= s/

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

Note: If you already stated your opinion at the IETF meeting in = Yokohama
then you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 16 = persons
for doing the work / 0 persons against / 2 persons need more info

Ciao
Hannes & Derek


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


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


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



= --Apple-Mail=_36E346A3-1AF2-4C5C-BF6A-CD4F90219F8F-- --Apple-Mail=_1F34A277-F31C-4258-AD23-6919C3370F4F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMjAxOTQxMDhaMCMGCSqGSIb3DQEJBDEWBBQRcT74akXdi8iRSj7cXwxq pLWOITCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQA+qKXPne4nzj5bK1kkyIcDThB5UyuYDPXu0OuAbgoLfzR7TqUOWq47 0+vfqOH5dMl86R6OipnBbW6CO7hudtPhLkNvgN5/M1Ljlji2c1Y8ldXoE/phS4Z3HvL66hOj4HXd InxDRQ1T0dzQLw4dFq7X54rJfQqj3cGkV4u17cD5NiBanay+9nWqMXEfNhdhrDIGPW+v7UG9Xk1c PSCwJWZBBFYyzZAABjTWtCBT0VDbHwoW76IgtF/g9xQoiqHufiaTlje2+B11EVwtxmEyHg+B4M2f iv5KoA7fePgeOZpQMf7XUszG6uYabdGjrjJNdQREAmTpdDGNACL2AJnkmrm0AAAAAAAA --Apple-Mail=_1F34A277-F31C-4258-AD23-6919C3370F4F-- From nobody Wed Jan 20 11:59:14 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93E41A87C1 for ; Wed, 20 Jan 2016 11:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6LLLYF580qj for ; Wed, 20 Jan 2016 11:59:11 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 DEE861A02B1 for ; Wed, 20 Jan 2016 11:59:10 -0800 (PST) Received: by mail-qg0-x22e.google.com with SMTP id o11so15146871qge.2 for ; Wed, 20 Jan 2016 11:59:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=OSuiJGTL6Vg9iEVx3x6zOXbhzDfXz8VgQwYGU95Yycs=; b=S3vsDdt3+wY3J+RWx/2OLXQuYdTxmiE2/3WMFtRmafRIwkRJJorAK6brfxnX+yifDW kg/peIglnx2hGbz17TuCs21F3A7r26gj+ovovC0rIQPQyIN9AbTfYAs9qDXFn9Ga4u6f /CY/vs9WQ30OD7UC8OfM5/izPp/Vpp1bJ+tIIdBzE4mhNrKZRFMaJzH73rszq6cihmP6 0+r1kZrR+AUdGIVR8wf3ocDf2TdLdGZgSqJjM3dh5GgwM8nI1fNs3WLwp6J2LAvXShVq TeXQgXeD4RLJ+qCLAjTZtuQ5I6E9OhDtdmv6Bf6TI1XBvWm6xl2pni/YLeNK0MdYwZNk 9azw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=OSuiJGTL6Vg9iEVx3x6zOXbhzDfXz8VgQwYGU95Yycs=; b=IucalXBoUMUt1ykuRZ8jNksCs8QXLxItT+JmW0rk8h5CvHssuE7IZ2vXaku2r+tiep ALzFb26F6VnAM0ycj/XA2rossswdFyuBzUtiwstEmsvLtjZOKWuHywjXIZFc889cRaqS qpjmHLtD8z7refZlT4INQyZcffmnHZd03QQDgT89HWqoGJvUGJY92KRoeDRXdO/4Nzyb KknIjHRGnJlKvXgSUR3ajCFqNam3Ra+PwI74TbPD6LfEhe37UdQTVrQTx/CWmVBj55jQ lbjK8fVv2pgdPVwjSPP3QabjvPNaN++fC+zgCXAXDAj59wwUslnmptY4Rvipc/VKE66g r+iQ== X-Gm-Message-State: ALoCoQlmJ8+cRybtCUiGASOYU39Et2NYzIy+8fmu7L+vCoj5gWVBApfInSQDpp2ukjoqHpXu2i0IDVTHMC7kiKtweVnvd1kt9w== X-Received: by 10.140.92.215 with SMTP id b81mr48532555qge.44.1453319949858; Wed, 20 Jan 2016 11:59:09 -0800 (PST) Received: from [192.168.8.101] ([181.202.164.7]) by smtp.gmail.com with ESMTPSA id c7sm14946721qkb.38.2016.01.20.11.59.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 11:59:09 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_21DF6964-D166-40E7-B67A-56D12E957B48"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Wed, 20 Jan 2016 16:59:05 -0300 Message-Id: <643DFE58-A8AF-483E-B654-0FB73E9634C1@ve7jtb.com> References: <569E2276.5070407@gmx.net> <255B9BB34FB7D647A506DC292726F6E13BB6958F55@WSMSG3153V.srv.dir.telstra.com> To: William Denniss X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 19:59:13 -0000 --Apple-Mail=_21DF6964-D166-40E7-B67A-56D12E957B48 Content-Type: multipart/alternative; boundary="Apple-Mail=_835DCFAA-C8C1-4685-BC6D-E830547E4E74" --Apple-Mail=_835DCFAA-C8C1-4685-BC6D-E830547E4E74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have always been on record as being against having this as a request = parameter, and managed to keep it out of connect. So will be looking to do the same with this. In a response as a list of that methods were used it is mostly harmless. = People think they need it until they discover that it is not really = useful in most circumstances. The methods listed are really not useful, but might be OK as general = categories of response. Fido U2F and UAF fall into what I would call Phishing resistant = credentials, is that something a RP should care about or is that = reflected in the LoA. In the MODRNA profile of OpenID Connect I added some other ones to = indicate if the key is hardware or software etc. This is probably a OK place to start from so I am OK with adopting it, = but will push for change:) John B. > On Jan 20, 2016, at 3:38 AM, William Denniss = wrote: >=20 > On Wed, Jan 20, 2016 at 12:37 PM, Manger, James = > wrote: > Accepting draft-jones-oauth-amr-values-03 is almost okay as a starting = point for work. >=20 > +1 for adoption. > =20 > I would like to see significant changes though: >=20 > * The "amr_values" parameter should be dropped; it just encourages = brittle designs as section 4 "relationship to acr" and section 6 = "security considerations" already warn about. There is no need to enable = that brittleness. If someone really wants this functionality they could = put an amr value in the "acr_values" field as a hack. >=20 > I agree that it seems to encourage brittle designs. Why would the OP = want to use "otp" when it has U2F on file for the same user, for = example? But come to think of it, is any use of "amr" non-brittle? I = guess the broader ones like "user", "rba", "mca" and "mfa" are a little = more future-proof. >=20 > I'm very keen to hear some concrete use-cases for this parameter. >=20 > * The model for amr_values is wrong as well. For example, = "amr":["pwd","otp"] could be a common response that you want, but you = cannot ask for that with amr_values since amr_values=3D"pwd otp" = actually means just "pwd", or just "otp" is okay (and just "pwd" is your = preference). >=20 > * Registering values on a "Specification Required" basis is = over-the-top. This doc registers 8 amr values with just a few words as = each value's "specification" (eg "eye": retina scan biometric). Each of = the other 7 amr values are "specified" in a few lines with a reference = (or two). A "First Come First Served" basis is probably sufficient, with = the "specification" just the description in the registry (that can = include references). >=20 > I agree, "Specification Required" does seem like a high bar. >=20 >=20 > -- > James Manger >=20 >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Hannes Tschofenig > Sent: Tuesday, 19 January 2016 10:48 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] Call for Adoption: Authentication Method Reference = Values >=20 > Hi all, >=20 > this is the call for adoption of Authentication Method Reference = Values, see > https://tools.ietf.org/html/draft-jones-oauth-amr-values-03 = >=20 > Please let us know by Feb 2nd whether you accept / object to the = adoption of this document as a starting point for work in the OAuth = working group. >=20 > Note: The feedback during the Yokohama meeting was inconclusive, = namely > 9 for / zero against / 6 persons need more information. >=20 > You feedback will therefore be important to find out whether we should = do this work in the OAuth working group. >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_835DCFAA-C8C1-4685-BC6D-E830547E4E74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

I have = always been on record as being against having this as a request = parameter, and managed to keep it out of connect.
So = will be looking to do the same with this.

In a response as a list of that methods = were used it is mostly harmless.  People think they need it until = they discover that it is not really useful in most = circumstances.

The methods listed are really not useful,  but might be = OK as general categories of response.

Fido U2F and UAF fall into what I would = call Phishing resistant credentials,  is that something a RP should = care about or is that reflected in the LoA.

In the MODRNA profile of OpenID Connect = I added some other ones to indicate if the key is hardware or software = etc.

This is = probably a OK place to start from so I am OK with adopting it, but will = push for change:)

John B.

On = Jan 20, 2016, at 3:38 AM, William Denniss <wdenniss@google.com>= wrote:

On Wed, Jan 20, 2016 at 12:37 PM, Manger, James <James.H.Manger@team.telstra.com> wrote:
Accepting = draft-jones-oauth-amr-values-03 is almost okay as a starting point for = work.

+1 for adoption.
 
I would like to see = significant changes though:

* The = "amr_values" parameter should be dropped; it just encourages brittle = designs as section 4 "relationship to acr" and section 6 "security = considerations" already warn about. There is no need to enable that = brittleness. If someone really wants this functionality they could put = an amr value in the "acr_values" field as a hack.

I agree that it seems to encourage brittle designs. Why would = the OP want to use "otp" when it has U2F on file for the same user, for = example? But come to think of it, is any use of "amr" non-brittle?  = I guess the broader ones like "user", "rba", "mca" and "mfa" are a = little more future-proof.

I'm very keen to hear some concrete use-cases for this = parameter.

* The model for amr_values = is wrong as well. For example, "amr":["pwd","otp"] could be a common = response that you want, but you cannot ask for that with amr_values = since amr_values=3D"pwd otp" actually means just "pwd", or just "otp" is = okay (and just "pwd" is your preference).

* = Registering values on a "Specification Required" basis is over-the-top. = This doc registers 8 amr values with just a few words as each value's = "specification" (eg "eye": retina scan biometric). Each of the other 7 = amr values are "specified" in a few lines with a reference (or two). A = "First Come First Served" basis is probably sufficient, with the = "specification" just the description in the registry (that can include = references).

I agree, "Specification Required" does = seem like a high bar.


--
James Manger


-----Original Message-----
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Tuesday, 19 January 2016 10:48 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Call for Adoption: Authentication Method = Reference Values

Hi all,

this is the call for adoption of Authentication Method = Reference Values, see
https://tools.ietf.org/html/draft-jones-oauth-amr-values-03=

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

Note: The = feedback during the Yokohama meeting was inconclusive, namely
9 for / zero against / 6 persons need more information.

You feedback will therefore be important to = find out whether we should do this work in the OAuth working group.

Ciao
Hannes & Derek

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

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

= --Apple-Mail=_835DCFAA-C8C1-4685-BC6D-E830547E4E74-- --Apple-Mail=_21DF6964-D166-40E7-B67A-56D12E957B48 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMjAxOTU5MDVaMCMGCSqGSIb3DQEJBDEWBBRtkRhEiX4Chj4Flc7FHYky ZSAR/TCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCiZH442k7Lru74HjdMpUn6Yqwo43DG7OtGZHaP/XgCIZkcJ84AxN2B oulViTCLNGFtEdGwQpPG3cW51sbCdXyMSuO0Yc2ubv6IbG6HTKAv4XYvFnDOVoN/0Sfg7TcS2cs5 1NOdlJYYAoFVSMJVI7cUXuYJJsRZ+3wv0YetkwiNB3lyZxNeozDlxA2SItmiOOF4R1bzlLrCndVr HQ4k6L4aQEp1OpHWwrSkfMQQUidRgwZcYxxNvbv10oxFJyR4EFiAqqxksn/H47OT8m2JUPmljEok G6xmkalwS0l4SYkxJtR9ABI2zIv12ejQl013rFnB+TEpKk+Hr+tbJ/aIdX6GAAAAAAAA --Apple-Mail=_21DF6964-D166-40E7-B67A-56D12E957B48-- From nobody Wed Jan 20 12:08:59 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E3D1A87AB for ; Wed, 20 Jan 2016 12:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmOpRDVFGNqy for ; Wed, 20 Jan 2016 12:08:55 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11FE11A87A1 for ; Wed, 20 Jan 2016 12:08:55 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id s68so7689640qkh.3 for ; Wed, 20 Jan 2016 12:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TqtDQ+t3XH6fPOuKTK4DtUS7X9KHBtgdhr2VB+I08aM=; b=CdhRhu/0uu9oeog2TAMuAU5ZjtuHnoK4qJ791uIHwPylRRO/G2nJq3+OeAkD+BfP5t NykC6HF2+bK7hKUYZCCcPHwkyMl3h1s0yv34bxC1qHCTPOhkcXygtjo/dCe455xx0/qh 2lDT3kVeDFIXguZZYkva8d74eeKLHjwFvhFDJ65EubbyANPPKS4aziKnRmjFeFz37eDJ eKTpj0+7fqcUZapvHgs0AjIvdpqT4B/TPO/u1o5vaLnURpmDKrAtlnxIpAx9ubdmv4Tq B/BMyQ4+VmrHVufmCi//Feh0Hv258e0l/VLAZ/9SbCksao7sx/v3GObKOaxuUI8ZxgFt UaWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TqtDQ+t3XH6fPOuKTK4DtUS7X9KHBtgdhr2VB+I08aM=; b=SDXrAUxFETabh5g02DLgko0hfQteWxIyvzFhh0xtOqr5nkJM/YOIIkzeneeja3Mh72 UdJswOYShYzbDlQVM7ESmyRCZVQwY6RN7f3abIZrpXpTdn/wj+cywfoKO0bvcXck7EN6 s4HlKLBPqKp3HVAm8OseNZUHhZj0gXjF1H5fgPaFs6b4JnkQHpeszdMFY6YQntalbH2e xkIwZyHnzG5RDQSoUmQzmYzpJRdd65O8x+pQ9WPu2qKx0Z6Nln3fykr8yYiYE3K5ob8o aQSwT5TvvI/KhNTUEhixSQblWhreKAbFs7R12s21x9S0FcKXOReRVUh/90U8kr3lKPUu LuPQ== X-Gm-Message-State: ALoCoQk1UFnRlpakK/xQpnYqq0QDlGfTTHVNSbON5FarkBzW8XmxwcM63jHx7EM4/tbN5qNFFth9g8TE5amAu2UQ8fFmGuHrZQ== MIME-Version: 1.0 X-Received: by 10.55.15.139 with SMTP id 11mr47157664qkp.50.1453320534214; Wed, 20 Jan 2016 12:08:54 -0800 (PST) Received: by 10.55.197.80 with HTTP; Wed, 20 Jan 2016 12:08:54 -0800 (PST) In-Reply-To: References: <569E2231.1010107@gmx.net> <6ADAA1B5-7EF9-49EA-A3D9-6EFC57275EB9@ve7jtb.com> Date: Thu, 21 Jan 2016 05:08:54 +0900 Message-ID: From: Nat Sakimura To: John Bradley Content-Type: multipart/alternative; boundary=001a1147446e2fcfdf0529c98ea0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 20:08:58 -0000 --001a1147446e2fcfdf0529c98ea0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for moving this forward. 2016=E5=B9=B41=E6=9C=8821=E6=97=A5=E6=9C=A8=E6=9B=9C=E6=97=A5=E3=80=81John = Bradley=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3= =81=BE=E3=81=97=E3=81=9F: > Yes more is needed. It was theoretical at that point. Now we have > implementation experience. > > On Jan 20, 2016, at 3:38 PM, Brian Campbell > wrote: > > There is > https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#appendix-= A > which has some mention of SFSafariViewController and Chrome Custom Tabs. > > Maybe more is needed? > > On Wed, Jan 20, 2016 at 10:45 AM, John Bradley > wrote: > >> Yes, in July we recommended using the system browser rather than >> WebViews. >> >> About that time Apple announced Safari view controller and Google Chrome >> custom tabs. The code in the OS is now stable and we have done a fair >> amount of testing. >> >> The OIDF will shortly be publishing reference libraries for iOS and >> Android to how how to best use View Controllers, and PKCE in native apps= on >> those platforms. >> >> We do need to update this doc to reflect what we have learned in the las= t >> 6 months. >> >> One problem we do still have is not having someone with Win 10 mobile >> experience to help document the best practices for that platform. >> I don=E2=80=99t understand that platform well enough yet to include anyt= hing. >> >> John B. >> >> On Jan 20, 2016, at 12:40 PM, Aaron Parecki > > wrote: >> >> The section on embedded web views doesn't mention the new iOS 9 >> SFSafariViewController which allows apps to display a system browser wit= hin >> the application. The new API doesn't give the calling application access= to >> anything inside the browser, so it is acceptable for using with OAuth >> flows. I think it's important to mention this new capability for apps to >> leverage since it leads to a better user experience. >> >> I'm sure that can be addressed in the coming months if this document is >> just the starting point. >> >> I definitely agree that a document about native apps is necessary since >> the core leaves a lot of guessing room for an implementation. >> >> For reference, >> https://developer.apple.com/library/prerelease/ios/releasenotes/General/= WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkEle= mentID_26 >> >> And see the attached screenshot for an example of what it looks like. >> >> >> >> ---- >> Aaron Parecki >> aaronparecki.com >> @aaronpk >> >> >> On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig < >> hannes.tschofenig@gmx.net >> > wrote: >> >>> Hi all, >>> >>> this is the call for adoption of OAuth 2.0 for Native Apps, see >>> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ >>> >>> Please let us know by Feb 2nd whether you accept / object to the >>> adoption of this document as a starting point for work in the OAuth >>> working group. >>> >>> Note: If you already stated your opinion at the IETF meeting in Yokoham= a >>> then you don't need to re-state your opinion, if you want. >>> >>> The feedback at the Yokohama IETF meeting was the following: 16 persons >>> for doing the work / 0 persons against / 2 persons need more info >>> >>> Ciao >>> Hannes & Derek >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > > --=20 Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a1147446e2fcfdf0529c98ea0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 for moving this forward.=C2=A0

2016=E5=B9=B41=E6=9C= =8821=E6=97=A5=E6=9C=A8=E6=9B=9C=E6=97=A5=E3=80=81John Bradley<ve7jtb@ve7jtb.com>=E3=81=95=E3=82=93= =E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=97=E3=81=9F:
Yes more is needed. =C2= =A0 It was theoretical at that point.=C2=A0 Now we have implementation expe= rience.

On Jan 20, 2016, at 3:3= 8 PM, Brian Campbell <bcampbell@pingidenti= ty.com> wrote:

There is=20 https://tools.ietf.org/html/draft-wdenniss-oa= uth-native-apps-00#appendix-A which has some mention of SFSafariViewController and Chrome Custom=20 Tabs.

Maybe more is needed?

On Wed, Jan 20, 2016 at 10:45 AM, John Br= adley <ve7jtb@ve7jtb.com><= /span> wrote:
Yes, in July we recommended using the system browser rather than W= ebViews. =C2=A0=C2=A0

About that time Apple announced Sa= fari view controller and Google Chrome custom tabs. =C2=A0 The code in the = OS is now stable and we have done a fair amount of testing.

<= /div>
The OIDF will shortly be publishing reference libraries for iOS a= nd Android to how how to best use View Controllers, and PKCE in native apps= on those platforms.

We do need to update this doc= to reflect what we have learned in the last 6 months.

=
One problem we do still have is not having someone with Win 10 mobile = experience to help document the best practices for that platform.=C2=A0
I don=E2=80=99t understand that platform well enough yet to include = anything.

John B.

On Jan 20, 2016, at 12:40 PM, Aaron Pare= cki <aaron@parecki.com> wrote:

The section on embedded web views doesn'= t mention the new iOS 9 SFSafariViewController which allows apps to display= a system browser within the application. The new API doesn't give the = calling application access to anything inside the browser, so it is accepta= ble for using with OAuth flows. I think it's important to mention this = new capability for apps to leverage since it leads to a better user experie= nce.

I'm sure that can be addressed in the coming mo= nths if this document is just the starting point.

I definitely agree that a document about native apps is necess= ary since the core leaves a lot of guessing room for an implementation.
=


And see the attached screenshot for an exa= mple of what it looks like.

<embed= ded-oauth-view.png>

----
Aaron Parecki<= /div>


On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tsch= ofenig <hannes.tschofenig= @gmx.net> wrote:
Hi all,<= br>
this is the call for adoption of OAuth 2.0 for Native Apps, see
http://datatracker.ietf.org/doc/dra= ft-wdenniss-oauth-native-apps/

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

Note: If you already stated your opinion at the IETF meeting in Yokohama then you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 16 persons
for doing the work / 0 persons against / 2 persons need more info

Ciao
Hannes & Derek


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


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


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





--
Nat Sa= kimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a1147446e2fcfdf0529c98ea0-- From nobody Wed Jan 20 12:11:05 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260E51A893C for ; Wed, 20 Jan 2016 12:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9G4bM-KUno5 for ; Wed, 20 Jan 2016 12:11:01 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C1A1A8821 for ; Wed, 20 Jan 2016 12:11:01 -0800 (PST) Received: by mail-qg0-x233.google.com with SMTP id e32so15569928qgf.3 for ; Wed, 20 Jan 2016 12:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=yn8jvZdqhSyUf4DNa0gRrM9ZA0L7zipVQe5XlJTg7SU=; b=iLktEcgG2fG8QSxFQ3eIzefvCRFks4n1k4m9RJrv5mR7L4XfqvWJx8r05mTOxjaYcb Z24H7cwkTFq92oEhnoXzkvYKK7+03WwU/elqGSU93BChn+4IHw1iZQW9cvqLrvkjg4XP i5XHyt83UqEcUBNxPdl/DagDjEibT8iMCWyZfQmac844KVv+1scySFbIrgkYR/DRaEjW YmvWYbEMaRqdT94mDanUEoUz9q4zat6ZD+db7BdXYzCXuukSL1b+JSRpnKcREhA9pZn+ ume6Kq+obe7bF9glzfOsOrIZkp736gyNCby5S1Rb7VUxn+M+xl+hNldcBrSA4JyuFDdE LWjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=yn8jvZdqhSyUf4DNa0gRrM9ZA0L7zipVQe5XlJTg7SU=; b=UsNTL28wvqn6duZUJDyoplOLG0Gma1+HT4ZL0Ad6rJbSurjJPKAPw+qGaQrtPkk1fy yAkLrmSgknIunzaMDCusv0AvGaqKqeLc4KWrQ03mXyoiKu1kSM2UY1tDoAXZ88OBfNE0 DvEnzTtefNh/P59km0k7HARdHFrsd/5AGvMwMjj9AcgASNN/ZYwf5hs4H7azFlwG/c+U 8ufniOPxRCbWmeBPoSCGSw8ADm9GXfpANvlsFA4HQ/ivZ5u9aY2YCbB3dqsGTCrTd/Br ewGHbt+zv60fQ4hwOo4XFejm7dgsm5zZVyhX+2ile6WjOINTERvpWsNE7SxRLX16kDOT 1dBw== X-Gm-Message-State: ALoCoQmE2fIncZ6WQGoGtMxxCxBwWxmEShpGJDl99etEkzEfwoBskAgB1pYpZIJGzUrFYmi4xXw7iDhGRvfmkGDstSRJymdB5Q== X-Received: by 10.140.82.11 with SMTP id g11mr48313487qgd.77.1453320660071; Wed, 20 Jan 2016 12:11:00 -0800 (PST) Received: from [192.168.8.101] ([181.202.164.7]) by smtp.gmail.com with ESMTPSA id d64sm5603965qgd.9.2016.01.20.12.10.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 12:10:59 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_1FE76715-29CB-4A9F-AF73-54DB3C06FA41"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Wed, 20 Jan 2016 17:10:56 -0300 Message-Id: <9062E913-39FB-4610-80FE-70796CBDEAC1@ve7jtb.com> References: <569E2231.1010107@gmx.net> <6ADAA1B5-7EF9-49EA-A3D9-6EFC57275EB9@ve7jtb.com> To: Nat Sakimura X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 20:11:04 -0000 --Apple-Mail=_1FE76715-29CB-4A9F-AF73-54DB3C06FA41 Content-Type: multipart/alternative; boundary="Apple-Mail=_39225A23-3B0C-43DD-9982-451920C621CA" --Apple-Mail=_39225A23-3B0C-43DD-9982-451920C621CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 PS as you probably suspected I am in favour of moving this forward. > On Jan 20, 2016, at 5:08 PM, Nat Sakimura wrote: >=20 > +1 for moving this forward.=20 >=20 > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5=E6=9C=A8=E6=9B=9C=E6=97=A5=E3=80=81Jo= hn Bradley>=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3= =81=BE=E3=81=97=E3=81=9F: > Yes more is needed. It was theoretical at that point. Now we have = implementation experience. >=20 >> On Jan 20, 2016, at 3:38 PM, Brian Campbell = > wrote: >>=20 >> There is = https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#appendix-A= = which has some mention of SFSafariViewController and Chrome Custom = Tabs.=20 >>=20 >> Maybe more is needed? >>=20 >> On Wed, Jan 20, 2016 at 10:45 AM, John Bradley > wrote: >> Yes, in July we recommended using the system browser rather than = WebViews. =20 >>=20 >> About that time Apple announced Safari view controller and Google = Chrome custom tabs. The code in the OS is now stable and we have done = a fair amount of testing. >>=20 >> The OIDF will shortly be publishing reference libraries for iOS and = Android to how how to best use View Controllers, and PKCE in native apps = on those platforms. >>=20 >> We do need to update this doc to reflect what we have learned in the = last 6 months. >>=20 >> One problem we do still have is not having someone with Win 10 mobile = experience to help document the best practices for that platform.=20 >> I don=E2=80=99t understand that platform well enough yet to include = anything. >>=20 >> John B. >>=20 >>> On Jan 20, 2016, at 12:40 PM, Aaron Parecki > wrote: >>>=20 >>> The section on embedded web views doesn't mention the new iOS 9 = SFSafariViewController which allows apps to display a system browser = within the application. The new API doesn't give the calling application = access to anything inside the browser, so it is acceptable for using = with OAuth flows. I think it's important to mention this new capability = for apps to leverage since it leads to a better user experience. >>>=20 >>> I'm sure that can be addressed in the coming months if this document = is just the starting point. >>>=20 >>> I definitely agree that a document about native apps is necessary = since the core leaves a lot of guessing room for an implementation. >>>=20 >>> For reference, = https://developer.apple.com/library/prerelease/ios/releasenotes/General/Wh= atsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElem= entID_26 = >>>=20 >>> And see the attached screenshot for an example of what it looks = like. >>>=20 >>> >>>=20 >>> ---- >>> Aaron Parecki >>> aaronparecki.com >>> @aaronpk >>>=20 >>>=20 >>> On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig = > wrote: >>> Hi all, >>>=20 >>> this is the call for adoption of OAuth 2.0 for Native Apps, see >>> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ = >>>=20 >>> Please let us know by Feb 2nd whether you accept / object to the >>> adoption of this document as a starting point for work in the OAuth >>> working group. >>>=20 >>> Note: If you already stated your opinion at the IETF meeting in = Yokohama >>> then you don't need to re-state your opinion, if you want. >>>=20 >>> The feedback at the Yokohama IETF meeting was the following: 16 = persons >>> for doing the work / 0 persons against / 2 persons need more info >>>=20 >>> Ciao >>> Hannes & Derek >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >=20 >=20 >=20 > --=20 > Nat Sakimura (=3Dnat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 --Apple-Mail=_39225A23-3B0C-43DD-9982-451920C621CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 PS as you probably suspected I am in favour of moving this = forward.


On = Jan 20, 2016, at 5:08 PM, Nat Sakimura <sakimura@gmail.com> = wrote:

+1 = for moving this forward. 

2016=E5=B9=B41=E6=9C=8821=E6=97=A5=E6=9C=A8=E6=9B=9C=E6=97=A5=E3= =80=81John Bradley<ve7jtb@ve7jtb.com>=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3= =81=8D=E3=81=BE=E3=81=97=E3=81=9F:
Yes= more is needed.   It was theoretical at that point.  Now we = have implementation experience.

On Jan = 20, 2016, at 3:38 PM, Brian Campbell <bcampbell@pingidentity.com> = wrote:

There is=20 https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00= #appendix-A which has some mention of SFSafariViewController and Chrome Custom=20 Tabs.

Maybe more is needed?

On Wed, Jan 20, 2016 at 10:45 AM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
Yes, in July we recommended = using the system browser rather than WebViews.   

About that time Apple = announced Safari view controller and Google Chrome custom tabs.   = The code in the OS is now stable and we have done a fair amount of = testing.

The = OIDF will shortly be publishing reference libraries for iOS and Android = to how how to best use View Controllers, and PKCE in native apps on = those platforms.

We do need to update this doc to reflect what we have learned = in the last 6 months.

One problem we do still have is not having someone with Win = 10 mobile experience to help document the best practices for that = platform. 
I don=E2=80=99t understand that = platform well enough yet to include anything.

John B.

On Jan 20, 2016, at 12:40 = PM, Aaron Parecki <aaron@parecki.com> wrote:

The section on embedded web views doesn't mention the new iOS = 9 SFSafariViewController which allows apps to display a system browser = within the application. The new API doesn't give the calling application = access to anything inside the browser, so it is acceptable for using = with OAuth flows. I think it's important to mention this new capability = for apps to leverage since it leads to a better user experience.

I'm sure that can be = addressed in the coming months if this document is just the starting = point.

I definitely agree that a document about = native apps is necessary since the core leaves a lot of guessing room = for an implementation.

For reference, https://developer.apple.com/library/prerelease/ios/releasenotes= /General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-D= ontLinkElementID_26

And see the attached screenshot for an example of what it = looks like.

<embedded-oauth-view.png>

----
Aaron = Parecki
aaronparecki.com
@aaronpk


On Tue, Jan 19, 2016 at 3:46 = AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> = wrote:
Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see
http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-app= s/

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

Note: If you already stated your opinion at the IETF meeting in = Yokohama
then you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 16 = persons
for doing the work / 0 persons against / 2 persons need more info

Ciao
Hannes & Derek


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


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


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





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


= --Apple-Mail=_39225A23-3B0C-43DD-9982-451920C621CA-- --Apple-Mail=_1FE76715-29CB-4A9F-AF73-54DB3C06FA41 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMjAyMDEwNTdaMCMGCSqGSIb3DQEJBDEWBBQRVmavSmbm2p19TffhZyBI eCIqKDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBtAAw8O4QI9CSg1qfSl3So9pEV8ij0bJzPG7p3S8on5AXpMV7PPvgM yZOIDUzK6SJHyIx7hd4x7bubAaXzddwgsXI093p/cPL7Y9QlT4jE6JrgNMXvYoueNUuff8TIt1hm xHRIpQPElxHS/p5KRGJS+C8YSCKxPuI6Y/Gpy32ZMjhGdHBDdiy7AYsxmo4sMdBuZrzekjHu4DSA lgFAaSf/ihhjstDPImYFF3Jy9JlFciY1t/VeW8FpnHBDSfVfC8wD/HflBl1BaRasaZB7ESdbvIIG wiioxBFmbp7yTZXXVHx5AoHoeqR1VmdA1/W3ITHUEsgWs6abPCo2jqVna1OdAAAAAAAA --Apple-Mail=_1FE76715-29CB-4A9F-AF73-54DB3C06FA41-- From nobody Wed Jan 20 12:37:20 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5781ACE21 for ; Wed, 20 Jan 2016 12:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af7XwFddiNQW for ; Wed, 20 Jan 2016 12:37:17 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90871ACE1D for ; Wed, 20 Jan 2016 12:37:14 -0800 (PST) X-AuditID: 12074423-f797f6d0000023d0-5e-569feff8487b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 89.71.09168.8FFEF965; Wed, 20 Jan 2016 15:37:12 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u0KKbCs0014770; Wed, 20 Jan 2016 15:37:12 -0500 Received: from [192.168.128.48] (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 u0KKbA1J006759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jan 2016 15:37:11 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6CB68B5A-469C-4012-BF3F-5C1F956F2469"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5.2 From: Justin Richer In-Reply-To: <569E2276.5070407@gmx.net> Date: Wed, 20 Jan 2016 15:37:09 -0500 Message-Id: <8A2DAF46-BAF7-439D-8FE3-65EA2DA8E692@mit.edu> References: <569E2276.5070407@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAKsWRmVeSWpSXmKPExsUixCmqrPvj/fwwg5XfzC2W7rzHanHy7Ss2 ByaPxZv2s3ksWfKTKYApissmJTUnsyy1SN8ugStjzb+Z7AWL+Sv+3J/G2sA4l7eLkZNDQsBE YsPJy6wQtpjEhXvr2boYuTiEBBYzSSz7cx3K2cgoce/jTVYI5zaTxNa2n2AtwgKBEq9mr2QH sXkF9CRe3boMVsQsMIVRYvnu2UAJDqC5UhIz9guA1LAJqEpMX9PCBGJzCqhLfPreCNbLAhS/ 93ARG0g5M1C8/aQLxEgricYFDWBhIQE1iRdzpUHCIgKGEtdnToc6WlZi9+9HTBMYBWchOWIW siNAEswC2hLLFr5mhrA1JfZ3L2eBsOUltr+dAxW3lFg88wZU3FbiVt8CJgjbTuLRtEWsCxg5 VjHKpuRW6eYmZuYUpybrFicn5uWlFuma6eVmluilppRuYgRFDruL8g7GPweVDjEKcDAq8fDe uDY/TIg1say4MvcQoyQHk5Io76nXQCG+pPyUyozE4oz4otKc1OJDjCpAux5tWH2BUYolLz8v VUmEV+8RUB1vSmJlVWpRPkyZNAeLkjjvro65YUIC6YklqdmpqQWpRTBZGQ4OJQneVGDiEBIs Sk1PrUjLzClBSDNxcB5ilODgARp+7h3I8OKCxNzizHSI/ClGRSlx3j6QhABIIqM0D64XlPAS 3h42fcUoDvSWMO9ekCoeYLKE634FNJgJaPBeM7DBJYkIKakGxhqm26puUrWH2yfNiC69ofzx /l2+q7789VbX+s7N/88tI3ZgSzHT+T3Pef80W3iWNH6fYbQnSmnzHbHnb/dH3JgQvm+aruWD VZmzv7PWueWZXQmSmenVGM1f6lV7JFH40gvxPZxft3rEOPHZpkem69VuUmRlu7Jdyig9/6ey zS2735X/Lm29o8RSnJFoqMVcVJwIADFdga1TAwAA Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 20:37:19 -0000 --Apple-Mail=_6CB68B5A-469C-4012-BF3F-5C1F956F2469 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just reiterating my stance that this document detailing user = authentication methods has no place in the OAuth working group. =E2=80=94 Justin > On Jan 19, 2016, at 6:48 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > this is the call for adoption of Authentication Method Reference = Values, see > https://tools.ietf.org/html/draft-jones-oauth-amr-values-03 >=20 > Please let us know by Feb 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. >=20 > Note: The feedback during the Yokohama meeting was inconclusive, = namely > 9 for / zero against / 6 persons need more information. >=20 > You feedback will therefore be important to find out whether we should > do this work in the OAuth working group. >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_6CB68B5A-469C-4012-BF3F-5C1F956F2469 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWn+/1AAoJEDPAngkbd+w9ozMH/jCzsc8HC0yIcWuUhR1Y8IBZ IUpFNmNUym2IX2MpzQW2jFIt9DEPdLXxvhpwkl6Fe4IqsaRb2aPXvM2VtEIsv+Xs dMpxRwWzoGTGoEznEDbuzB3kW47CjgTIzomjCntlYqCzGBMqJC30sFY4Iio5JNTC q93GqcOEIIsR/jUs0Qt/Nslm+JTpGJQBkS4MApVryRHgQrNljLgVycLnHDBVWGpp dhfqc6y5YgHLvvTY7z95dt9w6vW7SO3loiZ3vnU6MG+yWmDawFy5ng3xQ5+WvdKE 7Ni30nXQYGPq8sQMXk5onjDYNJ6BGO7uNMolj7kPF5PuLuFhLedoid5ctRABZ8k= =Kp3h -----END PGP SIGNATURE----- --Apple-Mail=_6CB68B5A-469C-4012-BF3F-5C1F956F2469-- From nobody Wed Jan 20 12:43:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566671ACE4B for ; Wed, 20 Jan 2016 12:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fD_Nj7e7hDew for ; Wed, 20 Jan 2016 12:43:40 -0800 (PST) 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 48D411ACE42 for ; Wed, 20 Jan 2016 12:43:40 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id s68so8085873qkh.3 for ; Wed, 20 Jan 2016 12:43:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=RHlkXbUAFJ6DrGS9SejXCezupk3BsU2nBhHy4HoG3Xg=; b=ayrBGuG/TqL/VMnFs5JSrvlSGwrpxrvTuGHkinwPUKYVWq2rx2j4dLC6bhtrnJ7Pkm 21FX63SWrG8EqtGFvIviAvb+cUUPNfCVtuxl8Ng6R0xspaC9NHlq0fUXvdO6lApCT+bl x8qVCqtGOs5Sgvky6IyKEXlznWbhgd0yi93Qa3w2MItL/0nOY2aK6+kLW/jQy/VICTUo COhy58TFlmJmZCaaeBhJiXPoqGProdv+2A31IWQZJ3gKwIa6CGTmlWxJIfcDIKklI2bf 67WW/SHxMMSPymqqWcTwWGlrSITyLxl6s4bkc0f+W8CkVYAIFJahKBnBmd+mHakc4qSz dXNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=RHlkXbUAFJ6DrGS9SejXCezupk3BsU2nBhHy4HoG3Xg=; b=kqFrOncJcI9GPgyRcZQFX2u69UTuMzq5ju2XjzvT6f7smwVjrwipMgvJfkvto+6qUF 1X4fBDFe190F0flxt+EpFrvqvQMNbrBvrUD9WIhbSDjNMwdhUYkUtTTIPIYwnCZpRlPW MbVa0/nwXbeVLGJYmzZOJrKVcqG4ZBOJ360J/SMHeoZUXWpIKeve7N5lKm1B0LIovn+F 1g/LkSRdF1198Cv+Lhf+jG33ZI5KwkiavVN8Yp6419nBqCoi1DlIQT7wDauT8nXp6Mwo 7gmJ/UOqH8ORexWfA/xgsDvrMBZKrH9eAFeLmI75/65g95OgPlY3aI+RAzAEPHIvKGKR lidA== X-Gm-Message-State: ALoCoQlndsz5gTgeZqoPLQH4UJKOGdNFIsDhFCXpr+qr9H5oQb1txXjzCZV50sS9bt9h1PsWHTL5H9cNCNyrokBroWKjeadH7Q== X-Received: by 10.55.81.70 with SMTP id f67mr47607088qkb.28.1453322619200; Wed, 20 Jan 2016 12:43:39 -0800 (PST) Received: from [192.168.8.101] ([181.202.164.7]) by smtp.gmail.com with ESMTPSA id b6sm15107374qkh.12.2016.01.20.12.43.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 12:43:38 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C998B081-2050-4ECD-B515-4A2D571BB675"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: <8A2DAF46-BAF7-439D-8FE3-65EA2DA8E692@mit.edu> Date: Wed, 20 Jan 2016 17:43:34 -0300 Message-Id: <47F7D0BA-8E98-4E37-BA84-D128C0FD8396@ve7jtb.com> References: <569E2276.5070407@gmx.net> <8A2DAF46-BAF7-439D-8FE3-65EA2DA8E692@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 20:43:42 -0000 --Apple-Mail=_C998B081-2050-4ECD-B515-4A2D571BB675 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I see your point that it is a fine line reporting how a person = authenticated to a Authorization endpoit (it might be by SAML etc) and = encouraging people to use OAuth for Authentication. We already have the amr response in connect. The only thing really = missing is a registry. Unless this is a sneaky way to get requested_amr = into Connect? John B. > On Jan 20, 2016, at 5:37 PM, Justin Richer wrote: >=20 > Just reiterating my stance that this document detailing user = authentication methods has no place in the OAuth working group. >=20 > =E2=80=94 Justin >=20 >> On Jan 19, 2016, at 6:48 AM, Hannes Tschofenig = wrote: >>=20 >> Hi all, >>=20 >> this is the call for adoption of Authentication Method Reference = Values, see >> https://tools.ietf.org/html/draft-jones-oauth-amr-values-03 >>=20 >> Please let us know by Feb 2nd whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >>=20 >> Note: The feedback during the Yokohama meeting was inconclusive, = namely >> 9 for / zero against / 6 persons need more information. >>=20 >> You feedback will therefore be important to find out whether we = should >> do this work in the OAuth working group. >>=20 >> Ciao >> Hannes & Derek >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_C998B081-2050-4ECD-B515-4A2D571BB675 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMjAyMDQzMzRaMCMGCSqGSIb3DQEJBDEWBBSSjNMpUSd+iz2bTQnXZwnq 8PKB1jCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBMk1ct1WQ+779PkA8n4+70RJTqf+BJo+ffsqHo/9IEI8Dw5zOt5d0K Tx/EEmkeWr6vEHZ6pCvUhtpV7poat+GK736iRZuQXFTvIWEd6FJx3qt9Yidbqm1OJWwW5hOixoX8 Dj02MVrMdqj6TMsw67iRpgts0RrRpygQ+OCQmkY8JFy85b9upgoYCwr8IlBUs4e9mHhddF8bnvf8 AdYw103EbOT7bn859TMoekqcSLCsvuXyCzL+362GqKUk44uzulkNVjefInRSMFIiT2fp2zkJKTv7 /oLTXpOlv9GoThfXZZKAg0D/dIfBqYmfztH/w9/uf39xDKc/itbs1JhjtaR8AAAAAAAA --Apple-Mail=_C998B081-2050-4ECD-B515-4A2D571BB675-- From nobody Wed Jan 20 13:13:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F641ACED0 for ; Wed, 20 Jan 2016 13:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYPV9SXuZcfS for ; Wed, 20 Jan 2016 13:13:27 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 AE3361ACEC8 for ; Wed, 20 Jan 2016 13:13:27 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id e32so16952388qgf.3 for ; Wed, 20 Jan 2016 13:13:27 -0800 (PST) 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 :content-type; bh=HRqrjUeQ6n1pecnp2OUlBqfn3S5ZKVzcOQLFDknrOTo=; b=Tmdc1OQfcivPaY1wmU/ppjKxHZEd/48xVvZOv4MTrLRqsHCDkjnQWsWf7csugHlRDP +XhpI2Lx2OVDGzuQkyc9wyP9k5sjal8cpADJsCknSgQ4QR0RJHmTsCVbnuS/g2HeEyKO tyklTNCOlscPCvUdzvuaELioDb+NG2zkF1vk4HKj3ejbhZtd9SL6IWvyVMOkEDsHJd8j 88kvLAzFGJfddQGWSQYp2eKyuz/BzT0I1HqBAYhpIL0Swmkm5XPVwLRXzZJ9HcleGLm0 GFpBjdrzd6N3hcomuDV1D0dhCt9DqlloqIfzuZzEOVIcSoj7eMHuOgJWiTEcmvQKo0VZ aaNQ== 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:content-type; bh=HRqrjUeQ6n1pecnp2OUlBqfn3S5ZKVzcOQLFDknrOTo=; b=dQk5d9hY4viVF0vwAkUPO57xVLdVG113tSC3JdtOZaDJ7CIoP2cuDKQ0u55YyZS6Gr VleywUNL3aeScirgeSsG7d/lRMpUMc7Qj7FFwCphetiYrYF/Ll3ZnRRgFf1B4sQT8mZJ FZvQpkjjpD7kghCtp0b3XgcOjz/yqQPBGQl4xf+BS1b+aYsY12nFzh/5OtpOw6bZv/tR NIynRIwkYQi6Lcnipi/tCjzOeB5BakG5tY2vWU1oAFZFz6fdXBpAXOHdotUrowKWFlYr UOoCOVLnlliANX33qZy240LkuVM/ltDFNWHSpLl7fdzlDFa6m2KFh5wu9qJsafvRMuZA FrVQ== X-Gm-Message-State: AG10YOTWQwb595RAydQ+F6GHbRexNlKC9dRnm83SrO4snyCko9ocCBUIYKnelCyaxNa3JoewQu2hL0bElMLSqg== X-Received: by 10.140.180.80 with SMTP id b77mr29664542qha.67.1453324406840; Wed, 20 Jan 2016 13:13:26 -0800 (PST) MIME-Version: 1.0 References: <831693C2CDA2E849A7D7A712B24E257F4A129732@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F4A130B17@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A130B17@BRN1WNEXMBX01.vcorp.ad.vrsn.com> From: Nat Sakimura Date: Wed, 20 Jan 2016 21:13:14 +0000 Message-ID: To: "Hollenbeck, Scott" , "OAuth@ietf.org" Content-Type: multipart/alternative; boundary=001a113a7e3c0365ab0529ca755d Archived-At: Subject: Re: [OAUTH-WG] Cross-Area Review Request for RDAP Authentication X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 21:13:29 -0000 --001a113a7e3c0365ab0529ca755d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It is on my todo list but ... 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 23:40 Hollenbeck, Scott : > > -----Original Message----- > > From: Hollenbeck, Scott > > Sent: Monday, January 11, 2016 8:31 AM > > To: OAuth@ietf.org > > Subject: Cross-Area Review Request for RDAP Authentication > > > > I'd like to ask folks who are more familiar with OAuth than I am to > > please review an I-D I've written that describes an approach to using > > OpenID Connect with the Registration Data Access Protocol (RDAP, a > > product of the WEIRDS WG). Those of you who are familiar with WHOIS > > will understand the motivation behind the development of RDAP and the > > benefits of being able to authenticate clients. > > > > The I-D can be found here: > > > > https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-openid/ > > > > Note that RDAP does not depend on clients using web browsers. I have > > some text in the document that describes how to use OpenID Connect with > > non-browser clients and I'd like to ensure that it all makes sense. > > Can anyone help with this? > > Scott > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113a7e3c0365ab0529ca755d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It is on my todo list but ...
2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 23:40 Hollenbeck, Scott &l= t;shollenbeck@verisign.com&= gt;:
> -----Original Message----= -
> From: Hollenbeck, Scott
> Sent: Monday, January 11, 2016 8:31 AM
> To: OAuth@ietf.org=
> Subject: Cross-Area Review Request for RDAP Authentication
>
> I'd like to ask folks who are more familiar with OAuth than I am t= o
> please review an I-D I've written that describes an approach to us= ing
> OpenID Connect with the Registration Data Access Protocol (RDAP, a
> product of the WEIRDS WG). Those of you who are familiar with WHOIS > will understand the motivation behind the development of RDAP and the<= br> > benefits of being able to authenticate clients.
>
> The I-D can be found here:
>
> https://datatracker.ietf.o= rg/doc/draft-hollenbeck-weirds-rdap-openid/
>
> Note that RDAP does not depend on clients using web browsers. I have > some text in the document that describes how to use OpenID Connect wit= h
> non-browser clients and I'd like to ensure that it all makes sense= .

Can anyone help with this?

Scott

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a113a7e3c0365ab0529ca755d-- From nobody Wed Jan 20 13:29:28 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805311ACF59 for ; Wed, 20 Jan 2016 13:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgfoNKmkDsP4 for ; Wed, 20 Jan 2016 13:29:22 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0103.outbound.protection.outlook.com [207.46.100.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D67E1ACF1C for ; Wed, 20 Jan 2016 13:29:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1JVnEjbysAMh6YccY116h5UCaZzyj1xs+6C7csFXLm8=; b=nK3Ku3vZdkCCr3MNJLoxdSGdGekoJdn1zsC4TrTNNnBmgcf91cLatFfSoUg9otfVZQxL507/fmZnwxEXgnmYkMJFC81PW2wTpRokAuRipUV0ytvnP+8nm1XjXf/03TJVx7wfBekNmpwhtFCrtKnXnVQa/Xo/11BMzkD5I/Wqhro= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.365.19; Wed, 20 Jan 2016 21:29:19 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Wed, 20 Jan 2016 21:29:19 +0000 From: Mike Jones To: John Bradley , Justin Richer Thread-Topic: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values Thread-Index: AQHRUq9MSU/VGOfqxU64HImRUaDLo58E30uAgAABywCAAAn9MA== Date: Wed, 20 Jan 2016 21:29:18 +0000 Message-ID: References: <569E2276.5070407@gmx.net> <8A2DAF46-BAF7-439D-8FE3-65EA2DA8E692@mit.edu> <47F7D0BA-8E98-4E37-BA84-D128C0FD8396@ve7jtb.com> In-Reply-To: <47F7D0BA-8E98-4E37-BA84-D128C0FD8396@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [131.107.147.213] x-ms-office365-filtering-correlation-id: 310f5bf2-96ef-4b44-6302-08d321e0c196 x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:3TcS0iEGC0Qxq9ZiO2ILuj+C60FEx8m19jSK88DIyJxMCtQHHdGl2x0SFwynng2iUxQr2rnIWAEnWXG+AJmnwrIWIgtDoCn62NxvGz/5icpZ6RAPoxM6nzZiKjF0TsTmrBezW7mUUZL9a2Cs6Nhfzg==; 24:K8gLjjLqvHAwWFUZGxyNW24xJb1SYsGda2sUk/2/wj5s+tkNbA9BJjI1XyJxTue2qDAZfAAvVwqnUOxmbE3P+5BhHLp0haMgCXuT3CJA4bA= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; UriScan:; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; x-forefront-prvs: 0827D7ACB9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(53754006)(377454003)(24454002)(13464003)(189002)(50986999)(189998001)(33656002)(122556002)(2900100001)(19580405001)(4326007)(54356999)(19580395003)(74316001)(101416001)(2171001)(11100500001)(3846002)(76176999)(77096005)(5003600100002)(40100003)(6116002)(586003)(102836003)(1220700001)(2906002)(5002640100001)(5004730100002)(15975445007)(5008740100001)(5005710100001)(87936001)(86612001)(2950100001)(1096002)(5001960100002)(8990500004)(99286002)(86362001)(66066001)(10290500002)(105586002)(5001770100001)(106356001)(106116001)(10090500001)(76576001)(10400500002)(97736004)(81156007)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2016 21:29:18.7527 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 21:29:26 -0000 VGhlIHByaW1hcnkgcHVycG9zZSBvZiB0aGUgc3BlY2lmaWNhdGlvbiBpcyB0byBlc3RhYmxpc2gg YSByZWdpc3RyeSBmb3IgImFtciIgSldUIGNsYWltIHZhbHVlcy4gIFRoaXMgaXMgaW1wb3J0YW50 LCBhcyBpdCBpbmNyZWFzZXMgaW50ZXJvcGVyYWJpbGl0eSBhbW9uZyBpbXBsZW1lbnRhdGlvbnMg dXNpbmcgdGhpcyBjbGFpbS4NCg0KSXQncyBhIGZhaXIgcXVlc3Rpb24gd2hldGhlciAicmVxdWVz dGVkX2FtciIgc2hvdWxkIGJlIGtlcHQgb3IgZHJvcHBlZC4gIEkgYWdyZWUgd2l0aCBKb2huIGFu ZCBKYW1lcyB0aGF0IGl0J3MgYmFkIGFyY2hpdGVjdHVyZS4gIEkgcHV0IGl0IGluIHRoZSAtMDAg aW5kaXZpZHVhbCBkcmFmdCB0byBkb2N1bWVudCBleGlzdGluZyBwcmFjdGljZS4gIEkgc3VzcGVj dCB0aGF0IHNob3VsZCB0aGUgZHJhZnQgaXMgYWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91cCBh cyBhIHN0YXJ0aW5nIHBvaW50LCBvbmUgb2YgdGhlIGZpcnN0IHRoaW5ncyB0aGUgd29ya2luZyBn cm91cCB3aWxsIHdhbnQgdG8gZGVjaWRlIGlzIHdoZXRoZXIgdG8gZHJvcCBpdC4gIEkgc3VzcGVj dCB0aGF0IEkga25vdyBob3cgdGhpcyB3aWxsIGNvbWUgb3V0IGFuZCBJIHdvbid0IGJlIHNhZCwg YXJjaGl0ZWN0dXJhbGx5LCB0byBzZWUgaXQgZ28uDQoNCkFzIHRvIHdoZXRoZXIgdGhpcyBiZWxv bmdzIGluIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLCBsb25nIGFnbyBpdCB3YXMgZGVjaWRlZCB0 aGF0IEpXVCBhbmQgSldUIGNsYWltIGRlZmluaXRpb25zIHdlcmUgd2l0aGluIHNjb3BlIG9mIHRo ZSBPQXV0aCB3b3JraW5nIGdyb3VwLiAgVGhhdCBzaGlwIGhhcyBsb25nIGFnbyBzYWlsZWQsIGJv dGggaW4gdGVybXMgb2YgUkZDIDc1MTkgYW5kIGl0IGNvbnRpbnVlcyB0byBzYWlsLCBmb3IgaW5z dGFuY2UsIGluIGRyYWZ0LWlldGYtb2F1dGgtcHJvb2Ytb2YtcG9zc2Vzc2lvbiwgd2hpY2ggZGVm aW5lcyBhIG5ldyBKV1QgY2xhaW0sIGFuZCBpcyBpbiB0aGUgUkZDIEVkaXRvciBRdWV1ZS4gIERl ZmluaW5nIGEgcmVnaXN0cnkgZm9yIHZhbHVlcyBvZiB0aGUgImFtciIgY2xhaW0sIHdoaWNoIGlz IHJlZ2lzdGVyZWQgaW4gdGhlIE9BdXRoLWVzdGFibGlzaGVkIHJlZ2lzdHJ5IGF0IGh0dHA6Ly93 d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvand0LCBpcyBzcXVhcmVseSB3aXRoaW4gdGhlIE9BdXRo IFdHJ3MgbWlzc2lvbiBmb3IgdGhlIGNyZWF0aW9uIGFuZCBzdGV3YXJkc2hpcCBvZiBKV1QuDQoN CgkJCQktLSBNaWtlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPQXV0aCBb bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkN ClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMCwgMjAxNiAxMjo0NCBQTQ0KVG86IEp1c3RpbiBS aWNoZXIgPGpyaWNoZXJAbWl0LmVkdT4NCkNjOiA8b2F1dGhAaWV0Zi5vcmc+IDxvYXV0aEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9uOiBBdXRoZW50 aWNhdGlvbiBNZXRob2QgUmVmZXJlbmNlIFZhbHVlcw0KDQpJIHNlZSB5b3VyIHBvaW50IHRoYXQg aXQgaXMgYSBmaW5lIGxpbmUgcmVwb3J0aW5nIGhvdyBhIHBlcnNvbiBhdXRoZW50aWNhdGVkIHRv IGEgQXV0aG9yaXphdGlvbiBlbmRwb2l0IChpdCBtaWdodCBiZSBieSBTQU1MIGV0YykgYW5kIGVu Y291cmFnaW5nIHBlb3BsZSB0byB1c2UgT0F1dGggZm9yIEF1dGhlbnRpY2F0aW9uLg0KDQpXZSBh bHJlYWR5IGhhdmUgdGhlIGFtciByZXNwb25zZSBpbiBjb25uZWN0LiAgVGhlIG9ubHkgdGhpbmcg cmVhbGx5IG1pc3NpbmcgaXMgYSByZWdpc3RyeS4gIFVubGVzcyB0aGlzIGlzIGEgc25lYWt5IHdh eSB0byBnZXQgcmVxdWVzdGVkX2FtciBpbnRvIENvbm5lY3Q/DQoNCkpvaG4gQi4NCj4gT24gSmFu IDIwLCAyMDE2LCBhdCA1OjM3IFBNLCBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU+IHdy b3RlOg0KPiANCj4gSnVzdCByZWl0ZXJhdGluZyBteSBzdGFuY2UgdGhhdCB0aGlzIGRvY3VtZW50 IGRldGFpbGluZyB1c2VyIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgaGFzIG5vIHBsYWNlIGluIHRo ZSBPQXV0aCB3b3JraW5nIGdyb3VwLg0KPiANCj4g4oCUIEp1c3Rpbg0KPiANCj4+IE9uIEphbiAx OSwgMjAxNiwgYXQgNjo0OCBBTSwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2Zlbmln QGdteC5uZXQ+IHdyb3RlOg0KPj4gDQo+PiBIaSBhbGwsDQo+PiANCj4+IHRoaXMgaXMgdGhlIGNh bGwgZm9yIGFkb3B0aW9uIG9mIEF1dGhlbnRpY2F0aW9uIE1ldGhvZCBSZWZlcmVuY2UgDQo+PiBW YWx1ZXMsIHNlZQ0KPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9h dXRoLWFtci12YWx1ZXMtMDMNCj4+IA0KPj4gUGxlYXNlIGxldCB1cyBrbm93IGJ5IEZlYiAybmQg d2hldGhlciB5b3UgYWNjZXB0IC8gb2JqZWN0IHRvIHRoZSANCj4+IGFkb3B0aW9uIG9mIHRoaXMg ZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3Igd29yayBpbiB0aGUgT0F1dGggDQo+PiB3 b3JraW5nIGdyb3VwLg0KPj4gDQo+PiBOb3RlOiBUaGUgZmVlZGJhY2sgZHVyaW5nIHRoZSBZb2tv aGFtYSBtZWV0aW5nIHdhcyBpbmNvbmNsdXNpdmUsIA0KPj4gbmFtZWx5DQo+PiA5IGZvciAvIHpl cm8gYWdhaW5zdCAvIDYgcGVyc29ucyBuZWVkIG1vcmUgaW5mb3JtYXRpb24uDQo+PiANCj4+IFlv dSBmZWVkYmFjayB3aWxsIHRoZXJlZm9yZSBiZSBpbXBvcnRhbnQgdG8gZmluZCBvdXQgd2hldGhl ciB3ZSANCj4+IHNob3VsZCBkbyB0aGlzIHdvcmsgaW4gdGhlIE9BdXRoIHdvcmtpbmcgZ3JvdXAu DQo+PiANCj4+IENpYW8NCj4+IEhhbm5lcyAmIERlcmVrDQo+PiANCj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBPQXV0aCBtYWlsaW5nIGxpc3QN Cj4+IE9BdXRoQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= From nobody Wed Jan 20 14:07:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DA21AD2B2 for ; Wed, 20 Jan 2016 14:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heaPO4uGwfEA for ; Wed, 20 Jan 2016 14:07:30 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 DD6D21AD2C0 for ; Wed, 20 Jan 2016 14:07:29 -0800 (PST) Received: by mail-qg0-x22d.google.com with SMTP id 6so17918087qgy.1 for ; Wed, 20 Jan 2016 14:07:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=MzQ1pKc4Nn6NkEzhzYhGPJFlXivNcPUqhEXNOJ3dOzU=; b=WafZxOHX6cMtnsnbUoiiqabODzE3Ydg+CwU91t8BViExLY0IPn+1sIdLnNLnxdLxhE PDt1nmhUmFACMZeWWmK0F1Et+AiQQiOkPCPa7fJmRQLm8aDTGOWjsYKWWRnYTvpck5V6 /hdMmxt5qgVR8VbI78TOEvuZ2XZ0x1nPMGqYO+VBA4lHP0oUC1ZrdpKkruUMSW7n1ahG CYERW/0mD56yadaTpyWPH2OcS3+HEppjWfLYuGPwRLPUQjdHGow+BcLH57EABSnEeCf2 tgsyJ5Fwr/LTPMzHPmUZF25v+RVb3BF2qGTk2lTms08rm/4+VQ+XwxBO0j1LKWnyIv8/ 7Brg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=MzQ1pKc4Nn6NkEzhzYhGPJFlXivNcPUqhEXNOJ3dOzU=; b=FHzw8SdTiDO7rJbBq/TS+r0ylnK1L2/4AYMqP7DH+dwVXOhETP9xOwIw0t1leUtnYl L3XMWtCl+BEwWMCFZ6DzSrm5TkqPnEk9VCRE+9mSDoYaAHrEl6bMB4HiwRGySQ8GMB4y 9KWjROTmw1Y1DtJvAHFIIghTKnkyJ4s1SQRI9YmIs8jnksuftUVCs/NuShJ9GL1tLMau TzEz41emlRirD2dkRwWOP3Z4wVj+I/SCXNHOplMz/PDo7SnhwGf1in48DTWRFdKjAD3/ WmDnrty56FJkeUi1ZNaHNWAfHfpxDe33rGBpfGjIjfbsy8+ABMAs0inLxebmYN958HGg qTtw== X-Gm-Message-State: ALoCoQlVinDiZcPcYJuFQafJII/ZlNkAsdMRWHhVUi2euEnHHsTxsyirCUZq0ypuptWNpZLZNJvXX3w85z4Ay/QzW9YD5cbTaQ== X-Received: by 10.140.35.115 with SMTP id m106mr47638671qgm.13.1453327649017; Wed, 20 Jan 2016 14:07:29 -0800 (PST) Received: from [192.168.8.101] ([181.202.164.7]) by smtp.gmail.com with ESMTPSA id s103sm15143560qge.3.2016.01.20.14.07.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 14:07:28 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_EBE9EE38-330B-44CE-BA96-C7372E3686D9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Wed, 20 Jan 2016 19:07:25 -0300 Message-Id: References: <569E2276.5070407@gmx.net> <8A2DAF46-BAF7-439D-8FE3-65EA2DA8E692@mit.edu> <47F7D0BA-8E98-4E37-BA84-D128C0FD8396@ve7jtb.com> To: Michael Jones X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 22:07:32 -0000 --Apple-Mail=_EBE9EE38-330B-44CE-BA96-C7372E3686D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 So if this is scoped to be a registry for the values of a JWT claim then = it is fine. We should discourage people from thinking that it is part of the OAuth = protocol vs JWT claims. John B. > On Jan 20, 2016, at 6:29 PM, Mike Jones = wrote: >=20 > The primary purpose of the specification is to establish a registry = for "amr" JWT claim values. This is important, as it increases = interoperability among implementations using this claim. >=20 > It's a fair question whether "requested_amr" should be kept or = dropped. I agree with John and James that it's bad architecture. I put = it in the -00 individual draft to document existing practice. I suspect = that should the draft is adopted by the working group as a starting = point, one of the first things the working group will want to decide is = whether to drop it. I suspect that I know how this will come out and I = won't be sad, architecturally, to see it go. >=20 > As to whether this belongs in the OAuth working group, long ago it was = decided that JWT and JWT claim definitions were within scope of the = OAuth working group. That ship has long ago sailed, both in terms of = RFC 7519 and it continues to sail, for instance, in = draft-ietf-oauth-proof-of-possession, which defines a new JWT claim, and = is in the RFC Editor Queue. Defining a registry for values of the "amr" = claim, which is registered in the OAuth-established registry at = http://www.iana.org/assignments/jwt, is squarely within the OAuth WG's = mission for the creation and stewardship of JWT. >=20 > -- Mike >=20 > -----Original Message----- > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Wednesday, January 20, 2016 12:44 PM > To: Justin Richer > Cc: > Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method = Reference Values >=20 > I see your point that it is a fine line reporting how a person = authenticated to a Authorization endpoit (it might be by SAML etc) and = encouraging people to use OAuth for Authentication. >=20 > We already have the amr response in connect. The only thing really = missing is a registry. Unless this is a sneaky way to get requested_amr = into Connect? >=20 > John B. >> On Jan 20, 2016, at 5:37 PM, Justin Richer wrote: >>=20 >> Just reiterating my stance that this document detailing user = authentication methods has no place in the OAuth working group. >>=20 >> =E2=80=94 Justin >>=20 >>> On Jan 19, 2016, at 6:48 AM, Hannes Tschofenig = wrote: >>>=20 >>> Hi all, >>>=20 >>> this is the call for adoption of Authentication Method Reference=20 >>> Values, see >>> https://tools.ietf.org/html/draft-jones-oauth-amr-values-03 >>>=20 >>> Please let us know by Feb 2nd whether you accept / object to the=20 >>> adoption of this document as a starting point for work in the OAuth=20= >>> working group. >>>=20 >>> Note: The feedback during the Yokohama meeting was inconclusive,=20 >>> namely >>> 9 for / zero against / 6 persons need more information. >>>=20 >>> You feedback will therefore be important to find out whether we=20 >>> should do this work in the OAuth working group. >>>=20 >>> Ciao >>> Hannes & Derek >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail=_EBE9EE38-330B-44CE-BA96-C7372E3686D9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMjAyMjA3MjZaMCMGCSqGSIb3DQEJBDEWBBTcibGZGTtOaBNj0vWG5XdA 4xamWjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQB/8A1/1ZnN6LebIUD+OFmZgDCDdHo4KE7X7dvPrBnmD8MMzQLzYPAE 1SPTmEW/LUqUMR2kRYpN/O+8pU6bu7JlJgKDsBLcVBLbZdk3YoOzB3vlV+nZsNaC0lwzGCRVjG1l HP5CViEezoY+4Ncbq4xH3soh51wv/5b2TKbZcRhUz2Wm6uxg8BfvW5pOOn4I8aMu9EMx1QqZDoa2 yi/k31E2r2YdQJtNjh2DgR1DHV//voJxQyhP18Ya9sTZHLYFvqJGrkUB980bMBUKUCxSd580WksM eddQUhwC/wIXxpHXEBipFGmUBN/Mao7VRVPpST0Rkzqu8Nn0YbNZ02IVTZ7CAAAAAAAA --Apple-Mail=_EBE9EE38-330B-44CE-BA96-C7372E3686D9-- From nobody Wed Jan 20 14:19:02 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC6B1AD371 for ; Wed, 20 Jan 2016 14:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuEEvenT-y41 for ; Wed, 20 Jan 2016 14:18:59 -0800 (PST) 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 B310C1AD36F for ; Wed, 20 Jan 2016 14:18:59 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id g73so35991533ioe.3 for ; Wed, 20 Jan 2016 14:18:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W7FxT5RGxHq5GBAZgZ2Ho6oxrmy98cn8JKIFheY6PPY=; b=OeYA0ZyE2jT51rFP6zxtAPtmwnidVHaeuBiMfjVmy63Dj8HdB4acQDkngESphr1sza fQNF2iM15KWJWjBI4D2jOMpfIpoU+jnBbySYrtbpU1HNfR7aSE5FWu1CfuneQmneRPDl /4V2Pa25ywmsJWobqnKVBwWFmVnaYa4XyKNuM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=W7FxT5RGxHq5GBAZgZ2Ho6oxrmy98cn8JKIFheY6PPY=; b=R37VL7lcKLc+G+JBqV1UYyRQxjCQRYbVYAaz0jKNG+I68m44KOclq/TW90MarCsnKd aEF4GE7f7j4WoCa1T9L8I1T/QscjIaUDaPGqVf/WXldkJCegTJn3jHkPVDSuMADelT3A YfWuTLuHbEJJsLi6aiPS9YSIFREYvgy1kIZ9kXbHFlHq3zvswOA7tisADPyt74Bz7Oeo h+tsUt7SITBEaQuIOWeH8p3vqaoBCHZVlJ/4HnygeNGg56FHSbV2oYoVkdYyuiR3Evbx 1bFaisp7Vow30cY9Vmzs50y8TgGbCPwKGwD2efyfEzQL160VP1HwXtj4A2VX1JBL5wxZ CLzA== X-Gm-Message-State: ALoCoQk3LJTXqievI92iSq9SO9Oy1PDnr451VcugbJX7/u9LdrCCRmI9oNYE0ZmqLDA8ZHYpPJIPbnkwknuXLmCdzvV1fB8fUhAwPi16zi3bAF1dHTn29Qc= X-Received: by 10.107.16.226 with SMTP id 95mr39808662ioq.147.1453328339032; Wed, 20 Jan 2016 14:18:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.212.69 with HTTP; Wed, 20 Jan 2016 14:18:29 -0800 (PST) In-Reply-To: <569F9955.9030001@gmx.net> References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> <569F60B3.3030501@gmail.com> <569F9955.9030001@gmx.net> From: Brian Campbell Date: Wed, 20 Jan 2016 15:18:29 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113ecda063f6bc0529cb5f09 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 22:19:01 -0000 --001a113ecda063f6bc0529cb5f09 Content-Type: text/plain; charset=UTF-8 There does seem to be a need to provide the client a means of telling the AS the place(s) and/or entity(s) where it intends to use the token it's asking for. And that it's common enough to warrant it's own small spec. This has come up several times before and I think has some consensus behind doing it. What needs to happen to move forward? The concept shows up in these three different drafts (that I know of anyway): https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 has an audience parameter https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3 has an aud parameter http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 has both an audience and a resource resource All the above apply only to the token request. However, there are ways of requesting/obtaining access tokens that don't involve the token endpoint so I think it follows that the same facility should be available for the authorization request too. On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Sergey, > > that's a good question. After this document was published the > functionality had been integrated into the PoP solution document. > Recently, I got feedback that the functionality should be more generic > and it is independent of the PoP work. > > So, I guess it is a good time to discuss the needed functionality and > where it should be included. > > Ciao > Hannes > > > On 01/20/2016 11:25 AM, Sergey Beryozkin wrote: > > Hi > > > > Given that the draft-tschofenig-oauth-audience [1] has expired, I'm > > wondering if it is still relevant. > > > > I know the token introspection response can provide the audience > > value(s), but the question is really how a client is associated with a a > > given audience in the first place. As such [1] may still make sense, for > > example, I can think of two options: > > 1. the client audiences are set out of band during the client > > registration time and all the tokens issued to that client will be > > restricted accordingly > > 2. the client is requesting a specific audience during the grant to > > token exchange as per [1] > > > > I guess 1. is how it is done in practice or is 2. is also a valid option > ? > > > > > > Thanks, Sergey > > > > > > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 > > > > _______________________________________________ > > 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 > > --001a113ecda063f6bc0529cb5f09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There does seem to be a need to provide the client a = means of telling the AS the place(s) and/or entity(s) where it intends to u= se the token it's asking for. And that it's common enough to warran= t it's own small spec. This has come up several times before and I thin= k has some consensus behind doing it. What needs to happen to move forward?=

The concept shows up in these three different drafts (that I = know of anyway):

https://tools.ietf= .org/html/draft-tschofenig-oauth-audience-00#section-3 has an audience = parameter
https://tools.ietf.org/html= /draft-ietf-oauth-pop-key-distribution-02#section-3 has an aud paramete= r
http://tools.ietf.org/html/draft-ietf-o= auth-token-exchange-03#section-2.1 has both an audience and a resource = resource

All the above apply only to the token request. However, the= re are ways of requesting/obtaining access tokens that don't invol= ve the token endpoint so I think it follows that=C2=A0 the same facilit= y should be available for the authorization request too.




On Wed, Jan 2= 0, 2016 at 7:27 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Sergey,

that's a good question. After this document was published the
functionality had been integrated into the PoP solution document.
Recently, I got feedback that the functionality should be more generic
and it is independent of the PoP work.

So, I guess it is a good time to discuss the needed functionality and
where it should be included.

Ciao
Hannes


On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
> Hi
>
> Given that the draft-tschofenig-oauth-audience [1] has expired, I'= m
> wondering if it is still relevant.
>
> I know the token introspection response can provide the audience
> value(s), but the question is really how a client is associated with a= a
> given audience in the first place. As such [1] may still make sense, f= or
> example, I can think of two options:
> 1. the client audiences are set out of band during the client
> registration time and all the tokens issued to that client will be
> restricted accordingly
> 2. the client is requesting a specific audience during the grant to > token exchange as per [1]
>
> I guess 1. is how it is done in practice or is 2. is also a valid opti= on ?
>
>
> Thanks, Sergey
>
>
> [1] https://tools.ietf.org/html/d= raft-tschofenig-oauth-audience-00
>
> _______________________________________________
> 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


--001a113ecda063f6bc0529cb5f09-- From nobody Wed Jan 20 14:25:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F471B29AD for ; Wed, 20 Jan 2016 14:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEpHlfYGd4rt for ; Wed, 20 Jan 2016 14:25:38 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB101B29AE for ; Wed, 20 Jan 2016 14:25:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jo8MxEaVI3BGRgTYHNzcaNjBPSW8MvUuMLnivmhJpio=; b=R7kZH5WcMnHYHFU0cnCfobg81uydq172DVpGz/mRPol2MYlUtqnUNPvCJhoP2kPLFrc1kN5lB6rsvZw6KDmjK1/tBOMfMqbp8ZRplqmuI1Zf4I/ca/ArNCMYbHJptbfLESkKeQALVFjUNvn6OCQubxqYw4sgj6iY6secmySzX7Y= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.365.19; Wed, 20 Jan 2016 22:25:35 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Wed, 20 Jan 2016 22:25:35 +0000 From: Mike Jones To: Brian Campbell , Hannes Tschofenig Thread-Topic: [OAUTH-WG] Status of draft-tschofenig-oauth-audience Thread-Index: AQHRU2z5bd5WDYhJ/0CRjTQN4ztm9p8EdoyAgACDlICAAAE0AA== Date: Wed, 20 Jan 2016 22:25:35 +0000 Message-ID: References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> <569F60B3.3030501@gmail.com> <569F9955.9030001@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: [2001:4898:80e8:2::37e] x-ms-office365-filtering-correlation-id: b4d5a5d6-778d-4e8e-04f6-08d321e89dd6 x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:ITk1+7V7X2fJspbRRfqCVmSuSBfR9sjj1p7r4giMauKdblO/AqKeHhwHLR4R2SMvKV5dnB+MRPqYFTn8/DyKzol4dW7fOzXDDzqjESJbfMxsMhR/lyhy43ZPEttbEenayXP/e/xK4qMUCH5RcWLm4A==; 24:A+0NvQAwjATxzPaUiJl9A3DkjBXEiXsMb9HRpM7q75gt+teWI7K1wM0MQRVBZORMTJVJjAItQvHiKFQ45KZbudut0Aa3nsYb2NaKxYkrgiI= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0827D7ACB9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(164054003)(189002)(377454003)(199003)(479174004)(87936001)(15975445007)(92566002)(106116001)(105586002)(19617315012)(19580405001)(5004730100002)(106356001)(8990500004)(54356999)(5008740100001)(10090500001)(19609705001)(5001960100002)(11100500001)(4326007)(2906002)(77096005)(5002640100001)(790700001)(1096002)(50986999)(19625215002)(76176999)(97736004)(10400500002)(102836003)(19580395003)(99286002)(586003)(2950100001)(10290500002)(33656002)(122556002)(5005710100001)(81156007)(16236675004)(40100003)(1220700001)(6116002)(101416001)(2900100001)(93886004)(5001770100001)(19300405004)(189998001)(86612001)(5003600100002)(86362001)(76576001)(74316001)(230783001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442A47609A3B5AD87169294F5C20BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2016 22:25:35.1831 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 22:25:40 -0000 --_000_BY2PR03MB442A47609A3B5AD87169294F5C20BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgbWVudGlvbmVkIGluIFByYWd1ZSwgQXp1cmUgQWN0aXZlIERpcmVjdG9yeSB1c2VzIGEg4oCc cmVzb3VyY2XigJ0gcmVxdWVzdCBwYXJhbWV0ZXIgdG8gc3VwcGx5IHRoZSBVUkwgb2YgdGhlIHJl c291cmNlIHNlcnZlciB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gaXMgaW50ZW5kZWQgZm9yLiAgSG93 ZXZlciwgSSBiZWxpZXZlIHRoYXQgR29vZ2xlIHVzZXMgc2NvcGUgdmFsdWVzIGZvciB0aGlzIGFu ZCBzb21lIE1pY3Jvc29mdCBzZXJ2aWNlcyBhcmUgbW92aW5nIHRvd2FyZHMgdXNpbmcgc2NvcGUg dmFsdWVzIGFzIHdlbGwuICBTb3J0aW5nIHRoaXMgb3V0IHNvb24gd291bGQgYmUgZ29vZC4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IFdlZG5lc2RheSwgSmFudWFy eSAyMCwgMjAxNiAyOjE4IFBNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcNCkNjOiBvYXV0aA0KU3Vi amVjdDogUmU6IFtPQVVUSC1XR10gU3RhdHVzIG9mIGRyYWZ0LXRzY2hvZmVuaWctb2F1dGgtYXVk aWVuY2UNCg0KVGhlcmUgZG9lcyBzZWVtIHRvIGJlIGEgbmVlZCB0byBwcm92aWRlIHRoZSBjbGll bnQgYSBtZWFucyBvZiB0ZWxsaW5nIHRoZSBBUyB0aGUgcGxhY2UocykgYW5kL29yIGVudGl0eShz KSB3aGVyZSBpdCBpbnRlbmRzIHRvIHVzZSB0aGUgdG9rZW4gaXQncyBhc2tpbmcgZm9yLiBBbmQg dGhhdCBpdCdzIGNvbW1vbiBlbm91Z2ggdG8gd2FycmFudCBpdCdzIG93biBzbWFsbCBzcGVjLiBU aGlzIGhhcyBjb21lIHVwIHNldmVyYWwgdGltZXMgYmVmb3JlIGFuZCBJIHRoaW5rIGhhcyBzb21l IGNvbnNlbnN1cyBiZWhpbmQgZG9pbmcgaXQuIFdoYXQgbmVlZHMgdG8gaGFwcGVuIHRvIG1vdmUg Zm9yd2FyZD8NClRoZSBjb25jZXB0IHNob3dzIHVwIGluIHRoZXNlIHRocmVlIGRpZmZlcmVudCBk cmFmdHMgKHRoYXQgSSBrbm93IG9mIGFueXdheSk6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC10c2Nob2ZlbmlnLW9hdXRoLWF1ZGllbmNlLTAwI3NlY3Rpb24tMyBoYXMgYW4g YXVkaWVuY2UgcGFyYW1ldGVyDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1vYXV0aC1wb3Ata2V5LWRpc3RyaWJ1dGlvbi0wMiNzZWN0aW9uLTMgaGFzIGFuIGF1ZCBwYXJh bWV0ZXINCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4t ZXhjaGFuZ2UtMDMjc2VjdGlvbi0yLjEgaGFzIGJvdGggYW4gYXVkaWVuY2UgYW5kIGEgcmVzb3Vy Y2UgcmVzb3VyY2UNCg0KQWxsIHRoZSBhYm92ZSBhcHBseSBvbmx5IHRvIHRoZSB0b2tlbiByZXF1 ZXN0LiBIb3dldmVyLCB0aGVyZSBhcmUgd2F5cyBvZiByZXF1ZXN0aW5nL29idGFpbmluZyBhY2Nl c3MgdG9rZW5zIHRoYXQgZG9uJ3QgaW52b2x2ZSB0aGUgdG9rZW4gZW5kcG9pbnQ8aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi00LjI+IHNvIEkgdGhpbmsgaXQgZm9s bG93cyB0aGF0ICB0aGUgc2FtZSBmYWNpbGl0eSBzaG91bGQgYmUgYXZhaWxhYmxlIGZvciB0aGUg YXV0aG9yaXphdGlvbiByZXF1ZXN0IHRvby4NCg0KDQoNCk9uIFdlZCwgSmFuIDIwLCAyMDE2IGF0 IDc6MjcgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PG1h aWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj4gd3JvdGU6DQpIaSBTZXJnZXksDQoNCnRo YXQncyBhIGdvb2QgcXVlc3Rpb24uIEFmdGVyIHRoaXMgZG9jdW1lbnQgd2FzIHB1Ymxpc2hlZCB0 aGUNCmZ1bmN0aW9uYWxpdHkgaGFkIGJlZW4gaW50ZWdyYXRlZCBpbnRvIHRoZSBQb1Agc29sdXRp b24gZG9jdW1lbnQuDQpSZWNlbnRseSwgSSBnb3QgZmVlZGJhY2sgdGhhdCB0aGUgZnVuY3Rpb25h bGl0eSBzaG91bGQgYmUgbW9yZSBnZW5lcmljDQphbmQgaXQgaXMgaW5kZXBlbmRlbnQgb2YgdGhl IFBvUCB3b3JrLg0KDQpTbywgSSBndWVzcyBpdCBpcyBhIGdvb2QgdGltZSB0byBkaXNjdXNzIHRo ZSBuZWVkZWQgZnVuY3Rpb25hbGl0eSBhbmQNCndoZXJlIGl0IHNob3VsZCBiZSBpbmNsdWRlZC4N Cg0KQ2lhbw0KSGFubmVzDQoNCg0KT24gMDEvMjAvMjAxNiAxMToyNSBBTSwgU2VyZ2V5IEJlcnlv emtpbiB3cm90ZToNCj4gSGkNCj4NCj4gR2l2ZW4gdGhhdCB0aGUgZHJhZnQtdHNjaG9mZW5pZy1v YXV0aC1hdWRpZW5jZSBbMV0gaGFzIGV4cGlyZWQsIEknbQ0KPiB3b25kZXJpbmcgaWYgaXQgaXMg c3RpbGwgcmVsZXZhbnQuDQo+DQo+IEkga25vdyB0aGUgdG9rZW4gaW50cm9zcGVjdGlvbiByZXNw b25zZSBjYW4gcHJvdmlkZSB0aGUgYXVkaWVuY2UNCj4gdmFsdWUocyksIGJ1dCB0aGUgcXVlc3Rp b24gaXMgcmVhbGx5IGhvdyBhIGNsaWVudCBpcyBhc3NvY2lhdGVkIHdpdGggYSBhDQo+IGdpdmVu IGF1ZGllbmNlIGluIHRoZSBmaXJzdCBwbGFjZS4gQXMgc3VjaCBbMV0gbWF5IHN0aWxsIG1ha2Ug c2Vuc2UsIGZvcg0KPiBleGFtcGxlLCBJIGNhbiB0aGluayBvZiB0d28gb3B0aW9uczoNCj4gMS4g dGhlIGNsaWVudCBhdWRpZW5jZXMgYXJlIHNldCBvdXQgb2YgYmFuZCBkdXJpbmcgdGhlIGNsaWVu dA0KPiByZWdpc3RyYXRpb24gdGltZSBhbmQgYWxsIHRoZSB0b2tlbnMgaXNzdWVkIHRvIHRoYXQg Y2xpZW50IHdpbGwgYmUNCj4gcmVzdHJpY3RlZCBhY2NvcmRpbmdseQ0KPiAyLiB0aGUgY2xpZW50 IGlzIHJlcXVlc3RpbmcgYSBzcGVjaWZpYyBhdWRpZW5jZSBkdXJpbmcgdGhlIGdyYW50IHRvDQo+ IHRva2VuIGV4Y2hhbmdlIGFzIHBlciBbMV0NCj4NCj4gSSBndWVzcyAxLiBpcyBob3cgaXQgaXMg ZG9uZSBpbiBwcmFjdGljZSBvciBpcyAyLiBpcyBhbHNvIGEgdmFsaWQgb3B0aW9uID8NCj4NCj4N Cj4gVGhhbmtzLCBTZXJnZXkNCj4NCj4NCj4gWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC10c2Nob2ZlbmlnLW9hdXRoLWF1ZGllbmNlLTAwDQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0K PiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5v cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQo= --_000_BY2PR03MB442A47609A3B5AD87169294F5C20BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgbWVudGlvbmVkIGlu IFByYWd1ZSwgQXp1cmUgQWN0aXZlIERpcmVjdG9yeSB1c2VzIGEg4oCccmVzb3VyY2XigJ0gcmVx dWVzdCBwYXJhbWV0ZXIgdG8gc3VwcGx5IHRoZSBVUkwgb2YgdGhlIHJlc291cmNlIHNlcnZlciB0 aGF0IHRoZSBhY2Nlc3MgdG9rZW4gaXMgaW50ZW5kZWQNCiBmb3IuJm5ic3A7IEhvd2V2ZXIsIEkg YmVsaWV2ZSB0aGF0IEdvb2dsZSB1c2VzIHNjb3BlIHZhbHVlcyBmb3IgdGhpcyBhbmQgc29tZSBN aWNyb3NvZnQgc2VydmljZXMgYXJlIG1vdmluZyB0b3dhcmRzIHVzaW5nIHNjb3BlIHZhbHVlcyBh cyB3ZWxsLiZuYnNwOyBTb3J0aW5nIHRoaXMgb3V0IHNvb24gd291bGQgYmUgZ29vZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAyMCwgMjAxNiAyOjE4IFBNPGJyPg0KPGI+ VG86PC9iPiBIYW5uZXMgVHNjaG9mZW5pZzxicj4NCjxiPkNjOjwvYj4gb2F1dGg8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gU3RhdHVzIG9mIGRyYWZ0LXRzY2hvZmVuaWctb2F1 dGgtYXVkaWVuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGVyZSBkb2VzIHNlZW0gdG8gYmUgYSBuZWVk IHRvIHByb3ZpZGUgdGhlIGNsaWVudCBhIG1lYW5zIG9mIHRlbGxpbmcgdGhlIEFTIHRoZSBwbGFj ZShzKSBhbmQvb3IgZW50aXR5KHMpIHdoZXJlIGl0IGludGVuZHMgdG8gdXNlIHRoZSB0b2tlbiBp dCdzIGFza2luZyBmb3IuIEFuZCB0aGF0IGl0J3MgY29tbW9uIGVub3VnaCB0byB3YXJyYW50IGl0 J3Mgb3duIHNtYWxsDQogc3BlYy4gVGhpcyBoYXMgY29tZSB1cCBzZXZlcmFsIHRpbWVzIGJlZm9y ZSBhbmQgSSB0aGluayBoYXMgc29tZSBjb25zZW5zdXMgYmVoaW5kIGRvaW5nIGl0LiBXaGF0IG5l ZWRzIHRvIGhhcHBlbiB0byBtb3ZlIGZvcndhcmQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjb25jZXB0IHNob3dzIHVwIGluIHRoZXNlIHRocmVlIGRp ZmZlcmVudCBkcmFmdHMgKHRoYXQgSSBrbm93IG9mIGFueXdheSk6PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5p Zy1vYXV0aC1hdWRpZW5jZS0wMCNzZWN0aW9uLTMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5jZS0wMCNzZWN0 aW9uLTM8L2E+IGhhcyBhbiBhdWRpZW5jZSBwYXJhbWV0ZXINCjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1rZXktZGlzdHJpYnV0 aW9uLTAyI3NlY3Rpb24tMyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW9hdXRoLXBvcC1rZXktZGlzdHJpYnV0aW9uLTAyI3NlY3Rpb24tMzwv YT4gaGFzIGFuIGF1ZCBwYXJhbWV0ZXINCjxicj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDMjc2VjdGlvbi0yLjEi IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9h dXRoLXRva2VuLWV4Y2hhbmdlLTAzI3NlY3Rpb24tMi4xPC9hPiBoYXMgYm90aCBhbiBhdWRpZW5j ZSBhbmQgYSByZXNvdXJjZSByZXNvdXJjZTxicj4NCjxicj4NCkFsbCB0aGUgYWJvdmUgYXBwbHkg b25seSB0byB0aGUgdG9rZW4gcmVxdWVzdC4gSG93ZXZlciwgdGhlcmUgYXJlIDxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tNC4yIiB0YXJnZXQ9Il9i bGFuayI+DQp3YXlzIG9mIHJlcXVlc3Rpbmcvb2J0YWluaW5nIGFjY2VzcyB0b2tlbnMgdGhhdCBk b24ndCBpbnZvbHZlIHRoZSB0b2tlbiBlbmRwb2ludDwvYT4gc28gSSB0aGluayBpdCBmb2xsb3dz IHRoYXQmbmJzcDsgdGhlIHNhbWUgZmFjaWxpdHkgc2hvdWxkIGJlIGF2YWlsYWJsZSBmb3IgdGhl IGF1dGhvcml6YXRpb24gcmVxdWVzdCB0b28uDQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSmFuIDIwLCAyMDE2 IGF0IDc6MjcgQU0sIEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJtYWlsdG86aGFubmVz LnRzY2hvZmVuaWdAZ214Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmhhbm5lcy50c2Nob2ZlbmlnQGdt eC5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIFNlcmdleSw8YnI+DQo8YnI+DQp0aGF0J3MgYSBnb29kIHF1ZXN0aW9uLiBBZnRlciB0aGlz IGRvY3VtZW50IHdhcyBwdWJsaXNoZWQgdGhlPGJyPg0KZnVuY3Rpb25hbGl0eSBoYWQgYmVlbiBp bnRlZ3JhdGVkIGludG8gdGhlIFBvUCBzb2x1dGlvbiBkb2N1bWVudC48YnI+DQpSZWNlbnRseSwg SSBnb3QgZmVlZGJhY2sgdGhhdCB0aGUgZnVuY3Rpb25hbGl0eSBzaG91bGQgYmUgbW9yZSBnZW5l cmljPGJyPg0KYW5kIGl0IGlzIGluZGVwZW5kZW50IG9mIHRoZSBQb1Agd29yay48YnI+DQo8YnI+ DQpTbywgSSBndWVzcyBpdCBpcyBhIGdvb2QgdGltZSB0byBkaXNjdXNzIHRoZSBuZWVkZWQgZnVu Y3Rpb25hbGl0eSBhbmQ8YnI+DQp3aGVyZSBpdCBzaG91bGQgYmUgaW5jbHVkZWQuPGJyPg0KPGJy Pg0KQ2lhbzxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5IYW5uZXM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KT24gMDEvMjAvMjAxNiAxMToyNSBBTSwg U2VyZ2V5IEJlcnlvemtpbiB3cm90ZTo8YnI+DQomZ3Q7IEhpPGJyPg0KJmd0Ozxicj4NCiZndDsg R2l2ZW4gdGhhdCB0aGUgZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5jZSBbMV0gaGFzIGV4 cGlyZWQsIEknbTxicj4NCiZndDsgd29uZGVyaW5nIGlmIGl0IGlzIHN0aWxsIHJlbGV2YW50Ljxi cj4NCiZndDs8YnI+DQomZ3Q7IEkga25vdyB0aGUgdG9rZW4gaW50cm9zcGVjdGlvbiByZXNwb25z ZSBjYW4gcHJvdmlkZSB0aGUgYXVkaWVuY2U8YnI+DQomZ3Q7IHZhbHVlKHMpLCBidXQgdGhlIHF1 ZXN0aW9uIGlzIHJlYWxseSBob3cgYSBjbGllbnQgaXMgYXNzb2NpYXRlZCB3aXRoIGEgYTxicj4N CiZndDsgZ2l2ZW4gYXVkaWVuY2UgaW4gdGhlIGZpcnN0IHBsYWNlLiBBcyBzdWNoIFsxXSBtYXkg c3RpbGwgbWFrZSBzZW5zZSwgZm9yPGJyPg0KJmd0OyBleGFtcGxlLCBJIGNhbiB0aGluayBvZiB0 d28gb3B0aW9uczo8YnI+DQomZ3Q7IDEuIHRoZSBjbGllbnQgYXVkaWVuY2VzIGFyZSBzZXQgb3V0 IG9mIGJhbmQgZHVyaW5nIHRoZSBjbGllbnQ8YnI+DQomZ3Q7IHJlZ2lzdHJhdGlvbiB0aW1lIGFu ZCBhbGwgdGhlIHRva2VucyBpc3N1ZWQgdG8gdGhhdCBjbGllbnQgd2lsbCBiZTxicj4NCiZndDsg cmVzdHJpY3RlZCBhY2NvcmRpbmdseTxicj4NCiZndDsgMi4gdGhlIGNsaWVudCBpcyByZXF1ZXN0 aW5nIGEgc3BlY2lmaWMgYXVkaWVuY2UgZHVyaW5nIHRoZSBncmFudCB0bzxicj4NCiZndDsgdG9r ZW4gZXhjaGFuZ2UgYXMgcGVyIFsxXTxicj4NCiZndDs8YnI+DQomZ3Q7IEkgZ3Vlc3MgMS4gaXMg aG93IGl0IGlzIGRvbmUgaW4gcHJhY3RpY2Ugb3IgaXMgMi4gaXMgYWxzbyBhIHZhbGlkIG9wdGlv biA/PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYW5rcywgU2VyZ2V5PGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFsxXSA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5jZS0wMCIgdGFyZ2V0PSJfYmxhbmsi Pg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRzY2hvZmVuaWctb2F1dGgtYXVk aWVuY2UtMDA8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4N CiZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1 dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY2PR03MB442A47609A3B5AD87169294F5C20BY2PR03MB442namprd_-- From nobody Wed Jan 20 14:27:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892281B29AF for ; Wed, 20 Jan 2016 14:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8w7LwOLd2viq for ; Wed, 20 Jan 2016 14:27:16 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD57E1B29AE for ; Wed, 20 Jan 2016 14:27:15 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id s68so9147737qkh.3 for ; Wed, 20 Jan 2016 14:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=n1dP9e83BhJ0fs6yLLNa8phIENZYUlacfJWinfj9jMA=; b=yHy5GtklYTqkObIKZxUDjJm++pBgwVpnAqT7UBn4eh6TwONYHmO2YLTNHnecuAt7zx h1ygO8SbbL469Cd44iMEhtlSwAgcCYEq/h7VnSVlt1tM+7WUEZzVuzS8jcBZS//vxMZf x8eMMxQBVeIS35fiac8UodZi0GjV5HASsY7HuCElkiSqGJQ5VAAmSFuNAgLElrolnq+l cBTt9yShz4f6iEzEbiY+TyQIu1M0S2uhqJm0r0hHz1zAqeKMiKaRIQL2IoGZ8HVFFvt0 2W2LD+c+6wkQMW7h3/hQc7k/6vCnLqDPTw6baoWwRKqm6o3WgyF6jRhSjumanUAMCBQM BCpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=n1dP9e83BhJ0fs6yLLNa8phIENZYUlacfJWinfj9jMA=; b=TyzuJpNM8k1Mwk++C/HJTbrujRRZ/wO5pjrfk6HtxiSB54wVilwQr3B2S5nM+AtJoS mBtho+FpDtDQNPrG+dcwQY3krd1EeSRO5Mhz9VHru7C/u1gwPCvAUAMm0noQ2+iInhAs gETJnSP+OLMD8CmBKg+T9wUZnTxqhfTrF5UKEfkrFOLhU1Joy6+NNoLYbiJUxbM8OtN4 ZKytbS5deGrVvcw1poyRrkTSt4LZqpgjLMx7R4V9qi0DOmxcfDLsADoG9KouwW72kQdx kpVNprTojw7ciXHAlyNTeT+cW0TziBXae36L2UTM4nk0qaRx/AAYweUGZEYTzrNIkumt N/ew== X-Gm-Message-State: ALoCoQkDWBLkInWAtv0ff3o/eKKPIQviGVtrsl85iPPjfHKf6OAkJUk6YcHb/g4GndGXf4n5d3K5zg67OkT0Lx1kUu9VEG5ltg== X-Received: by 10.55.76.84 with SMTP id z81mr47785558qka.17.1453328834856; Wed, 20 Jan 2016 14:27:14 -0800 (PST) Received: from [192.168.8.101] ([181.202.164.7]) by smtp.gmail.com with ESMTPSA id t10sm12561862qhc.1.2016.01.20.14.27.13 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 14:27:14 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_B130B023-EDFA-4676-8365-96A637C2C120"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Wed, 20 Jan 2016 19:27:09 -0300 Message-Id: <1D483C18-6103-4197-9AF0-D4FD80E8F17E@ve7jtb.com> References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> <569F60B3.3030501@gmail.com> <569F9955.9030001@gmx.net> To: Michael Jones X-Mailer: Apple Mail (2.3112) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 22:27:18 -0000 --Apple-Mail=_B130B023-EDFA-4676-8365-96A637C2C120 Content-Type: multipart/alternative; boundary="Apple-Mail=_BFB085DA-A03A-4A5E-95F7-9F31DFF6C46C" --Apple-Mail=_BFB085DA-A03A-4A5E-95F7-9F31DFF6C46C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > On Jan 20, 2016, at 7:25 PM, Mike Jones = wrote: >=20 > As mentioned in Prague, Azure Active Directory uses a =E2=80=9Cresource=E2= =80=9D request parameter to supply the URL of the resource server that = the access token is intended for. However, I believe that Google uses = scope values for this and some Microsoft services are moving towards = using scope values as well. Sorting this out soon would be good. > =20 > -- = Mike > =20 > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Brian Campbell > Sent: Wednesday, January 20, 2016 2:18 PM > To: Hannes Tschofenig > Cc: oauth > Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience > =20 > There does seem to be a need to provide the client a means of telling = the AS the place(s) and/or entity(s) where it intends to use the token = it's asking for. And that it's common enough to warrant it's own small = spec. This has come up several times before and I think has some = consensus behind doing it. What needs to happen to move forward? >=20 > The concept shows up in these three different drafts (that I know of = anyway): >=20 > = https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 = = has an audience parameter=20 > = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#secti= on-3 = has an aud parameter=20 > = http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 = has both an audience and a resource resource >=20 > All the above apply only to the token request. However, there are ways = of requesting/obtaining access tokens that don't involve the token = endpoint so I think it = follows that the same facility should be available for the = authorization request too.=20 >=20 >=20 >=20 > =20 > On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig = > wrote: > Hi Sergey, >=20 > that's a good question. After this document was published the > functionality had been integrated into the PoP solution document. > Recently, I got feedback that the functionality should be more generic > and it is independent of the PoP work. >=20 > So, I guess it is a good time to discuss the needed functionality and > where it should be included. >=20 > Ciao > Hannes >=20 >=20 > On 01/20/2016 11:25 AM, Sergey Beryozkin wrote: > > Hi > > > > Given that the draft-tschofenig-oauth-audience [1] has expired, I'm > > wondering if it is still relevant. > > > > I know the token introspection response can provide the audience > > value(s), but the question is really how a client is associated with = a a > > given audience in the first place. As such [1] may still make sense, = for > > example, I can think of two options: > > 1. the client audiences are set out of band during the client > > registration time and all the tokens issued to that client will be > > restricted accordingly > > 2. the client is requesting a specific audience during the grant to > > token exchange as per [1] > > > > I guess 1. is how it is done in practice or is 2. is also a valid = option ? > > > > > > Thanks, Sergey > > > > > > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 = > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_BFB085DA-A03A-4A5E-95F7-9F31DFF6C46C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

On Jan 20, 2016, at 7:25 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

As = mentioned in Prague, Azure Active Directory uses a =E2=80=9Cresource=E2=80= =9D request parameter to supply the URL of the resource server that the = access token is intended for.  However, I believe that Google uses = scope values for this and some Microsoft services are moving towards = using scope values as well.  Sorting this out soon would be = good.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf = Of Brian = Campbell
Sent: Wednesday, January 20, 2016 = 2:18 PM
To: Hannes Tschofenig
Cc: oauth
Subject: Re: [OAUTH-WG] Status of = draft-tschofenig-oauth-audience
 

There = does seem to be a need to provide the client a means of telling the AS = the place(s) and/or entity(s) where it intends to use the token it's = asking for. And that it's common enough to warrant it's own small spec. = This has come up several times before and I think has some consensus = behind doing it. What needs to happen to move forward?

The = concept shows up in these three different drafts (that I know of = anyway):


https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#= section-3 has an = audience parameter 
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi= on-02#section-3 has = an aud parameter 
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#s= ection-2.1 has = both an audience and a resource resource

All = the above apply only to the token request. However, there are ways of = requesting/obtaining access tokens that don't involve the token = endpoint so I = think it follows that  the same facility should be available for = the authorization request too. 


 
On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi = Sergey,

that's a good question. After this = document was published the
functionality had been = integrated into the PoP solution document.
Recently, I got = feedback that the functionality should be more generic
and = it is independent of the PoP work.

So, I = guess it is a good time to discuss the needed functionality and
where it should be included.

Ciao
Hannes



On 01/20/2016 11:25 AM, Sergey Beryozkin = wrote:
> Hi
>
> Given = that the draft-tschofenig-oauth-audience [1] has expired, I'm
> wondering if it is still relevant.
>
> I know the token introspection response can provide the = audience
> value(s), but the question is really how a = client is associated with a a
> given audience in the = first place. As such [1] may still make sense, for
> = example, I can think of two options:
> 1. the client = audiences are set out of band during the client
> = registration time and all the tokens issued to that client will be
> restricted accordingly
> 2. the client = is requesting a specific audience during the grant to
> = token exchange as per [1]
>
> I guess = 1. is how it is done in practice or is 2. is also a valid option ?
>
>
> Thanks, Sergey
>
>
> [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00<= /a>
>
> = _______________________________________________
> 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=_BFB085DA-A03A-4A5E-95F7-9F31DFF6C46C-- --Apple-Mail=_B130B023-EDFA-4676-8365-96A637C2C120 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMjAyMjI3MTBaMCMGCSqGSIb3DQEJBDEWBBTO62znuVUNxufSpi26/SZv Z8uW+jCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBKF3dWSiTts9CCIFIfZy/5knnXw8HU3u/wlSnJaYU0NjG/hrcAjXYJ YD4gyGGrVfmpdvlESGuC7mEFWzbQnrihYJJPKo/Uwdk0ceN9SGGL/KZBIbsEhGnrVbeV5UE2QpKw dstAcY2oUiRmR3SbR9lDCxhcl2X19u2376cRM6FVIzw3z4iopMbxEJWFDZQhE3UNFec81x22diX+ Cx3LLcRk0g/ZTjWgnO9MGYz2vYQ808QFSG6rBgSUugsEk+o3qx4rulRvy4Vkv5EQrLdsi3hzLyia 2TwxRdIAVpZEWA/XJx0dqTOyKgfeNfWhwhF+AL8BU3ToEARk0OiuxrCVNSF0AAAAAAAA --Apple-Mail=_B130B023-EDFA-4676-8365-96A637C2C120-- From nobody Wed Jan 20 14:43:05 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EC51B2A1F for ; Wed, 20 Jan 2016 14:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUz_pi__iWYT for ; Wed, 20 Jan 2016 14:43:02 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 7C8EC1B2A1A for ; Wed, 20 Jan 2016 14:43:00 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id g73so36560172ioe.3 for ; Wed, 20 Jan 2016 14:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1tgaoBy1zkyGN9iiF2QPhLkdGZzDvZn/syEVe108mCE=; b=gWFGre85VT08M8QJbWWQ3aB1FGlIldgsckSeIkVNduAiiYbJIqdiVgovW/3nNB1882 MhfNeXl6dK4YtHnZnLrP2GmtFC5fezVXRaPoaVTGkey+kVwhrYk/To4pAEt09jRDfKG5 XuwB+7U1JKqHmxQdSJasjlb65QlJD0SQXPe48= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1tgaoBy1zkyGN9iiF2QPhLkdGZzDvZn/syEVe108mCE=; b=Zg3j60DCsiMKEQl/Mlm31yrxrh12qspenGIToEErRP4pL7W83oRDDrp70OJ+WB6LfI FMDSNdXAw8UBpnghbfHLGMHXbBsZHqSW8UBMFSOIUDViEDZ4bqbvRvr2cXcwQ4dJHWhc 2HSlZ9/9HNuyvWfWvwYy0raR3Nvmt4kaqw1XwllXDTC6G+ujtdj9XiUh75x/MGJuug0G Bf1nGX57NfHh/epUlkeUW4pnKfFCJTHPoukFUDs94htGEdL37JLaW6Q4bdYm4YVx2V1v OoW+csKu705/BBrtu6VYmLZTiC/loCZ65uuIxJN0Sxml2Vc2lvmTXbR415Eq4hHAJBwt Gq2w== X-Gm-Message-State: ALoCoQl4dFuXEIU5/26e2551susViM+wqsTXkl05knOJIRNT3XrbIA39IcPzKmc2JBFlAz4JtGETGI8pTxFwLpe1WqWH2gAnDWKMztcDLpDnBgfoaUlJTHg= X-Received: by 10.107.16.226 with SMTP id 95mr39894710ioq.147.1453329779899; Wed, 20 Jan 2016 14:42:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.212.69 with HTTP; Wed, 20 Jan 2016 14:42:30 -0800 (PST) In-Reply-To: <569E22E1.5010402@gmx.net> References: <569E22E1.5010402@gmx.net> From: Brian Campbell Date: Wed, 20 Jan 2016 15:42:30 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113ecda045cd140529cbb5bd Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 22:43:03 -0000 --001a113ecda045cd140529cbb5bd Content-Type: text/plain; charset=UTF-8 I conditionally accept this document as a starting point for work in the OAuth working group on the assumption that the considerable simplifications discussed and accepted at http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html will be incorporated. This document is (should be) intended to provide a mitigation to a security problem. As such, it would be nice to see it progress a little faster than the typical WG document. The more quickly the document can progress and/or be perceived as stable, the better. On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see > https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 > > Please let us know by Feb 9th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Note: This call is related to the announcement made on the list earlier > this month, see > http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More > time for analysis is provided due to the complexity of the topic. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a113ecda045cd140529cbb5bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I conditionally accept this document as a starting po= int for work in the OAuth working group on the assumption that the consider= able simplifications discussed and accepted at http://w= ww.ietf.org/mail-archive/web/oauth/current/msg15351.html will be incorp= orated.

This document is (should be) intended to provide = a mitigation to a security problem. As such, it would be nice to see it pro= gress a little faster than the typical WG document. The more quickly the do= cument can progress and/or be perceived as stable, the better.

On Tue, Jan 19= , 2016 at 4:49 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
https://tools.ietf.org/html/draft-= jones-oauth-mix-up-mitigation-00

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

Note: This call is related to the announcement made on the list earlier
this month, see
http://www.ietf.org/mail-archive/web= /oauth/current/msg15336.html. More
time for analysis is provided due to the complexity of the topic.

Ciao
Hannes & Derek


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


--001a113ecda045cd140529cbb5bd-- From nobody Wed Jan 20 14:47:31 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7271B2A37 for ; Wed, 20 Jan 2016 14:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jza3yLsSBZvp for ; Wed, 20 Jan 2016 14:47:27 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 761741B2A36 for ; Wed, 20 Jan 2016 14:47:27 -0800 (PST) Received: by mail-qg0-x22d.google.com with SMTP id 6so18649835qgy.1 for ; Wed, 20 Jan 2016 14:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=EyYrHu2K2OVVoAQRFZenKaj/Mg7HNWCZeYUsLARLGgw=; b=L1zlOvP7QWe5hwomA07m4jaexKEQr/LXNAsQ0ZTOn4wb/a/SDDxjD3rzynCavP7UKb pfFAwzkszCfzNISPY//qX2OPqaO7aFjNdU/IHp6JOElTbRRP7a0el72l2/+tg/Bxj3L0 6XG35EH8esexEpNj6D5/pXdMwTGTzmHcBBRmhSL1R1ppS0F4COAeC11H/1COsXSmrHiL ym+XBBgfHxo1d8AMdFtilCrwJKzgqvIM3r1E4UgTLYqkCbA7WTQjfZC33A8Y1o72vATk aNeU0FRH1if1jMN0K4x1SVnJdErCHJr92A/4lV9DgYPWQVah1HZg1ppcSfFpTy4SaVed xwYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=EyYrHu2K2OVVoAQRFZenKaj/Mg7HNWCZeYUsLARLGgw=; b=e9yWVWe+Aes0OeIOwtzVSiSiRNKoe0YvIs1+Sve+uhtyzaMyOOT0qTn+QOWR5Wqt5a 2OOfN264jftK8OadQlsecIgSrqe8gSHbKJL+UkActWPIBowI+BCW0USX0fndaShjmoGp w8Jqp8kxgX8BQRpvmLJ+LaBVUgJWWztUDO9bfHMII3bYBlM1AlkFNDn0G8E5QfdRr0IQ rqEoVc69wn0/yPMzkduISkjybrDMXV2/plFrJMv3W5bXaQG9pI41N+crTdGnlOwuF+e6 flWdrUzIDnG76O3sSepofQsEpgW3yxI8nzDvbHeH7i/4zpEwPYSO27HGRLG8K8mUnrIB rX0Q== X-Gm-Message-State: ALoCoQm/m6rc80aE9ja4klyDlrCXLZ0IdXjYR9qRbta2x9vwwekKSWfDP75ty2Gp4QnXSGC7zi14vknR30SfuZ40+ce3Mk0Dng== X-Received: by 10.140.18.136 with SMTP id 8mr48067303qgf.64.1453330046665; Wed, 20 Jan 2016 14:47:26 -0800 (PST) MIME-Version: 1.0 References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> <569F60B3.3030501@gmail.com> <569F9955.9030001@gmx.net> <1D483C18-6103-4197-9AF0-D4FD80E8F17E@ve7jtb.com> In-Reply-To: <1D483C18-6103-4197-9AF0-D4FD80E8F17E@ve7jtb.com> From: Nat Sakimura Date: Wed, 20 Jan 2016 22:47:17 +0000 Message-ID: To: John Bradley , Michael Jones Content-Type: multipart/alternative; boundary=001a113546422c49ed0529cbc57a Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 22:47:30 -0000 --001a113546422c49ed0529cbc57a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Also, I have always thought that it would be good if one could ask for a particular resource type, and the server could respond with the actual location of it with the associated access token. This is because it is often undesirable to tell the client the location of the resource before the authorization from the privacy point of view. So, the processing flow in this case will be: 1. The client request an access to the resource type in the scope of the authorization request. 2. The client request an access token to the resource type to the token endpoint with audience/resource/scope parameter. 3. The token endpoint responds with token response with oauth-meta header indicating the URL of the resource as in draft-sakimura-oauth-meta. Best, Nat 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 7:27 John Bradley : > +1 > > On Jan 20, 2016, at 7:25 PM, Mike Jones > wrote: > > As mentioned in Prague, Azure Active Directory uses a =E2=80=9Cresource= =E2=80=9D request > parameter to supply the URL of the resource server that the access token = is > intended for. However, I believe that Google uses scope values for this > and some Microsoft services are moving towards using scope values as well= . > Sorting this out soon would be good. > > -- Mike > > *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O= n > Behalf Of *Brian Campbell > *Sent:* Wednesday, January 20, 2016 2:18 PM > *To:* Hannes Tschofenig > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience > > > There does seem to be a need to provide the client a means of telling the > AS the place(s) and/or entity(s) where it intends to use the token it's > asking for. And that it's common enough to warrant it's own small spec. > This has come up several times before and I think has some consensus behi= nd > doing it. What needs to happen to move forward? > The concept shows up in these three different drafts (that I know of > anyway): > > > https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 = has > an audience parameter > > https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#sect= ion-3 > has an aud parameter > http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1= has > both an audience and a resource resource > > All the above apply only to the token request. However, there are ways of > requesting/obtaining access tokens that don't involve the token endpoint > so I think it follows > that the same facility should be available for the authorization request > too. > > > > On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > Hi Sergey, > > that's a good question. After this document was published the > functionality had been integrated into the PoP solution document. > Recently, I got feedback that the functionality should be more generic > and it is independent of the PoP work. > > So, I guess it is a good time to discuss the needed functionality and > where it should be included. > > Ciao > Hannes > > > > On 01/20/2016 11:25 AM, Sergey Beryozkin wrote: > > Hi > > > > Given that the draft-tschofenig-oauth-audience [1] has expired, I'm > > wondering if it is still relevant. > > > > I know the token introspection response can provide the audience > > value(s), but the question is really how a client is associated with a = a > > given audience in the first place. As such [1] may still make sense, fo= r > > example, I can think of two options: > > 1. the client audiences are set out of band during the client > > registration time and all the tokens issued to that client will be > > restricted accordingly > > 2. the client is requesting a specific audience during the grant to > > token exchange as per [1] > > > > I guess 1. is how it is done in practice or is 2. is also a valid optio= n > ? > > > > > > Thanks, Sergey > > > > > > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 > > > > _______________________________________________ > > 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 > --001a113546422c49ed0529cbc57a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Also, I have always thought that it = would be good if one could ask for a particular resource type, and the serv= er could respond with the actual location of it with the associated access = token. This is because it is often undesirable to tell the client the locat= ion of the resource before the authorization from the privacy point of view= .=C2=A0

So, the processing flow in this case will = be:=C2=A0

  1. = The client request an access to the resource type in the scope of the autho= rization request.=C2=A0
  2. = The client request an access token to the resource type to the token endpoi= nt with audience/resource/scope parameter.=C2=A0
  3. The token endpoint responds with token response wi= th oauth-meta header indicating the URL of the resource as in=C2=A0<= span style=3D"line-height:1.5">=C2=A0draft-sakimura-oauth-meta.=C2=A0
Best,=C2=A0

Nat


2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6= =9C=A8) 7:27 John Bradley <ve7jtb@v= e7jtb.com>:
+1

On Jan 20, 2016, at 7:25 PM, Mike Jones &= lt;Michael= .Jones@microsoft.com> wrote:

As mentioned in Prague, Azure Active Directory uses a =E2=80=9Cresource=E2= =80=9D request parameter to supply the URL of the resource server that the = access token is intended for.=C2=A0 However, I believe that Google uses sco= pe values for this and some Microsoft services are moving towards using sco= pe values as well.=C2=A0 Sorting this out soon would be good.=
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
=C2=A0
Fro= m:<= span>=C2=A0OAuth [mailto:oauth-bou= nces@ietf.org]=C2=A0On Behalf Of=C2=A0= Brian Campbell
Sent:=C2=A0Wednesday, January 20, 201= 6 2:18 PM
To:=C2=A0Hannes Tschofenig
Cc:=C2=A0oauth
Subject:=C2=A0Re: [OAUTH-WG] = Status of draft-tschofenig-oauth-audience
=C2=A0

There does seem to be a need to provide the client a means of= telling the AS the place(s) and/or entity(s) where it intends to use the t= oken it's asking for. And that it's common enough to warrant it'= ;s own small spec. This has come up several times before and I think has so= me consensus behind doing it. What needs to happen to move forward?<= u>

The concept shows up in these three = different drafts (that I know of anyway):


https://tools.ietf.org/html/draft-tschof= enig-oauth-audience-00#section-3=C2=A0has an audience para= meter=C2=A0
https://tools.ietf.org/html/draft-ietf-= oauth-pop-key-distribution-02#section-3=C2=A0has an aud pa= rameter=C2=A0
http://tools.ietf.org/html/draft-ietf-oaut= h-token-exchange-03#section-2.1=C2=A0has both an audience = and a resource resource

All the above apply only to the token reques= t. However, there are=C2=A0ways of requesting/obtaining access tokens that don't = involve the token endpoint=C2=A0so I think it follows that= =C2=A0 the same facility should be available for the authorization request = too.=C2=A0


=C2=A0
On Wed, = Jan 20, 2016 at 7:27 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Sergey,

that's a good question. After this d= ocument was published the
functionality had been integrated into the PoP= solution document.
Recently, I got feedback that the functionality shou= ld be more generic
and it is independent of the PoP work.

So, I g= uess it is a good time to discuss the needed functionality and
where it = should be included.

Ciao
H= annes



On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
> Hi
&= gt;
> Given that the draft-tschofenig-oauth-audience [1] has expired,= I'm
> wondering if it is still relevant.
>
> I know = the token introspection response can provide the audience
> value(s),= but the question is really how a client is associated with a a
> giv= en audience in the first place. As such [1] may still make sense, for
&g= t; example, I can think of two options:
> 1. the client audiences are= set out of band during the client
> registration time and all the to= kens issued to that client will be
> restricted accordingly
> 2= . the client is requesting a specific audience during the grant to
> = token exchange as per [1]
>
> I guess 1. is how it is done in p= ractice or is 2. is also a valid option ?
>
>
> Thanks, S= ergey
>
>
> [1]=C2=A0https://tools.ietf.org/html/dra= ft-tschofenig-oauth-audience-00
>
> _______________________= ________________________
> OAuth mailing list
>=C2=A0OAuth@ietf.org
>=C2=A0<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" style=3D"color:purpl= e;text-decoration:underline" target=3D"_blank">https://www.ietf.org/mailman= /listinfo/oauth


_______________________________________________
OAuth mai= ling list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oau= th

=C2=A0
_____________________= __________________________
OAuth mailing li= st
OAuth@ietf.org
https://www.ietf.org/mailm= an/listinfo/oauth

_____________= __________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a113546422c49ed0529cbc57a-- From nobody Wed Jan 20 14:54:42 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC791A9127 for ; Wed, 20 Jan 2016 14:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIe52HfxfiUq for ; Wed, 20 Jan 2016 14:54:38 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39FA71A6FF9 for ; Wed, 20 Jan 2016 14:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RYSe+5fxXfS6+3aLZlI+s9bJ8F9wSCQSUA4ShJIpc+I=; b=cfMibeQM4ExxbL3X74c3+ZvEtd/ZPrb9DFUtPLwFndyCYyka3TRgx0aBHYiv9Qip+CE64h1HINbiQCzFkcWtszOuwcAz1BKWOgUkgJshqN68agYt/ODubdfGa7B9nvQjQsl0krcJYNO13LlAkFeHoKc+ZJZQt1nwrDQb7mDsy3k= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.365.19; Wed, 20 Jan 2016 22:54:36 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Wed, 20 Jan 2016 22:54:36 +0000 From: Mike Jones To: Nat Sakimura , John Bradley Thread-Topic: [OAUTH-WG] Status of draft-tschofenig-oauth-audience Thread-Index: AQHRU2z5bd5WDYhJ/0CRjTQN4ztm9p8EdoyAgACDlICAAAE0AIAAATiAgAAFoICAAAGIMA== Date: Wed, 20 Jan 2016 22:54:35 +0000 Message-ID: References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> <569F60B3.3030501@gmail.com> <569F9955.9030001@gmx.net> <1D483C18-6103-4197-9AF0-D4FD80E8F17E@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:2::37e] x-ms-office365-filtering-correlation-id: 20d80258-4eb7-4724-bf7c-08d321ecab58 x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:Iuf9djnO+qhF5zQzAyNo4U9/oIg/TZ5RvcQKSdHlWuJwNS1ubKh0Tvj4C5pSTQcVFqfNLzRHO6hzTVX5kOZfe2MND5y27x+bBcR8IkhkdK2q/x0FRwvlJAeV2CQfbkPiElgw9E8AH0c1Ee3s8YtXcQ==; 24:+m28ea0Ppp1NoVdsWQNvISZmtd7PplJ7fgKWpMjNTF62hINb8OAtUWDC1nAYagcSXodBZMz2HLQMFHyJp8RWiDIchHNlPSPJI07X2kj6GOA= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0827D7ACB9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(164054003)(189002)(377454003)(199003)(479174004)(87936001)(15975445007)(92566002)(106116001)(54356999)(19617315012)(105586002)(19580405001)(5004730100002)(106356001)(8990500004)(5008740100001)(10090500001)(5001960100002)(19609705001)(11100500001)(4326007)(2906002)(77096005)(5002640100001)(790700001)(1096002)(50986999)(19625215002)(76176999)(97736004)(10400500002)(19580395003)(102836003)(99286002)(586003)(2950100001)(10290500002)(33656002)(81156007)(122556002)(5005710100001)(16236675004)(40100003)(1220700001)(6116002)(101416001)(2900100001)(93886004)(5001770100001)(189998001)(19300405004)(5003600100002)(86612001)(86362001)(76576001)(74316001)(230783001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4422AFC1970EE19564F6046F5C20BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2016 22:54:35.8215 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 22:54:41 -0000 --_000_BY2PR03MB4422AFC1970EE19564F6046F5C20BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBkb2VzbuKAmXQgYWx3YXlzIHdvcmsgd2hlbiB0aGVyZeKAmXMgbXVsdGlwbGUgcmVzb3Vy Y2Ugc2VydmVycyB0aGF0IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBjb3VsZCBhdXRob3JpemUg YWNjZXNzIHRvLiAgV2hlcmVhcywgdGhlIGNsaWVudCBkb2VzIGtub3cgd2hhdCBpdOKAmXMgdHJ5 aW5nIHRvIGFjY2Vzcywgb3IgaXQgd291bGRu4oCZdCBiZSBtYWtpbmcgdGhlIGF1dGhvcml6YXRp b24gcmVxdWVzdCBpbiB0aGUgZmlyc3QgcGxhY2UuICBJdOKAmXMgZmluZSBmb3IgdGhlIGNsaWVu dCB0byB0ZWxsIHRoZSBzZXJ2ZXIgd2hhdCBpdCB3YW50cyBhY2Nlc3MgdG8uDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAt LSBNaWtlDQoNCkZyb206IE5hdCBTYWtpbXVyYSBbbWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbV0N ClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyMCwgMjAxNiAyOjQ3IFBNDQpUbzogSm9obiBCcmFk bGV5OyBNaWtlIEpvbmVzDQpDYzogb2F1dGgNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFN0YXR1 cyBvZiBkcmFmdC10c2Nob2ZlbmlnLW9hdXRoLWF1ZGllbmNlDQoNCisxDQoNCkFsc28sIEkgaGF2 ZSBhbHdheXMgdGhvdWdodCB0aGF0IGl0IHdvdWxkIGJlIGdvb2QgaWYgb25lIGNvdWxkIGFzayBm b3IgYSBwYXJ0aWN1bGFyIHJlc291cmNlIHR5cGUsIGFuZCB0aGUgc2VydmVyIGNvdWxkIHJlc3Bv bmQgd2l0aCB0aGUgYWN0dWFsIGxvY2F0aW9uIG9mIGl0IHdpdGggdGhlIGFzc29jaWF0ZWQgYWNj ZXNzIHRva2VuLiBUaGlzIGlzIGJlY2F1c2UgaXQgaXMgb2Z0ZW4gdW5kZXNpcmFibGUgdG8gdGVs bCB0aGUgY2xpZW50IHRoZSBsb2NhdGlvbiBvZiB0aGUgcmVzb3VyY2UgYmVmb3JlIHRoZSBhdXRo b3JpemF0aW9uIGZyb20gdGhlIHByaXZhY3kgcG9pbnQgb2Ygdmlldy4NCg0KU28sIHRoZSBwcm9j ZXNzaW5nIGZsb3cgaW4gdGhpcyBjYXNlIHdpbGwgYmU6DQoNCg0KICAxLiAgVGhlIGNsaWVudCBy ZXF1ZXN0IGFuIGFjY2VzcyB0byB0aGUgcmVzb3VyY2UgdHlwZSBpbiB0aGUgc2NvcGUgb2YgdGhl IGF1dGhvcml6YXRpb24gcmVxdWVzdC4NCiAgMi4gIFRoZSBjbGllbnQgcmVxdWVzdCBhbiBhY2Nl c3MgdG9rZW4gdG8gdGhlIHJlc291cmNlIHR5cGUgdG8gdGhlIHRva2VuIGVuZHBvaW50IHdpdGgg YXVkaWVuY2UvcmVzb3VyY2Uvc2NvcGUgcGFyYW1ldGVyLg0KICAzLiAgVGhlIHRva2VuIGVuZHBv aW50IHJlc3BvbmRzIHdpdGggdG9rZW4gcmVzcG9uc2Ugd2l0aCBvYXV0aC1tZXRhIGhlYWRlciBp bmRpY2F0aW5nIHRoZSBVUkwgb2YgdGhlIHJlc291cmNlIGFzIGluICBkcmFmdC1zYWtpbXVyYS1v YXV0aC1tZXRhLg0KQmVzdCwNCg0KTmF0DQoNCg0KMjAxNuW5tDHmnIgyMeaXpSjmnKgpIDc6Mjcg Sm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+ PjoNCisxDQoNCk9uIEphbiAyMCwgMjAxNiwgYXQgNzoyNSBQTSwgTWlrZSBKb25lcyA8TWljaGFl bC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+ PiB3cm90ZToNCg0KQXMgbWVudGlvbmVkIGluIFByYWd1ZSwgQXp1cmUgQWN0aXZlIERpcmVjdG9y eSB1c2VzIGEg4oCccmVzb3VyY2XigJ0gcmVxdWVzdCBwYXJhbWV0ZXIgdG8gc3VwcGx5IHRoZSBV Ukwgb2YgdGhlIHJlc291cmNlIHNlcnZlciB0aGF0IHRoZSBhY2Nlc3MgdG9rZW4gaXMgaW50ZW5k ZWQgZm9yLiAgSG93ZXZlciwgSSBiZWxpZXZlIHRoYXQgR29vZ2xlIHVzZXMgc2NvcGUgdmFsdWVz IGZvciB0aGlzIGFuZCBzb21lIE1pY3Jvc29mdCBzZXJ2aWNlcyBhcmUgbW92aW5nIHRvd2FyZHMg dXNpbmcgc2NvcGUgdmFsdWVzIGFzIHdlbGwuICBTb3J0aW5nIHRoaXMgb3V0IHNvb24gd291bGQg YmUgZ29vZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IFdlZG5l c2RheSwgSmFudWFyeSAyMCwgMjAxNiAyOjE4IFBNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcNCkNj OiBvYXV0aA0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gU3RhdHVzIG9mIGRyYWZ0LXRzY2hvZmVu aWctb2F1dGgtYXVkaWVuY2UNCg0KVGhlcmUgZG9lcyBzZWVtIHRvIGJlIGEgbmVlZCB0byBwcm92 aWRlIHRoZSBjbGllbnQgYSBtZWFucyBvZiB0ZWxsaW5nIHRoZSBBUyB0aGUgcGxhY2UocykgYW5k L29yIGVudGl0eShzKSB3aGVyZSBpdCBpbnRlbmRzIHRvIHVzZSB0aGUgdG9rZW4gaXQncyBhc2tp bmcgZm9yLiBBbmQgdGhhdCBpdCdzIGNvbW1vbiBlbm91Z2ggdG8gd2FycmFudCBpdCdzIG93biBz bWFsbCBzcGVjLiBUaGlzIGhhcyBjb21lIHVwIHNldmVyYWwgdGltZXMgYmVmb3JlIGFuZCBJIHRo aW5rIGhhcyBzb21lIGNvbnNlbnN1cyBiZWhpbmQgZG9pbmcgaXQuIFdoYXQgbmVlZHMgdG8gaGFw cGVuIHRvIG1vdmUgZm9yd2FyZD8NClRoZSBjb25jZXB0IHNob3dzIHVwIGluIHRoZXNlIHRocmVl IGRpZmZlcmVudCBkcmFmdHMgKHRoYXQgSSBrbm93IG9mIGFueXdheSk6DQoNCmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10c2Nob2ZlbmlnLW9hdXRoLWF1ZGllbmNlLTAwI3NlY3Rp b24tMyBoYXMgYW4gYXVkaWVuY2UgcGFyYW1ldGVyDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1vYXV0aC1wb3Ata2V5LWRpc3RyaWJ1dGlvbi0wMiNzZWN0aW9uLTMgaGFz IGFuIGF1ZCBwYXJhbWV0ZXINCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDMjc2VjdGlvbi0yLjEgaGFzIGJvdGggYW4gYXVkaWVuY2Ug YW5kIGEgcmVzb3VyY2UgcmVzb3VyY2UNCg0KQWxsIHRoZSBhYm92ZSBhcHBseSBvbmx5IHRvIHRo ZSB0b2tlbiByZXF1ZXN0LiBIb3dldmVyLCB0aGVyZSBhcmUgd2F5cyBvZiByZXF1ZXN0aW5nL29i dGFpbmluZyBhY2Nlc3MgdG9rZW5zIHRoYXQgZG9uJ3QgaW52b2x2ZSB0aGUgdG9rZW4gZW5kcG9p bnQ8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi00LjI+IHNvIEkg dGhpbmsgaXQgZm9sbG93cyB0aGF0ICB0aGUgc2FtZSBmYWNpbGl0eSBzaG91bGQgYmUgYXZhaWxh YmxlIGZvciB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHRvby4NCg0KDQpPbiBXZWQsIEphbiAy MCwgMjAxNiBhdCA3OjI3IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdA Z214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+IHdyb3RlOg0KSGkgU2Vy Z2V5LA0KDQp0aGF0J3MgYSBnb29kIHF1ZXN0aW9uLiBBZnRlciB0aGlzIGRvY3VtZW50IHdhcyBw dWJsaXNoZWQgdGhlDQpmdW5jdGlvbmFsaXR5IGhhZCBiZWVuIGludGVncmF0ZWQgaW50byB0aGUg UG9QIHNvbHV0aW9uIGRvY3VtZW50Lg0KUmVjZW50bHksIEkgZ290IGZlZWRiYWNrIHRoYXQgdGhl IGZ1bmN0aW9uYWxpdHkgc2hvdWxkIGJlIG1vcmUgZ2VuZXJpYw0KYW5kIGl0IGlzIGluZGVwZW5k ZW50IG9mIHRoZSBQb1Agd29yay4NCg0KU28sIEkgZ3Vlc3MgaXQgaXMgYSBnb29kIHRpbWUgdG8g ZGlzY3VzcyB0aGUgbmVlZGVkIGZ1bmN0aW9uYWxpdHkgYW5kDQp3aGVyZSBpdCBzaG91bGQgYmUg aW5jbHVkZWQuDQoNCkNpYW8NCkhhbm5lcw0KDQoNCk9uIDAxLzIwLzIwMTYgMTE6MjUgQU0sIFNl cmdleSBCZXJ5b3praW4gd3JvdGU6DQo+IEhpDQo+DQo+IEdpdmVuIHRoYXQgdGhlIGRyYWZ0LXRz Y2hvZmVuaWctb2F1dGgtYXVkaWVuY2UgWzFdIGhhcyBleHBpcmVkLCBJJ20NCj4gd29uZGVyaW5n IGlmIGl0IGlzIHN0aWxsIHJlbGV2YW50Lg0KPg0KPiBJIGtub3cgdGhlIHRva2VuIGludHJvc3Bl Y3Rpb24gcmVzcG9uc2UgY2FuIHByb3ZpZGUgdGhlIGF1ZGllbmNlDQo+IHZhbHVlKHMpLCBidXQg dGhlIHF1ZXN0aW9uIGlzIHJlYWxseSBob3cgYSBjbGllbnQgaXMgYXNzb2NpYXRlZCB3aXRoIGEg YQ0KPiBnaXZlbiBhdWRpZW5jZSBpbiB0aGUgZmlyc3QgcGxhY2UuIEFzIHN1Y2ggWzFdIG1heSBz dGlsbCBtYWtlIHNlbnNlLCBmb3INCj4gZXhhbXBsZSwgSSBjYW4gdGhpbmsgb2YgdHdvIG9wdGlv bnM6DQo+IDEuIHRoZSBjbGllbnQgYXVkaWVuY2VzIGFyZSBzZXQgb3V0IG9mIGJhbmQgZHVyaW5n IHRoZSBjbGllbnQNCj4gcmVnaXN0cmF0aW9uIHRpbWUgYW5kIGFsbCB0aGUgdG9rZW5zIGlzc3Vl ZCB0byB0aGF0IGNsaWVudCB3aWxsIGJlDQo+IHJlc3RyaWN0ZWQgYWNjb3JkaW5nbHkNCj4gMi4g dGhlIGNsaWVudCBpcyByZXF1ZXN0aW5nIGEgc3BlY2lmaWMgYXVkaWVuY2UgZHVyaW5nIHRoZSBn cmFudCB0bw0KPiB0b2tlbiBleGNoYW5nZSBhcyBwZXIgWzFdDQo+DQo+IEkgZ3Vlc3MgMS4gaXMg aG93IGl0IGlzIGRvbmUgaW4gcHJhY3RpY2Ugb3IgaXMgMi4gaXMgYWxzbyBhIHZhbGlkIG9wdGlv biA/DQo+DQo+DQo+IFRoYW5rcywgU2VyZ2V5DQo+DQo+DQo+IFsxXSBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5jZS0wMA0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWls aW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9B dXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFp bHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo= --_000_BY2PR03MB4422AFC1970EE19564F6046F5C20BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToy IDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1 IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4NzQ1NDM4Mjk7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjcyNDU4ODEyODt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYXQg ZG9lc27igJl0IGFsd2F5cyB3b3JrIHdoZW4gdGhlcmXigJlzIG11bHRpcGxlIHJlc291cmNlIHNl cnZlcnMgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgY291bGQgYXV0aG9yaXplIGFjY2Vz cyB0by4mbmJzcDsgV2hlcmVhcywgdGhlIGNsaWVudCBkb2VzIGtub3cgd2hhdA0KIGl04oCZcyB0 cnlpbmcgdG8gYWNjZXNzLCBvciBpdCB3b3VsZG7igJl0IGJlIG1ha2luZyB0aGUgYXV0aG9yaXph dGlvbiByZXF1ZXN0IGluIHRoZSBmaXJzdCBwbGFjZS4mbmJzcDsgSXTigJlzIGZpbmUgZm9yIHRo ZSBjbGllbnQgdG8gdGVsbCB0aGUgc2VydmVyIHdoYXQgaXQgd2FudHMgYWNjZXNzIHRvLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE5hdCBTYWtpbXVyYSBbbWFpbHRv OnNha2ltdXJhQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVh cnkgMjAsIDIwMTYgMjo0NyBQTTxicj4NCjxiPlRvOjwvYj4gSm9obiBCcmFkbGV5OyBNaWtlIEpv bmVzPGJyPg0KPGI+Q2M6PC9iPiBvYXV0aDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRI LVdHXSBTdGF0dXMgb2YgZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5jZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgSSBoYXZlIGFsd2F5cyB0aG91Z2h0IHRoYXQg aXQgd291bGQgYmUgZ29vZCBpZiBvbmUgY291bGQgYXNrIGZvciBhIHBhcnRpY3VsYXIgcmVzb3Vy Y2UgdHlwZSwgYW5kIHRoZSBzZXJ2ZXIgY291bGQgcmVzcG9uZCB3aXRoIHRoZSBhY3R1YWwgbG9j YXRpb24gb2YgaXQgd2l0aCB0aGUgYXNzb2NpYXRlZCBhY2Nlc3MgdG9rZW4uIFRoaXMgaXMgYmVj YXVzZSBpdCBpcyBvZnRlbiB1bmRlc2lyYWJsZSB0bw0KIHRlbGwgdGhlIGNsaWVudCB0aGUgbG9j YXRpb24gb2YgdGhlIHJlc291cmNlIGJlZm9yZSB0aGUgYXV0aG9yaXphdGlvbiBmcm9tIHRoZSBw cml2YWN5IHBvaW50IG9mIHZpZXcuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCB0aGUgcHJvY2Vzc2luZyBmbG93IGluIHRoaXMg Y2FzZSB3aWxsIGJlOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8b2wg c3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+DQpUaGUgY2xpZW50IHJlcXVlc3QgYW4gYWNjZXNzIHRvIHRoZSByZXNvdXJj ZSB0eXBlIGluIHRoZSBzY29wZSBvZiB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0LiZuYnNwOzxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj4NClRoZSBjbGllbnQgcmVxdWVzdCBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhlIHJlc291cmNl IHR5cGUgdG8gdGhlIHRva2VuIGVuZHBvaW50IHdpdGggYXVkaWVuY2UvcmVzb3VyY2Uvc2NvcGUg cGFyYW1ldGVyLiZuYnNwOzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZSB0b2tlbiBlbmRwb2ludCByZXNwb25kcyB3aXRo IHRva2VuIHJlc3BvbnNlIHdpdGggb2F1dGgtbWV0YSBoZWFkZXIgaW5kaWNhdGluZyB0aGUgVVJM IG9mIHRoZSByZXNvdXJjZSBhcyBpbiZuYnNwOyZuYnNwO2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1l dGEuJm5ic3A7PG86cD48L286cD48L2xpPjwvb2w+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5CZXN0LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O01TIEdvdGhpYyZxdW90OyI+5bm0PC9zcGFuPjE8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7TVMgR290aGljJnF1b3Q7Ij7mnIg8L3NwYW4+MjE8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7ml6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuacqDwvc3Bhbj4pIDc6MjcgSm9obiBCcmFkbGV5ICZs dDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9h PiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+JiM0MzsxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSmFuIDIwLCAyMDE2LCBhdCA3OjI1IFBNLCBN aWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t IiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIG1lbnRpb25lZCBp biBQcmFndWUsIEF6dXJlIEFjdGl2ZSBEaXJlY3RvcnkgdXNlcyBhIOKAnHJlc291cmNl4oCdIHJl cXVlc3QgcGFyYW1ldGVyIHRvIHN1cHBseSB0aGUgVVJMIG9mIHRoZSByZXNvdXJjZSBzZXJ2ZXIg dGhhdCB0aGUgYWNjZXNzIHRva2VuIGlzIGludGVuZGVkDQogZm9yLiZuYnNwOyBIb3dldmVyLCBJ IGJlbGlldmUgdGhhdCBHb29nbGUgdXNlcyBzY29wZSB2YWx1ZXMgZm9yIHRoaXMgYW5kIHNvbWUg TWljcm9zb2Z0IHNlcnZpY2VzIGFyZSBtb3ZpbmcgdG93YXJkcyB1c2luZyBzY29wZSB2YWx1ZXMg YXMgd2VsbC4mbmJzcDsgU29ydGluZyB0aGlzIG91dCBzb29uIHdvdWxkIGJlIGdvb2QuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDtPQXV0aCBbPGEgaHJl Zj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+XSZuYnNwOzxiPk9uDQogQmVoYWxmIE9mJm5ic3A7PC9iPkJyaWFuIENhbXBiZWxsPGJyPg0K PGI+U2VudDo8L2I+Jm5ic3A7V2VkbmVzZGF5LCBKYW51YXJ5IDIwLCAyMDE2IDI6MTggUE08YnI+ DQo8Yj5Ubzo8L2I+Jm5ic3A7SGFubmVzIFRzY2hvZmVuaWc8YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7 b2F1dGg8YnI+DQo8Yj5TdWJqZWN0OjwvYj4mbmJzcDtSZTogW09BVVRILVdHXSBTdGF0dXMgb2Yg ZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5jZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+VGhlcmUgZG9lcyBzZWVtIHRvIGJlIGEgbmVlZCB0byBwcm92aWRlIHRo ZSBjbGllbnQgYSBtZWFucyBvZiB0ZWxsaW5nIHRoZSBBUyB0aGUgcGxhY2UocykgYW5kL29yIGVu dGl0eShzKSB3aGVyZSBpdCBpbnRlbmRzIHRvIHVzZSB0aGUgdG9rZW4gaXQncyBhc2tpbmcgZm9y LiBBbmQgdGhhdCBpdCdzIGNvbW1vbiBlbm91Z2ggdG8gd2FycmFudCBpdCdzIG93biBzbWFsbA0K IHNwZWMuIFRoaXMgaGFzIGNvbWUgdXAgc2V2ZXJhbCB0aW1lcyBiZWZvcmUgYW5kIEkgdGhpbmsg aGFzIHNvbWUgY29uc2Vuc3VzIGJlaGluZCBkb2luZyBpdC4gV2hhdCBuZWVkcyB0byBoYXBwZW4g dG8gbW92ZSBmb3J3YXJkPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIGNvbmNlcHQgc2hvd3MgdXAgaW4gdGhlc2UgdGhyZWUgZGlmZmVyZW50 IGRyYWZ0cyAodGhhdCBJIGtub3cgb2YgYW55d2F5KTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRzY2hvZmVu aWctb2F1dGgtYXVkaWVuY2UtMDAjc2VjdGlvbi0zIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRzY2hv ZmVuaWctb2F1dGgtYXVkaWVuY2UtMDAjc2VjdGlvbi0zPC9zcGFuPjwvYT4mbmJzcDtoYXMgYW4g YXVkaWVuY2UgcGFyYW1ldGVyJm5ic3A7PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcG9wLWtleS1kaXN0cmlidXRpb24tMDIjc2VjdGlv bi0zIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcG9wLWtleS1kaXN0cmlidXRpb24t MDIjc2VjdGlvbi0zPC9zcGFuPjwvYT4mbmJzcDtoYXMgYW4gYXVkIHBhcmFtZXRlciZuYnNwOzxi cj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgt dG9rZW4tZXhjaGFuZ2UtMDMjc2VjdGlvbi0yLjEiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9h dXRoLXRva2VuLWV4Y2hhbmdlLTAzI3NlY3Rpb24tMi4xPC9zcGFuPjwvYT4mbmJzcDtoYXMgYm90 aCBhbiBhdWRpZW5jZSBhbmQgYSByZXNvdXJjZSByZXNvdXJjZTxicj4NCjxicj4NCkFsbCB0aGUg YWJvdmUgYXBwbHkgb25seSB0byB0aGUgdG9rZW4gcmVxdWVzdC4gSG93ZXZlciwgdGhlcmUgYXJl Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlv bi00LjIiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj53YXlzIG9m IHJlcXVlc3Rpbmcvb2J0YWluaW5nIGFjY2VzcyB0b2tlbnMgdGhhdCBkb24ndCBpbnZvbHZlIHRo ZSB0b2tlbiBlbmRwb2ludDwvc3Bhbj48L2E+Jm5ic3A7c28NCiBJIHRoaW5rIGl0IGZvbGxvd3Mg dGhhdCZuYnNwOyB0aGUgc2FtZSBmYWNpbGl0eSBzaG91bGQgYmUgYXZhaWxhYmxlIGZvciB0aGUg YXV0aG9yaXphdGlvbiByZXF1ZXN0IHRvby4mbmJzcDs8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBXZWQsIEphbiAyMCwgMjAxNiBhdCA3OjI3IEFNLCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5oYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9zcGFu PjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgU2VyZ2V5LDxicj4NCjxicj4NCnRoYXQncyBhIGdvb2QgcXVlc3Rpb24u IEFmdGVyIHRoaXMgZG9jdW1lbnQgd2FzIHB1Ymxpc2hlZCB0aGU8YnI+DQpmdW5jdGlvbmFsaXR5 IGhhZCBiZWVuIGludGVncmF0ZWQgaW50byB0aGUgUG9QIHNvbHV0aW9uIGRvY3VtZW50Ljxicj4N ClJlY2VudGx5LCBJIGdvdCBmZWVkYmFjayB0aGF0IHRoZSBmdW5jdGlvbmFsaXR5IHNob3VsZCBi ZSBtb3JlIGdlbmVyaWM8YnI+DQphbmQgaXQgaXMgaW5kZXBlbmRlbnQgb2YgdGhlIFBvUCB3b3Jr Ljxicj4NCjxicj4NClNvLCBJIGd1ZXNzIGl0IGlzIGEgZ29vZCB0aW1lIHRvIGRpc2N1c3MgdGhl IG5lZWRlZCBmdW5jdGlvbmFsaXR5IGFuZDxicj4NCndoZXJlIGl0IHNob3VsZCBiZSBpbmNsdWRl ZC48YnI+DQo8YnI+DQpDaWFvPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPkhhbm5l czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCk9uIDAx LzIwLzIwMTYgMTE6MjUgQU0sIFNlcmdleSBCZXJ5b3praW4gd3JvdGU6PGJyPg0KJmd0OyBIaTxi cj4NCiZndDs8YnI+DQomZ3Q7IEdpdmVuIHRoYXQgdGhlIGRyYWZ0LXRzY2hvZmVuaWctb2F1dGgt YXVkaWVuY2UgWzFdIGhhcyBleHBpcmVkLCBJJ208YnI+DQomZ3Q7IHdvbmRlcmluZyBpZiBpdCBp cyBzdGlsbCByZWxldmFudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGtub3cgdGhlIHRva2VuIGlu dHJvc3BlY3Rpb24gcmVzcG9uc2UgY2FuIHByb3ZpZGUgdGhlIGF1ZGllbmNlPGJyPg0KJmd0OyB2 YWx1ZShzKSwgYnV0IHRoZSBxdWVzdGlvbiBpcyByZWFsbHkgaG93IGEgY2xpZW50IGlzIGFzc29j aWF0ZWQgd2l0aCBhIGE8YnI+DQomZ3Q7IGdpdmVuIGF1ZGllbmNlIGluIHRoZSBmaXJzdCBwbGFj ZS4gQXMgc3VjaCBbMV0gbWF5IHN0aWxsIG1ha2Ugc2Vuc2UsIGZvcjxicj4NCiZndDsgZXhhbXBs ZSwgSSBjYW4gdGhpbmsgb2YgdHdvIG9wdGlvbnM6PGJyPg0KJmd0OyAxLiB0aGUgY2xpZW50IGF1 ZGllbmNlcyBhcmUgc2V0IG91dCBvZiBiYW5kIGR1cmluZyB0aGUgY2xpZW50PGJyPg0KJmd0OyBy ZWdpc3RyYXRpb24gdGltZSBhbmQgYWxsIHRoZSB0b2tlbnMgaXNzdWVkIHRvIHRoYXQgY2xpZW50 IHdpbGwgYmU8YnI+DQomZ3Q7IHJlc3RyaWN0ZWQgYWNjb3JkaW5nbHk8YnI+DQomZ3Q7IDIuIHRo ZSBjbGllbnQgaXMgcmVxdWVzdGluZyBhIHNwZWNpZmljIGF1ZGllbmNlIGR1cmluZyB0aGUgZ3Jh bnQgdG88YnI+DQomZ3Q7IHRva2VuIGV4Y2hhbmdlIGFzIHBlciBbMV08YnI+DQomZ3Q7PGJyPg0K Jmd0OyBJIGd1ZXNzIDEuIGlzIGhvdyBpdCBpcyBkb25lIGluIHByYWN0aWNlIG9yIGlzIDIuIGlz IGFsc28gYSB2YWxpZCBvcHRpb24gPzxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFu a3MsIFNlcmdleTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBbMV0mbmJzcDs8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRp ZW5jZS0wMCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10c2Nob2ZlbmlnLW9hdXRoLWF1ZGllbmNlLTAw PC9zcGFuPjwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyZuYnNwOzxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9BdXRoQGlldGYub3JnPC9zcGFuPjwvYT48YnI+ DQomZ3Q7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v YXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR03MB4422AFC1970EE19564F6046F5C20BY2PR03MB442namprd_-- From nobody Wed Jan 20 14:55:44 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB6F1B2A2A for ; Wed, 20 Jan 2016 14:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYWKWZCSXaSV for ; Wed, 20 Jan 2016 14:55:39 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 E8A021A9127 for ; Wed, 20 Jan 2016 14:55:38 -0800 (PST) Received: by mail-qg0-x22d.google.com with SMTP id o11so18797835qge.2 for ; Wed, 20 Jan 2016 14:55:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=P5t5jsYiz+07tyWFBgblpyZ9f+C1LS9GyK7U1VfX2Y0=; b=RYH1NQdpkNNUO38IBKxjDwbJWkjHXvwG7zTwdRbk9aY3mlhA00XLtddUS8pkBsnSh1 IlfT3ocyNKL4323sxUFUzXiGGvr9tFs3Zb1NmAWaLBlXK0yKa3OrsSqfLLiLrlOJR8nG +H/3kF2HrnGLoCs3mV6jIRt0le5xPXiR42B7AzvabfO7ZYtvKgZAYaNDVxTx99O0/RsF zl8lzOY1jCmvIqzxBPl5j6izMCfHQhNmdjx7abUoU7FaPqszApV6RCwr0t03ixfr5J1Y Dajps+NnS6/8zF/JH8ASrPV3ZBhbfnyJZxjABnLmtItZOsq7qHWfKVr112cs22i+svVt mkDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=P5t5jsYiz+07tyWFBgblpyZ9f+C1LS9GyK7U1VfX2Y0=; b=OgNPIUsZrJ7JCnECNuOP9Xq9xhbAVybmfUQ3vaz94XOkDRccvu2baq3NvC6G/D83y9 C3q7o9aZM1vQr9tGGZ+1ahGKvXmyTSUZWud/z3CaKoZGc6Ge273mIAgYt55hLzHj3iyB tfIJU+hg3C00yJVcWoZsraGtxOC4bJS1yPatPT7LwHi6M2khJ4fPV2ZAiQyXAxrY51nI ByJRprSf0aq09yr8bVN3n+R0O0ycwgbD8fa9bV1VSoIV24kDINrj0NIGuMtWpdIaSYu1 JfWr33fpQ1255dh8kkS/l9sJ0Rgh41OKtO4UWcTNZDj90VgY/CjOT7LCcyC018k58qp0 WB3g== X-Gm-Message-State: ALoCoQlKnn9YiWjVLDpYzUPrzhrDUnlwrJnvVbKRN8yMWUYzt8WUDZv6rJsDie/wJD6Pn3DtoJYQKOQ1wx1iv5OFFXWnHKdc9w== X-Received: by 10.140.175.7 with SMTP id v7mr51282353qhv.103.1453330538039; Wed, 20 Jan 2016 14:55:38 -0800 (PST) Received: from [192.168.8.101] ([181.202.164.7]) by smtp.gmail.com with ESMTPSA id d6sm15232016qkb.13.2016.01.20.14.55.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 14:55:37 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_ADF6BD98-8CDE-48B3-8214-A8775BFBC8BB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Wed, 20 Jan 2016 19:55:32 -0300 Message-Id: References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> <569F60B3.3030501@gmail.com> <569F9955.9030001@gmx.net> <1D483C18-6103-4197-9AF0-D4FD80E8F17E@ve7jtb.com> To: Nat Sakimura X-Mailer: Apple Mail (2.3112) Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 22:55:42 -0000 --Apple-Mail=_ADF6BD98-8CDE-48B3-8214-A8775BFBC8BB Content-Type: multipart/alternative; boundary="Apple-Mail=_D7FA10F6-0B87-4F25-8984-A81512311970" --Apple-Mail=_D7FA10F6-0B87-4F25-8984-A81512311970 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We have been talking about providing the resource or audience as the = input. The resource type would be more abstract than audience. =20 That is something we would need to discuss in a spec. The problem foe POP is that the same scope may cover multiple resource = endpoints. Especially when using a symmetric key you need to specify = what Resource server you are sending the token to so that it can be = encrypted with the correct key. John B. > On Jan 20, 2016, at 7:47 PM, Nat Sakimura wrote: >=20 > +1 >=20 > Also, I have always thought that it would be good if one could ask for = a particular resource type, and the server could respond with the actual = location of it with the associated access token. This is because it is = often undesirable to tell the client the location of the resource before = the authorization from the privacy point of view.=20 >=20 > So, the processing flow in this case will be:=20 >=20 > The client request an access to the resource type in the scope of the = authorization request.=20 > The client request an access token to the resource type to the token = endpoint with audience/resource/scope parameter.=20 > The token endpoint responds with token response with oauth-meta header = indicating the URL of the resource as in draft-sakimura-oauth-meta.=20 > Best,=20 >=20 > Nat >=20 >=20 > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 7:27 John Bradley = >: > +1 >=20 >> On Jan 20, 2016, at 7:25 PM, Mike Jones > wrote: >>=20 >> As mentioned in Prague, Azure Active Directory uses a =E2=80=9Cresource= =E2=80=9D request parameter to supply the URL of the resource server = that the access token is intended for. However, I believe that Google = uses scope values for this and some Microsoft services are moving = towards using scope values as well. Sorting this out soon would be = good. >> =20 >> -- = Mike >> =20 >> From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of Brian Campbell >> Sent: Wednesday, January 20, 2016 2:18 PM >> To: Hannes Tschofenig >> Cc: oauth >> Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience >> =20 >> There does seem to be a need to provide the client a means of telling = the AS the place(s) and/or entity(s) where it intends to use the token = it's asking for. And that it's common enough to warrant it's own small = spec. This has come up several times before and I think has some = consensus behind doing it. What needs to happen to move forward? >>=20 >> The concept shows up in these three different drafts (that I know of = anyway): >>=20 >> = https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 = = has an audience parameter=20 >> = https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#secti= on-3 = has an aud parameter=20 >> = http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 = has both an audience and a resource resource >>=20 >> All the above apply only to the token request. However, there are = ways of requesting/obtaining access tokens that don't involve the token = endpoint so I think it = follows that the same facility should be available for the = authorization request too.=20 >>=20 >>=20 >>=20 >> =20 >> On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig = > wrote: >> Hi Sergey, >>=20 >> that's a good question. After this document was published the >> functionality had been integrated into the PoP solution document. >> Recently, I got feedback that the functionality should be more = generic >> and it is independent of the PoP work. >>=20 >> So, I guess it is a good time to discuss the needed functionality and >> where it should be included. >>=20 >> Ciao >> Hannes >>=20 >>=20 >> On 01/20/2016 11:25 AM, Sergey Beryozkin wrote: >> > Hi >> > >> > Given that the draft-tschofenig-oauth-audience [1] has expired, I'm >> > wondering if it is still relevant. >> > >> > I know the token introspection response can provide the audience >> > value(s), but the question is really how a client is associated = with a a >> > given audience in the first place. As such [1] may still make = sense, for >> > example, I can think of two options: >> > 1. the client audiences are set out of band during the client >> > registration time and all the tokens issued to that client will be >> > restricted accordingly >> > 2. the client is requesting a specific audience during the grant to >> > token exchange as per [1] >> > >> > I guess 1. is how it is done in practice or is 2. is also a valid = option ? >> > >> > >> > Thanks, Sergey >> > >> > >> > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 = >> > >> > _______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth = >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> =20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_D7FA10F6-0B87-4F25-8984-A81512311970 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We have been talking about providing the resource or audience = as the input.

The = resource type would be more abstract than audience.  

That is something we = would need to discuss in a spec.

The problem foe POP is that the same = scope may cover multiple resource endpoints.  Especially when using = a symmetric key you need to specify what Resource server you are sending = the token to so that it can be encrypted with the correct key.

John B.
On = Jan 20, 2016, at 7:47 PM, Nat Sakimura <sakimura@gmail.com> = wrote:

+1

Also, I have always thought that it would be good if one = could ask for a particular resource type, and the server could respond = with the actual location of it with the associated access token. This is = because it is often undesirable to tell the client the location of the = resource before the authorization from the privacy point of = view. 

So, = the processing flow in this case will be: 

  1. The client request an access to the = resource type in the scope of the authorization request. 
  2. The client request an access token to the resource type to = the token endpoint with audience/resource/scope = parameter. 
  3. The token endpoint responds with = token response with oauth-meta header indicating the URL of the resource = as in  draft-sakimura-oauth-meta. 
Best, 

Nat


2016=E5=B9=B41=E6=9C=882= 1=E6=97=A5(=E6=9C=A8) 7:27 John Bradley <ve7jtb@ve7jtb.com>:
+1

On Jan 20, 2016, at 7:25 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

As mentioned in Prague, Azure Active Directory uses a = =E2=80=9Cresource=E2=80=9D request parameter to supply the URL of the = resource server that the access token is intended for.  However, I = believe that Google uses scope values for this and some Microsoft = services are moving towards using scope values as well.  Sorting = this out soon would be good.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;    -- Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, January 20, = 2016 2:18 PM
To: Hannes Tschofenig
Cc: oauth
Subject: Re: [OAUTH-WG] = Status of draft-tschofenig-oauth-audience
 

There does seem = to be a need to provide the client a means of telling the AS the = place(s) and/or entity(s) where it intends to use the token it's asking = for. And that it's common enough to warrant it's own small spec. This = has come up several times before and I think has some consensus behind = doing it. What needs to happen to move forward?

The concept shows up in these three different drafts (that I = know of anyway):


https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#= section-3 has an audience = parameter 
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distributi= on-02#section-3 has an aud = parameter 
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#s= ection-2.1 has both an audience and a = resource resource

All the above apply only = to the token request. However, there are ways of requesting/obtaining access tokens that don't involve = the token endpoint so I think it = follows that  the same facility should be available for the = authorization request too. 

 
On Wed, Jan 20, 2016 at 7:27 AM, Hannes = Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi= Sergey,

that's a good question. After this = document was published the
functionality had been = integrated into the PoP solution document.
Recently, I got = feedback that the functionality should be more generic
and = it is independent of the PoP work.

So, I = guess it is a good time to discuss the needed functionality and
where it should be included.

Ciao
Hannes



On 01/20/2016 11:25 AM, Sergey Beryozkin = wrote:
> Hi
>
> Given = that the draft-tschofenig-oauth-audience [1] has expired, I'm
> wondering if it is still relevant.
>
> I know the token introspection response can provide the = audience
> value(s), but the question is really how a = client is associated with a a
> given audience in the = first place. As such [1] may still make sense, for
> = example, I can think of two options:
> 1. the client = audiences are set out of band during the client
> = registration time and all the tokens issued to that client will be
> restricted accordingly
> 2. the client = is requesting a specific audience during the grant to
> = token exchange as per [1]
>
> I guess = 1. is how it is done in practice or is 2. is also a valid option ?
>
>
> Thanks, Sergey
>
>
> [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00<= /a>
>
> = _______________________________________________
> 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=_D7FA10F6-0B87-4F25-8984-A81512311970-- --Apple-Mail=_ADF6BD98-8CDE-48B3-8214-A8775BFBC8BB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMjAyMjU1MzJaMCMGCSqGSIb3DQEJBDEWBBQbGexeJqyxAU8afHEO/mAl 1Cdi4zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBfbEnsPfMuj9beODmKgqPbg6oazNX4U510p5HwAitSWljbnDbe/5/J Evi9Fnd9QFz9rt55P+pSIXmSeYdO1kegkavx8OtT+p7sbBIOd4S3JnmU+Iss/aZibkjBqLzKJVVI qT50cHOKQpQ9Mi+c88QwYBkimJ4Zdd2HTExQDXIJDsJn0bmqK8hoIGtII3mGBbN9ZvARXnuZ0XaX NjD46Ad3jDmxO2PDw8OhOEDjspFOSJIZ1V06wtbdgJIgn8RrHMwOCRWAj2oCb1P+Ej7y6VEFyQMR px0XCxgg9vtWB3MFQvM0XZW4xdO15Z8i3AMJvf9klkA9F2JJooe97h/MFxVpAAAAAAAA --Apple-Mail=_ADF6BD98-8CDE-48B3-8214-A8775BFBC8BB-- From nobody Wed Jan 20 14:56:54 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45F81B2A30 for ; Wed, 20 Jan 2016 14:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4mqOfZiWeug for ; Wed, 20 Jan 2016 14:56:50 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0115.outbound.protection.outlook.com [207.46.100.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF001A9127 for ; Wed, 20 Jan 2016 14:56:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DweIVq+AopCTwkBPaQgH8ninGqF3pth0QweE8nklvxQ=; b=iGfJz11CUIEHtOQdZZ+sVDSBE5YamfR3XKx271ZBc3IMA5+WENfyOxYr/LLecY08yCIXlx0367H4UiEQTrb7qK1SLzkiZFE356M/SutYNXDhVPnQdVD0deZIICytqLw517NCV/xjr4Hhh+Z5qdiVX/mTshq/kDMBsklNuPpnWU4= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.365.19; Wed, 20 Jan 2016 22:56:48 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Wed, 20 Jan 2016 22:56:48 +0000 From: Mike Jones To: John Bradley , Nat Sakimura Thread-Topic: [OAUTH-WG] Status of draft-tschofenig-oauth-audience Thread-Index: AQHRU2z5bd5WDYhJ/0CRjTQN4ztm9p8EdoyAgACDlICAAAE0AIAAATiAgAAFoICAAAJOAIAAAD3g Date: Wed, 20 Jan 2016 22:56:48 +0000 Message-ID: References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> <569F60B3.3030501@gmail.com> <569F9955.9030001@gmx.net> <1D483C18-6103-4197-9AF0-D4FD80E8F17E@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:2::37e] x-ms-office365-filtering-correlation-id: a317667a-0355-45b5-8aad-08d321ecfa74 x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:5tx/qGb1KGanQgXi+8mQKfwaQ48TT+UmrFTv5vEN8eW4qOnqDqAFTpzp4gwDHLnpGaBACnOh/zDhwgsOj3oFHKrRG3J71s6m9m541lXl+7JsFg+wZEqP0ouvDxwmrDXeuIJM+QZopNbpxH6g7hvdGw==; 24:lPL1KM7j+xUZDTFQbLBvEf+Is9Z+BHba7U7XCS6Gpe0a4ubSq9nFR4Mvoe2YKS46fY2jZ6jvQ3WbdqknOy1MPQGmEk8lBEifglTo7jrZHQs= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; x-forefront-prvs: 0827D7ACB9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(164054003)(189002)(377454003)(199003)(479174004)(87936001)(15975445007)(92566002)(106116001)(54356999)(19617315012)(105586002)(19580405001)(5004730100002)(106356001)(8990500004)(5008740100001)(10090500001)(5001960100002)(19609705001)(11100500001)(4326007)(2906002)(77096005)(5002640100001)(790700001)(1096002)(50986999)(19625215002)(76176999)(97736004)(10400500002)(19580395003)(102836003)(99286002)(586003)(2950100001)(10290500002)(33656002)(81156007)(122556002)(5005710100001)(16236675004)(40100003)(1220700001)(6116002)(101416001)(2900100001)(93886004)(5001770100001)(189998001)(19300405004)(5003600100002)(86612001)(86362001)(76576001)(74316001)(230783001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44200DD63CBEF54423164E6F5C20BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2016 22:56:48.4968 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 22:56:53 -0000 --_000_BY2PR03MB44200DD63CBEF54423164E6F5C20BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSSBzZWUgaXQsIEpvaG4ganVzdCBzYWlkIHRoZSBzYW1lIHRoaW5nIEkgZGlkIGluIHBhcmFs bGVsLCB1c2luZyBkaWZmZXJlbnQgd29yZHMuDQoNCkZyb206IEpvaG4gQnJhZGxleSBbbWFpbHRv OnZlN2p0YkB2ZTdqdGIuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIwLCAyMDE2IDI6 NTYgUE0NClRvOiBOYXQgU2FraW11cmENCkNjOiBNaWtlIEpvbmVzOyBvYXV0aA0KU3ViamVjdDog UmU6IFtPQVVUSC1XR10gU3RhdHVzIG9mIGRyYWZ0LXRzY2hvZmVuaWctb2F1dGgtYXVkaWVuY2UN Cg0KV2UgaGF2ZSBiZWVuIHRhbGtpbmcgYWJvdXQgcHJvdmlkaW5nIHRoZSByZXNvdXJjZSBvciBh dWRpZW5jZSBhcyB0aGUgaW5wdXQuDQoNClRoZSByZXNvdXJjZSB0eXBlIHdvdWxkIGJlIG1vcmUg YWJzdHJhY3QgdGhhbiBhdWRpZW5jZS4NCg0KVGhhdCBpcyBzb21ldGhpbmcgd2Ugd291bGQgbmVl ZCB0byBkaXNjdXNzIGluIGEgc3BlYy4NCg0KVGhlIHByb2JsZW0gZm9lIFBPUCBpcyB0aGF0IHRo ZSBzYW1lIHNjb3BlIG1heSBjb3ZlciBtdWx0aXBsZSByZXNvdXJjZSBlbmRwb2ludHMuICBFc3Bl Y2lhbGx5IHdoZW4gdXNpbmcgYSBzeW1tZXRyaWMga2V5IHlvdSBuZWVkIHRvIHNwZWNpZnkgd2hh dCBSZXNvdXJjZSBzZXJ2ZXIgeW91IGFyZSBzZW5kaW5nIHRoZSB0b2tlbiB0byBzbyB0aGF0IGl0 IGNhbiBiZSBlbmNyeXB0ZWQgd2l0aCB0aGUgY29ycmVjdCBrZXkuDQoNCkpvaG4gQi4NCk9uIEph biAyMCwgMjAxNiwgYXQgNzo0NyBQTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208 bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQorMQ0KDQpBbHNvLCBJIGhhdmUg YWx3YXlzIHRob3VnaHQgdGhhdCBpdCB3b3VsZCBiZSBnb29kIGlmIG9uZSBjb3VsZCBhc2sgZm9y IGEgcGFydGljdWxhciByZXNvdXJjZSB0eXBlLCBhbmQgdGhlIHNlcnZlciBjb3VsZCByZXNwb25k IHdpdGggdGhlIGFjdHVhbCBsb2NhdGlvbiBvZiBpdCB3aXRoIHRoZSBhc3NvY2lhdGVkIGFjY2Vz cyB0b2tlbi4gVGhpcyBpcyBiZWNhdXNlIGl0IGlzIG9mdGVuIHVuZGVzaXJhYmxlIHRvIHRlbGwg dGhlIGNsaWVudCB0aGUgbG9jYXRpb24gb2YgdGhlIHJlc291cmNlIGJlZm9yZSB0aGUgYXV0aG9y aXphdGlvbiBmcm9tIHRoZSBwcml2YWN5IHBvaW50IG9mIHZpZXcuDQoNClNvLCB0aGUgcHJvY2Vz c2luZyBmbG93IGluIHRoaXMgY2FzZSB3aWxsIGJlOg0KDQoNCiAgMS4gIFRoZSBjbGllbnQgcmVx dWVzdCBhbiBhY2Nlc3MgdG8gdGhlIHJlc291cmNlIHR5cGUgaW4gdGhlIHNjb3BlIG9mIHRoZSBh dXRob3JpemF0aW9uIHJlcXVlc3QuDQogIDIuICBUaGUgY2xpZW50IHJlcXVlc3QgYW4gYWNjZXNz IHRva2VuIHRvIHRoZSByZXNvdXJjZSB0eXBlIHRvIHRoZSB0b2tlbiBlbmRwb2ludCB3aXRoIGF1 ZGllbmNlL3Jlc291cmNlL3Njb3BlIHBhcmFtZXRlci4NCiAgMy4gIFRoZSB0b2tlbiBlbmRwb2lu dCByZXNwb25kcyB3aXRoIHRva2VuIHJlc3BvbnNlIHdpdGggb2F1dGgtbWV0YSBoZWFkZXIgaW5k aWNhdGluZyB0aGUgVVJMIG9mIHRoZSByZXNvdXJjZSBhcyBpbiAgZHJhZnQtc2FraW11cmEtb2F1 dGgtbWV0YS4NCkJlc3QsDQoNCk5hdA0KDQoNCjIwMTblubQx5pyIMjHml6Uo5pyoKSA3OjI3IEpv aG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj46 DQorMQ0KDQpPbiBKYW4gMjAsIDIwMTYsIGF0IDc6MjUgUE0sIE1pa2UgSm9uZXMgPE1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQoNCkFzIG1lbnRpb25lZCBpbiBQcmFndWUsIEF6dXJlIEFjdGl2ZSBEaXJlY3Rvcnkg dXNlcyBhIOKAnHJlc291cmNl4oCdIHJlcXVlc3QgcGFyYW1ldGVyIHRvIHN1cHBseSB0aGUgVVJM IG9mIHRoZSByZXNvdXJjZSBzZXJ2ZXIgdGhhdCB0aGUgYWNjZXNzIHRva2VuIGlzIGludGVuZGVk IGZvci4gIEhvd2V2ZXIsIEkgYmVsaWV2ZSB0aGF0IEdvb2dsZSB1c2VzIHNjb3BlIHZhbHVlcyBm b3IgdGhpcyBhbmQgc29tZSBNaWNyb3NvZnQgc2VydmljZXMgYXJlIG1vdmluZyB0b3dhcmRzIHVz aW5nIHNjb3BlIHZhbHVlcyBhcyB3ZWxsLiAgU29ydGluZyB0aGlzIG91dCBzb29uIHdvdWxkIGJl IGdvb2QuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIENhbXBiZWxsDQpTZW50OiBXZWRuZXNk YXksIEphbnVhcnkgMjAsIDIwMTYgMjoxOCBQTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzog b2F1dGgNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFN0YXR1cyBvZiBkcmFmdC10c2Nob2Zlbmln LW9hdXRoLWF1ZGllbmNlDQoNClRoZXJlIGRvZXMgc2VlbSB0byBiZSBhIG5lZWQgdG8gcHJvdmlk ZSB0aGUgY2xpZW50IGEgbWVhbnMgb2YgdGVsbGluZyB0aGUgQVMgdGhlIHBsYWNlKHMpIGFuZC9v ciBlbnRpdHkocykgd2hlcmUgaXQgaW50ZW5kcyB0byB1c2UgdGhlIHRva2VuIGl0J3MgYXNraW5n IGZvci4gQW5kIHRoYXQgaXQncyBjb21tb24gZW5vdWdoIHRvIHdhcnJhbnQgaXQncyBvd24gc21h bGwgc3BlYy4gVGhpcyBoYXMgY29tZSB1cCBzZXZlcmFsIHRpbWVzIGJlZm9yZSBhbmQgSSB0aGlu ayBoYXMgc29tZSBjb25zZW5zdXMgYmVoaW5kIGRvaW5nIGl0LiBXaGF0IG5lZWRzIHRvIGhhcHBl biB0byBtb3ZlIGZvcndhcmQ/DQpUaGUgY29uY2VwdCBzaG93cyB1cCBpbiB0aGVzZSB0aHJlZSBk aWZmZXJlbnQgZHJhZnRzICh0aGF0IEkga25vdyBvZiBhbnl3YXkpOg0KDQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5jZS0wMCNzZWN0aW9u LTMgaGFzIGFuIGF1ZGllbmNlIHBhcmFtZXRlcg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtb2F1dGgtcG9wLWtleS1kaXN0cmlidXRpb24tMDIjc2VjdGlvbi0zIGhhcyBh biBhdWQgcGFyYW1ldGVyDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9h dXRoLXRva2VuLWV4Y2hhbmdlLTAzI3NlY3Rpb24tMi4xIGhhcyBib3RoIGFuIGF1ZGllbmNlIGFu ZCBhIHJlc291cmNlIHJlc291cmNlDQoNCkFsbCB0aGUgYWJvdmUgYXBwbHkgb25seSB0byB0aGUg dG9rZW4gcmVxdWVzdC4gSG93ZXZlciwgdGhlcmUgYXJlIHdheXMgb2YgcmVxdWVzdGluZy9vYnRh aW5pbmcgYWNjZXNzIHRva2VucyB0aGF0IGRvbid0IGludm9sdmUgdGhlIHRva2VuIGVuZHBvaW50 PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tNC4yPiBzbyBJIHRo aW5rIGl0IGZvbGxvd3MgdGhhdCAgdGhlIHNhbWUgZmFjaWxpdHkgc2hvdWxkIGJlIGF2YWlsYWJs ZSBmb3IgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdCB0b28uDQoNCg0KT24gV2VkLCBKYW4gMjAs IDIwMTYgYXQgNzoyNyBBTSwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdt eC5uZXQ8bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+PiB3cm90ZToNCkhpIFNlcmdl eSwNCg0KdGhhdCdzIGEgZ29vZCBxdWVzdGlvbi4gQWZ0ZXIgdGhpcyBkb2N1bWVudCB3YXMgcHVi bGlzaGVkIHRoZQ0KZnVuY3Rpb25hbGl0eSBoYWQgYmVlbiBpbnRlZ3JhdGVkIGludG8gdGhlIFBv UCBzb2x1dGlvbiBkb2N1bWVudC4NClJlY2VudGx5LCBJIGdvdCBmZWVkYmFjayB0aGF0IHRoZSBm dW5jdGlvbmFsaXR5IHNob3VsZCBiZSBtb3JlIGdlbmVyaWMNCmFuZCBpdCBpcyBpbmRlcGVuZGVu dCBvZiB0aGUgUG9QIHdvcmsuDQoNClNvLCBJIGd1ZXNzIGl0IGlzIGEgZ29vZCB0aW1lIHRvIGRp c2N1c3MgdGhlIG5lZWRlZCBmdW5jdGlvbmFsaXR5IGFuZA0Kd2hlcmUgaXQgc2hvdWxkIGJlIGlu Y2x1ZGVkLg0KDQpDaWFvDQpIYW5uZXMNCg0KDQpPbiAwMS8yMC8yMDE2IDExOjI1IEFNLCBTZXJn ZXkgQmVyeW96a2luIHdyb3RlOg0KPiBIaQ0KPg0KPiBHaXZlbiB0aGF0IHRoZSBkcmFmdC10c2No b2ZlbmlnLW9hdXRoLWF1ZGllbmNlIFsxXSBoYXMgZXhwaXJlZCwgSSdtDQo+IHdvbmRlcmluZyBp ZiBpdCBpcyBzdGlsbCByZWxldmFudC4NCj4NCj4gSSBrbm93IHRoZSB0b2tlbiBpbnRyb3NwZWN0 aW9uIHJlc3BvbnNlIGNhbiBwcm92aWRlIHRoZSBhdWRpZW5jZQ0KPiB2YWx1ZShzKSwgYnV0IHRo ZSBxdWVzdGlvbiBpcyByZWFsbHkgaG93IGEgY2xpZW50IGlzIGFzc29jaWF0ZWQgd2l0aCBhIGEN Cj4gZ2l2ZW4gYXVkaWVuY2UgaW4gdGhlIGZpcnN0IHBsYWNlLiBBcyBzdWNoIFsxXSBtYXkgc3Rp bGwgbWFrZSBzZW5zZSwgZm9yDQo+IGV4YW1wbGUsIEkgY2FuIHRoaW5rIG9mIHR3byBvcHRpb25z Og0KPiAxLiB0aGUgY2xpZW50IGF1ZGllbmNlcyBhcmUgc2V0IG91dCBvZiBiYW5kIGR1cmluZyB0 aGUgY2xpZW50DQo+IHJlZ2lzdHJhdGlvbiB0aW1lIGFuZCBhbGwgdGhlIHRva2VucyBpc3N1ZWQg dG8gdGhhdCBjbGllbnQgd2lsbCBiZQ0KPiByZXN0cmljdGVkIGFjY29yZGluZ2x5DQo+IDIuIHRo ZSBjbGllbnQgaXMgcmVxdWVzdGluZyBhIHNwZWNpZmljIGF1ZGllbmNlIGR1cmluZyB0aGUgZ3Jh bnQgdG8NCj4gdG9rZW4gZXhjaGFuZ2UgYXMgcGVyIFsxXQ0KPg0KPiBJIGd1ZXNzIDEuIGlzIGhv dyBpdCBpcyBkb25lIGluIHByYWN0aWNlIG9yIGlzIDIuIGlzIGFsc28gYSB2YWxpZCBvcHRpb24g Pw0KPg0KPg0KPiBUaGFua3MsIFNlcmdleQ0KPg0KPg0KPiBbMV0gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXRzY2hvZmVuaWctb2F1dGgtYXVkaWVuY2UtMDANCj4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGlu ZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0 aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0 bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Ck9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_BY2PR03MB44200DD63CBEF54423164E6F5C20BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIg MiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDgg MyA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFs LCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxs b29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDoxMTExNTg4NjE5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDYwODU1NDY2O30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMgSSBzZWUgaXQsIEpvaG4ganVzdCBz YWlkIHRoZSBzYW1lIHRoaW5nIEkgZGlkIGluIHBhcmFsbGVsLCB1c2luZyBkaWZmZXJlbnQgd29y ZHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSm9obiBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZlN2p0 Yi5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDIwLCAyMDE2IDI6 NTYgUE08YnI+DQo8Yj5Ubzo8L2I+IE5hdCBTYWtpbXVyYTxicj4NCjxiPkNjOjwvYj4gTWlrZSBK b25lczsgb2F1dGg8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gU3RhdHVzIG9m IGRyYWZ0LXRzY2hvZmVuaWctb2F1dGgtYXVkaWVuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYXZlIGJlZW4gdGFsa2luZyBhYm91dCBwcm92aWRp bmcgdGhlIHJlc291cmNlIG9yIGF1ZGllbmNlIGFzIHRoZSBpbnB1dC48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSByZXNvdXJjZSB0eXBlIHdvdWxkIGJl IG1vcmUgYWJzdHJhY3QgdGhhbiBhdWRpZW5jZS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgaXMgc29tZXRoaW5nIHdlIHdv dWxkIG5lZWQgdG8gZGlzY3VzcyBpbiBhIHNwZWMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwcm9ibGVtIGZvZSBQT1AgaXMgdGhhdCB0 aGUgc2FtZSBzY29wZSBtYXkgY292ZXIgbXVsdGlwbGUgcmVzb3VyY2UgZW5kcG9pbnRzLiAmbmJz cDtFc3BlY2lhbGx5IHdoZW4gdXNpbmcgYSBzeW1tZXRyaWMga2V5IHlvdSBuZWVkIHRvIHNwZWNp Znkgd2hhdCBSZXNvdXJjZSBzZXJ2ZXIgeW91IGFyZSBzZW5kaW5nIHRoZSB0b2tlbiB0byBzbyB0 aGF0IGl0IGNhbiBiZSBlbmNyeXB0ZWQgd2l0aCB0aGUgY29ycmVjdA0KIGtleS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIEphbiAyMCwgMjAxNiwgYXQgNzo0NyBQTSwgTmF0IFNha2ltdXJhICZsdDs8YSBo cmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYj NDM7MTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywg SSBoYXZlIGFsd2F5cyB0aG91Z2h0IHRoYXQgaXQgd291bGQgYmUgZ29vZCBpZiBvbmUgY291bGQg YXNrIGZvciBhIHBhcnRpY3VsYXIgcmVzb3VyY2UgdHlwZSwgYW5kIHRoZSBzZXJ2ZXIgY291bGQg cmVzcG9uZCB3aXRoIHRoZSBhY3R1YWwgbG9jYXRpb24gb2YgaXQgd2l0aCB0aGUgYXNzb2NpYXRl ZCBhY2Nlc3MgdG9rZW4uIFRoaXMgaXMgYmVjYXVzZSBpdCBpcyBvZnRlbiB1bmRlc2lyYWJsZSB0 bw0KIHRlbGwgdGhlIGNsaWVudCB0aGUgbG9jYXRpb24gb2YgdGhlIHJlc291cmNlIGJlZm9yZSB0 aGUgYXV0aG9yaXphdGlvbiBmcm9tIHRoZSBwcml2YWN5IHBvaW50IG9mIHZpZXcuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCB0 aGUgcHJvY2Vzc2luZyBmbG93IGluIHRoaXMgY2FzZSB3aWxsIGJlOiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpUaGUgY2xpZW50IHJlcXVl c3QgYW4gYWNjZXNzIHRvIHRoZSByZXNvdXJjZSB0eXBlIGluIHRoZSBzY29wZSBvZiB0aGUgYXV0 aG9yaXphdGlvbiByZXF1ZXN0LiZuYnNwOzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZSBjbGllbnQgcmVxdWVzdCBhbiBh Y2Nlc3MgdG9rZW4gdG8gdGhlIHJlc291cmNlIHR5cGUgdG8gdGhlIHRva2VuIGVuZHBvaW50IHdp dGggYXVkaWVuY2UvcmVzb3VyY2Uvc2NvcGUgcGFyYW1ldGVyLiZuYnNwOzxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZSB0 b2tlbiBlbmRwb2ludCByZXNwb25kcyB3aXRoIHRva2VuIHJlc3BvbnNlIHdpdGggb2F1dGgtbWV0 YSBoZWFkZXIgaW5kaWNhdGluZyB0aGUgVVJMIG9mIHRoZSByZXNvdXJjZSBhcyBpbiZuYnNwOyZu YnNwO2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEuJm5ic3A7PG86cD48L286cD48L2xpPjwvb2w+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LCZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIE1pbmNobyZxdW90OyI+5bm0PC9zcGFuPjE8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7Ij7mnIg8L3NwYW4+ MjE8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgTWluY2hvJnF1b3Q7Ij7ml6U8L3Nw YW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBNaW5jaG8mcXVvdDsiPuacqDwv c3Bhbj4pIDc6MjcgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0 Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g SmFuIDIwLCAyMDE2LCBhdCA3OjI1IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkFzIG1lbnRpb25lZCBpbiBQcmFndWUsIEF6dXJlIEFjdGl2ZSBEaXJlY3Rv cnkgdXNlcyBhIOKAnHJlc291cmNl4oCdIHJlcXVlc3QgcGFyYW1ldGVyIHRvIHN1cHBseSB0aGUg VVJMIG9mIHRoZSByZXNvdXJjZSBzZXJ2ZXIgdGhhdCB0aGUgYWNjZXNzIHRva2VuIGlzIGludGVu ZGVkDQogZm9yLiZuYnNwOyBIb3dldmVyLCBJIGJlbGlldmUgdGhhdCBHb29nbGUgdXNlcyBzY29w ZSB2YWx1ZXMgZm9yIHRoaXMgYW5kIHNvbWUgTWljcm9zb2Z0IHNlcnZpY2VzIGFyZSBtb3Zpbmcg dG93YXJkcyB1c2luZyBzY29wZSB2YWx1ZXMgYXMgd2VsbC4mbmJzcDsgU29ydGluZyB0aGlzIG91 dCBzb29uIHdvdWxkIGJlIGdvb2QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDtPQXV0aCBbPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSZuYnNwOzxiPk9uDQogQmVoYWxmIE9mJm5i c3A7PC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7V2VkbmVzZGF5LCBK YW51YXJ5IDIwLCAyMDE2IDI6MTggUE08YnI+DQo8Yj5Ubzo8L2I+Jm5ic3A7SGFubmVzIFRzY2hv ZmVuaWc8YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7b2F1dGg8YnI+DQo8Yj5TdWJqZWN0OjwvYj4mbmJz cDtSZTogW09BVVRILVdHXSBTdGF0dXMgb2YgZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5j ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlcmUgZG9lcyBzZWVt IHRvIGJlIGEgbmVlZCB0byBwcm92aWRlIHRoZSBjbGllbnQgYSBtZWFucyBvZiB0ZWxsaW5nIHRo ZSBBUyB0aGUgcGxhY2UocykgYW5kL29yIGVudGl0eShzKSB3aGVyZSBpdCBpbnRlbmRzIHRvIHVz ZSB0aGUgdG9rZW4gaXQncyBhc2tpbmcgZm9yLiBBbmQgdGhhdCBpdCdzIGNvbW1vbiBlbm91Z2gg dG8gd2FycmFudCBpdCdzIG93biBzbWFsbA0KIHNwZWMuIFRoaXMgaGFzIGNvbWUgdXAgc2V2ZXJh bCB0aW1lcyBiZWZvcmUgYW5kIEkgdGhpbmsgaGFzIHNvbWUgY29uc2Vuc3VzIGJlaGluZCBkb2lu ZyBpdC4gV2hhdCBuZWVkcyB0byBoYXBwZW4gdG8gbW92ZSBmb3J3YXJkPzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNvbmNlcHQgc2hvd3Mg dXAgaW4gdGhlc2UgdGhyZWUgZGlmZmVyZW50IGRyYWZ0cyAodGhhdCBJIGtub3cgb2YgYW55d2F5 KTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXRzY2hvZmVuaWctb2F1dGgtYXVkaWVuY2UtMDAjc2VjdGlvbi0z IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRzY2hvZmVuaWctb2F1dGgtYXVkaWVuY2UtMDAjc2VjdGlv bi0zPC9zcGFuPjwvYT4mbmJzcDtoYXMgYW4gYXVkaWVuY2UgcGFyYW1ldGVyJm5ic3A7PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtcG9w LWtleS1kaXN0cmlidXRpb24tMDIjc2VjdGlvbi0zIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt b2F1dGgtcG9wLWtleS1kaXN0cmlidXRpb24tMDIjc2VjdGlvbi0zPC9zcGFuPjwvYT4mbmJzcDto YXMgYW4gYXVkIHBhcmFtZXRlciZuYnNwOzxicj4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtdG9rZW4tZXhjaGFuZ2UtMDMjc2VjdGlvbi0yLjEi IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXRva2VuLWV4Y2hhbmdlLTAzI3NlY3Rpb24t Mi4xPC9zcGFuPjwvYT4mbmJzcDtoYXMgYm90aCBhbiBhdWRpZW5jZSBhbmQgYSByZXNvdXJjZSBy ZXNvdXJjZTxicj4NCjxicj4NCkFsbCB0aGUgYWJvdmUgYXBwbHkgb25seSB0byB0aGUgdG9rZW4g cmVxdWVzdC4gSG93ZXZlciwgdGhlcmUgYXJlJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi00LjIiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj53YXlzIG9mIHJlcXVlc3Rpbmcvb2J0YWluaW5nIGFjY2VzcyB0 b2tlbnMgdGhhdCBkb24ndCBpbnZvbHZlIHRoZSB0b2tlbiBlbmRwb2ludDwvc3Bhbj48L2E+Jm5i c3A7c28NCiBJIHRoaW5rIGl0IGZvbGxvd3MgdGhhdCZuYnNwOyB0aGUgc2FtZSBmYWNpbGl0eSBz aG91bGQgYmUgYXZhaWxhYmxlIGZvciB0aGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IHRvby4mbmJz cDs8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAyMCwgMjAxNiBhdCA3OjI3IEFN LCBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2Zlbmln QGdteC5uZXQiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5oYW5u ZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgU2VyZ2V5LDxicj4NCjxi cj4NCnRoYXQncyBhIGdvb2QgcXVlc3Rpb24uIEFmdGVyIHRoaXMgZG9jdW1lbnQgd2FzIHB1Ymxp c2hlZCB0aGU8YnI+DQpmdW5jdGlvbmFsaXR5IGhhZCBiZWVuIGludGVncmF0ZWQgaW50byB0aGUg UG9QIHNvbHV0aW9uIGRvY3VtZW50Ljxicj4NClJlY2VudGx5LCBJIGdvdCBmZWVkYmFjayB0aGF0 IHRoZSBmdW5jdGlvbmFsaXR5IHNob3VsZCBiZSBtb3JlIGdlbmVyaWM8YnI+DQphbmQgaXQgaXMg aW5kZXBlbmRlbnQgb2YgdGhlIFBvUCB3b3JrLjxicj4NCjxicj4NClNvLCBJIGd1ZXNzIGl0IGlz IGEgZ29vZCB0aW1lIHRvIGRpc2N1c3MgdGhlIG5lZWRlZCBmdW5jdGlvbmFsaXR5IGFuZDxicj4N CndoZXJlIGl0IHNob3VsZCBiZSBpbmNsdWRlZC48YnI+DQo8YnI+DQpDaWFvPGJyPg0KPHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPkhhbm5lczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCjxicj4NCk9uIDAxLzIwLzIwMTYgMTE6MjUgQU0sIFNlcmdleSBCZXJ5 b3praW4gd3JvdGU6PGJyPg0KJmd0OyBIaTxicj4NCiZndDs8YnI+DQomZ3Q7IEdpdmVuIHRoYXQg dGhlIGRyYWZ0LXRzY2hvZmVuaWctb2F1dGgtYXVkaWVuY2UgWzFdIGhhcyBleHBpcmVkLCBJJ208 YnI+DQomZ3Q7IHdvbmRlcmluZyBpZiBpdCBpcyBzdGlsbCByZWxldmFudC48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBJIGtub3cgdGhlIHRva2VuIGludHJvc3BlY3Rpb24gcmVzcG9uc2UgY2FuIHByb3Zp ZGUgdGhlIGF1ZGllbmNlPGJyPg0KJmd0OyB2YWx1ZShzKSwgYnV0IHRoZSBxdWVzdGlvbiBpcyBy ZWFsbHkgaG93IGEgY2xpZW50IGlzIGFzc29jaWF0ZWQgd2l0aCBhIGE8YnI+DQomZ3Q7IGdpdmVu IGF1ZGllbmNlIGluIHRoZSBmaXJzdCBwbGFjZS4gQXMgc3VjaCBbMV0gbWF5IHN0aWxsIG1ha2Ug c2Vuc2UsIGZvcjxicj4NCiZndDsgZXhhbXBsZSwgSSBjYW4gdGhpbmsgb2YgdHdvIG9wdGlvbnM6 PGJyPg0KJmd0OyAxLiB0aGUgY2xpZW50IGF1ZGllbmNlcyBhcmUgc2V0IG91dCBvZiBiYW5kIGR1 cmluZyB0aGUgY2xpZW50PGJyPg0KJmd0OyByZWdpc3RyYXRpb24gdGltZSBhbmQgYWxsIHRoZSB0 b2tlbnMgaXNzdWVkIHRvIHRoYXQgY2xpZW50IHdpbGwgYmU8YnI+DQomZ3Q7IHJlc3RyaWN0ZWQg YWNjb3JkaW5nbHk8YnI+DQomZ3Q7IDIuIHRoZSBjbGllbnQgaXMgcmVxdWVzdGluZyBhIHNwZWNp ZmljIGF1ZGllbmNlIGR1cmluZyB0aGUgZ3JhbnQgdG88YnI+DQomZ3Q7IHRva2VuIGV4Y2hhbmdl IGFzIHBlciBbMV08YnI+DQomZ3Q7PGJyPg0KJmd0OyBJIGd1ZXNzIDEuIGlzIGhvdyBpdCBpcyBk b25lIGluIHByYWN0aWNlIG9yIGlzIDIuIGlzIGFsc28gYSB2YWxpZCBvcHRpb24gPzxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MsIFNlcmdleTxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBbMV0mbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtdHNjaG9mZW5pZy1vYXV0aC1hdWRpZW5jZS0wMCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10 c2Nob2ZlbmlnLW9hdXRoLWF1ZGllbmNlLTAwPC9zcGFuPjwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZuYnNwOzxhIGhyZWY9Im1haWx0bzpPQXV0 aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk9B dXRoQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQomZ3Q7Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFu PjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cHVycGxlIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0 aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB44200DD63CBEF54423164E6F5C20BY2PR03MB442namprd_-- From nobody Wed Jan 20 15:01:07 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CDB1B2A57 for ; Wed, 20 Jan 2016 15:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbERMaHjH6Q1 for ; Wed, 20 Jan 2016 15:01:04 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA831B2A30 for ; Wed, 20 Jan 2016 15:01:04 -0800 (PST) X-AuditID: 1209190e-f79046d0000036c0-3a-56a011ae740a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 57.96.14016.EA110A65; Wed, 20 Jan 2016 18:01:02 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u0KN11og015915; Wed, 20 Jan 2016 18:01:02 -0500 Received: from [192.168.128.48] (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 u0KN0x8S007241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Jan 2016 18:01:01 -0500 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4EECEA1D-0541-40F6-8E83-AA582E27BE98"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5.2 From: Justin Richer In-Reply-To: Date: Wed, 20 Jan 2016 18:00:59 -0500 Message-Id: References: <569E2276.5070407@gmx.net> <8A2DAF46-BAF7-439D-8FE3-65EA2DA8E692@mit.edu> <47F7D0BA-8E98-4E37-BA84-D128C0FD8396@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFKsWRmVeSWpSXmKPExsUixG6nrrtOcEGYwbY2HYu90z6xWJx8+4rN YvXdv2wOzB5Llvxk8mjd8Zfd4/btjSwBzFFcNimpOZllqUX6dglcGROWXWYt2KdZ0dSxjr2B ca9SFyMnh4SAicT5F3PYIGwxiQv31gPZXBxCAouZJKZ8nQflbGSU+PD5DJRzm0ni48vfTCAt wgKBEq9mr2QHsXkF9CRe3brMClLELDCFUaLlzBeWLkYOoLlSEjP2C4DUsAmoSkxf0wLWyylg J7F2wTJGkBIWoPj6iVIgYWaBKInu3T/ZQcK8AlYSM95UgISFBDqYJN71WIPYIgIqEvv2PWKE OFpWYvfvR0wTGAVnITliFrIjZoGN1ZZYtvA1M4StKbG/ezlUXF5i+9s5UHFLicUzb0DFbSVu 9S1ggrDtJB5NW8S6gJFjFaNsSm6Vbm5iZk5xarJucXJiXl5qka6xXm5miV5qSukmRlA0cUry 7WD8elDpEKMAB6MSD++Na/PDhFgTy4orcw8xSnIwKYnyfuFZECbEl5SfUpmRWJwRX1Sak1p8 iFEFaNejDasvMEqx5OXnpSqJ8Oo9AmrlTUmsrEotyocpk+ZgURLn3dUxN0xIID2xJDU7NbUg tQgmK8PBoSTBKy8AtECwKDU9tSItM6cEIc3EwXmIUYKDB2i4DkgNb3FBYm5xZjpE/hSjopQ4 70d+oIQASCKjNA+uF5QEE94eNn3FKA70ljBEOw8wgcJ1vwIazAQ0eK8ZyNXFJYkIKakGximu R/9P4PHfVRBhczxa9I/Hiy5pycnHu0SObdzbfNxkw7bj9nun872b9HxTleq8K50nvPWMg8SP Z9muKTrzbPm+/S/z2gL/9uZMXfLO7+s8g+P7fyifcX8nHb1yZqaRwOmzM3yWT2VoUuFfcXOH UvWr1kO5X56dunTjjqXwzw1mT/tkYwMPHxZXYinOSDTUYi4qTgQAJD1ll10DAAA= Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 23:01:07 -0000 --Apple-Mail=_4EECEA1D-0541-40F6-8E83-AA582E27BE98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As it=E2=80=99s currently written it=E2=80=99s not really limited to = defining JWT claims, and so I=E2=80=99m with John that if that=E2=80=99s = what this turns into and stays that way then it=E2=80=99s fine. I=E2=80=99= m very afraid of scope creep and this being used for something it = shouldn=E2=80=99t be. And, as Mike well knows, I did not support the decision to bring JWT to = this group, nor do I think we should be necessarily bound by the = mistakes of the past when making future decisions of what to work on. :) =E2=80=94 Justin > On Jan 20, 2016, at 5:07 PM, John Bradley wrote: >=20 > So if this is scoped to be a registry for the values of a JWT claim = then it is fine. > We should discourage people from thinking that it is part of the OAuth = protocol vs JWT claims. >=20 > John B. >=20 >> On Jan 20, 2016, at 6:29 PM, Mike Jones = wrote: >>=20 >> The primary purpose of the specification is to establish a registry = for "amr" JWT claim values. This is important, as it increases = interoperability among implementations using this claim. >>=20 >> It's a fair question whether "requested_amr" should be kept or = dropped. I agree with John and James that it's bad architecture. I put = it in the -00 individual draft to document existing practice. I suspect = that should the draft is adopted by the working group as a starting = point, one of the first things the working group will want to decide is = whether to drop it. I suspect that I know how this will come out and I = won't be sad, architecturally, to see it go. >>=20 >> As to whether this belongs in the OAuth working group, long ago it = was decided that JWT and JWT claim definitions were within scope of the = OAuth working group. That ship has long ago sailed, both in terms of = RFC 7519 and it continues to sail, for instance, in = draft-ietf-oauth-proof-of-possession, which defines a new JWT claim, and = is in the RFC Editor Queue. Defining a registry for values of the "amr" = claim, which is registered in the OAuth-established registry at = http://www.iana.org/assignments/jwt, is squarely within the OAuth WG's = mission for the creation and stewardship of JWT. >>=20 >> -- Mike >>=20 >> -----Original Message----- >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley >> Sent: Wednesday, January 20, 2016 12:44 PM >> To: Justin Richer >> Cc: >> Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method = Reference Values >>=20 >> I see your point that it is a fine line reporting how a person = authenticated to a Authorization endpoit (it might be by SAML etc) and = encouraging people to use OAuth for Authentication. >>=20 >> We already have the amr response in connect. The only thing really = missing is a registry. Unless this is a sneaky way to get requested_amr = into Connect? >>=20 >> John B. >>> On Jan 20, 2016, at 5:37 PM, Justin Richer wrote: >>>=20 >>> Just reiterating my stance that this document detailing user = authentication methods has no place in the OAuth working group. >>>=20 >>> =E2=80=94 Justin >>>=20 >>>> On Jan 19, 2016, at 6:48 AM, Hannes Tschofenig = wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> this is the call for adoption of Authentication Method Reference >>>> Values, see >>>> https://tools.ietf.org/html/draft-jones-oauth-amr-values-03 >>>>=20 >>>> Please let us know by Feb 2nd whether you accept / object to the >>>> adoption of this document as a starting point for work in the OAuth >>>> working group. >>>>=20 >>>> Note: The feedback during the Yokohama meeting was inconclusive, >>>> namely >>>> 9 for / zero against / 6 persons need more information. >>>>=20 >>>> You feedback will therefore be important to find out whether we >>>> should do this work in the OAuth working group. >>>>=20 >>>> Ciao >>>> Hannes & Derek >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 --Apple-Mail=_4EECEA1D-0541-40F6-8E83-AA582E27BE98 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJWoBGrAAoJEDPAngkbd+w9vDwIAImZP/Ex56mpLiE69VDmSyPg +uZhrBhvuKocBU+loy6dn6kgotjvHfWYVog5ajz5lHk+DyAPBLTd5JHCTbundJGf SzZ/LvSnsUldIsl/6d57e5D912f8PLHD/00Gxny9z0nHnfVr0KbkvbgunB5NlYiW GKEDReoogQrhs3rn7uwVvvzPTGzKdZf1iASfzi0tGCd5RpED/7SFWktsBNWOg03Z oKMsSNWdeSmWDb694CQzM4k2Z1GdinX6HkdSy+sstlygDZpIRs/28a6ZP07q39HU VEJiB2p5uNur7Udh/UMZcJPClPLTD9AoSrDFnKjHRtfZw/lA4SGvHEzWeEcmvyM= =5kfM -----END PGP SIGNATURE----- --Apple-Mail=_4EECEA1D-0541-40F6-8E83-AA582E27BE98-- From nobody Wed Jan 20 15:06:20 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505051B2A66 for ; Wed, 20 Jan 2016 15:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vBbj43BpK6X for ; Wed, 20 Jan 2016 15:06:14 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6ED1B2A5B for ; Wed, 20 Jan 2016 15:06:13 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id s5so9508478qkd.0 for ; Wed, 20 Jan 2016 15:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=vwe9oJP28H9h43/qzbzcI78+caDoGb9+YMEum8RfbS8=; b=UD05Krn0TPsVnxY+i4EMuVDdshWTZSfVV5SK/WORYuEFOpI7mNQIb2igh6eOykbxYJ /fEDp31WYwtzXXczo9RgmTvhSzLRCHZAdlbDAhxI2oTe65TY10ZQg5MReJNajTOhfJNz QsoIcPeK+zAFvRqHmpNd3kGm+zdsovhz2pqQ181LkGgZyGPhpiOyVp82PbbhB8jVNOjt NwfjpHhq6z+OFDtVlyG1/m8vTDloXxkx1DSO8uMEJuG4OOBjRUH4zRZiu+mKwPRPQW9J /1qD+me95l9W/BaIswQH7xXirtl7honjDf7Nsn4FmQA03t2s8lR9anroO6eBi7SuDtlQ ADdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=vwe9oJP28H9h43/qzbzcI78+caDoGb9+YMEum8RfbS8=; b=KhseaYDvllgT6uQ8+rNHJrkER2uCTeu6JZJEzKzAaEwpXgYyZNhqDixw3kSIxnmrbO spaQvzLoyvsrzYdY4PQHdHVhTO4cm+43eUICmMmmcuNOqldxfsSJMZJRlwp+TUibGZSY z3/YmkKzEA1tBd4B5u2AASShyehiVnHQfqdAvOh+EJW0ovm6vfnguZgqGR4s8BGuULgD BynlISGUJaZnzBD4u0Vl+c8hWAQBebOULlO4XUiHsxUS1yIZxGhmm8Ai80+HLRgQK/9k g8E3YI2fgzCqt19eMlU6V8PnGeeol8JocTl9vIZ0rwbSQo8hUM78BBp9SQKL+tAmixkn uNGQ== X-Gm-Message-State: ALoCoQkzhI+A11IHJqIHmlzb+O0cSLLQJhlBr+b2hdRT7W8/Rz51Wb5df+GXRDAM4MvafG1SYvKikMJN2LYLRpkT5fh+hcaNdA== X-Received: by 10.55.20.211 with SMTP id 80mr48100919qku.67.1453331172898; Wed, 20 Jan 2016 15:06:12 -0800 (PST) MIME-Version: 1.0 References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> <569F60B3.3030501@gmail.com> <569F9955.9030001@gmx.net> <1D483C18-6103-4197-9AF0-D4FD80E8F17E@ve7jtb.com> In-Reply-To: From: Nat Sakimura Date: Wed, 20 Jan 2016 23:06:02 +0000 Message-ID: To: Mike Jones , John Bradley Content-Type: multipart/alternative; boundary=001a114495464d3d7a0529cc08a9 Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 23:06:17 -0000 --001a114495464d3d7a0529cc08a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Correct. I am not saying specifying resource URI as audience is a bad thing. In fact, I need it as described below. I am just asking for adding another option. For John's case, if the client started from an abstract resource type, then the token endpoint first responds with the tokens and set of possible resource endpoints, preferably with more specific rels. Then, the client can make a second token request using the refresh token, this time with the concrete resource endpoint URI, to get the access token to that location. Nat 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 7:56 Mike Jones : > As I see it, John just said the same thing I did in parallel, using > different words. > > > > *From:* John Bradley [mailto:ve7jtb@ve7jtb.com] > *Sent:* Wednesday, January 20, 2016 2:56 PM > *To:* Nat Sakimura > *Cc:* Mike Jones; oauth > > > *Subject:* Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience > > > > We have been talking about providing the resource or audience as the inpu= t. > > > > The resource type would be more abstract than audience. > > > > That is something we would need to discuss in a spec. > > > > The problem foe POP is that the same scope may cover multiple resource > endpoints. Especially when using a symmetric key you need to specify wha= t > Resource server you are sending the token to so that it can be encrypted > with the correct key. > > > > John B. > > On Jan 20, 2016, at 7:47 PM, Nat Sakimura wrote: > > > > +1 > > > > Also, I have always thought that it would be good if one could ask for a > particular resource type, and the server could respond with the actual > location of it with the associated access token. This is because it is > often undesirable to tell the client the location of the resource before > the authorization from the privacy point of view. > > > > So, the processing flow in this case will be: > > > > 1. The client request an access to the resource type in the scope of > the authorization request. > 2. The client request an access token to the resource type to the > token endpoint with audience/resource/scope parameter. > 3. The token endpoint responds with token response with oauth-meta > header indicating the URL of the resource as in draft-sakimura-oauth-= meta. > > Best, > > > > Nat > > > > > > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 7:27 John Bradley : > > +1 > > > > On Jan 20, 2016, at 7:25 PM, Mike Jones > wrote: > > > > As mentioned in Prague, Azure Active Directory uses a =E2=80=9Cresource= =E2=80=9D request > parameter to supply the URL of the resource server that the access token = is > intended for. However, I believe that Google uses scope values for this > and some Microsoft services are moving towards using scope values as well= . > Sorting this out soon would be good. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org ] *O= n > Behalf Of *Brian Campbell > *Sent:* Wednesday, January 20, 2016 2:18 PM > *To:* Hannes Tschofenig > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience > > > > There does seem to be a need to provide the client a means of telling the > AS the place(s) and/or entity(s) where it intends to use the token it's > asking for. And that it's common enough to warrant it's own small spec. > This has come up several times before and I think has some consensus behi= nd > doing it. What needs to happen to move forward? > > The concept shows up in these three different drafts (that I know of > anyway): > > > https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 = has > an audience parameter > > https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#sect= ion-3 has > an aud parameter > http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1= has > both an audience and a resource resource > > All the above apply only to the token request. However, there are ways of > requesting/obtaining access tokens that don't involve the token endpoint > so I think it follows > that the same facility should be available for the authorization request > too. > > > > On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > > Hi Sergey, > > that's a good question. After this document was published the > functionality had been integrated into the PoP solution document. > Recently, I got feedback that the functionality should be more generic > and it is independent of the PoP work. > > So, I guess it is a good time to discuss the needed functionality and > where it should be included. > > Ciao > Hannes > > > > On 01/20/2016 11:25 AM, Sergey Beryozkin wrote: > > Hi > > > > Given that the draft-tschofenig-oauth-audience [1] has expired, I'm > > wondering if it is still relevant. > > > > I know the token introspection response can provide the audience > > value(s), but the question is really how a client is associated with a = a > > given audience in the first place. As such [1] may still make sense, fo= r > > example, I can think of two options: > > 1. the client audiences are set out of band during the client > > registration time and all the tokens issued to that client will be > > restricted accordingly > > 2. the client is requesting a specific audience during the grant to > > token exchange as per [1] > > > > I guess 1. is how it is done in practice or is 2. is also a valid optio= n > ? > > > > > > Thanks, Sergey > > > > > > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 > > > > _______________________________________________ > > 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 > > > --001a114495464d3d7a0529cc08a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Correct. I am not saying specifying resource URI as audien= ce is a bad thing. In fact, I need it as described below. I am just asking = for adding another option.=C2=A0

For John's case, if= the client started from an abstract resource type, then the token endpoint= first responds with the tokens and set of possible resource endpoints, pre= ferably with more specific rels.=C2=A0
Then, the client can make = a second token request using the refresh token, this time with the concrete= resource endpoint URI, to get the access token to that location.=C2=A0

Nat


2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 7:56= Mike Jones <Michael.Jone= s@microsoft.com>:

As I see it, John just sa= id the same thing I did in parallel, using different words.

=C2=A0

From: John Bra= dley [mailto:ve7jtb@= ve7jtb.com]
Sent: Wednesday, January 20, 2016 2:56 PM
To: Nat Sakimura
Cc: Mike Jones; oauth


Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience=

=C2=A0

We have been talking about providing the resource or= audience as the input.

=C2=A0

The resource type would be more abstract than audien= ce. =C2=A0

=C2=A0

That is something we would need to discuss in a spec= .

=C2=A0

The problem foe POP is that the same scope may cover= multiple resource endpoints.=C2=A0 Especially when using a symmetric key y= ou need to specify what Resource server you are sending the token to so tha= t it can be encrypted with the correct key.

=C2=A0

John B.

On Jan 20, 2016, at 7:47 PM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

=C2=A0

+1

=C2=A0

Also, I have always thought that it would be good if= one could ask for a particular resource type, and the server could respond= with the actual location of it with the associated access token. This is b= ecause it is often undesirable to tell the client the location of the resource before the authorization from= the privacy point of view.=C2=A0

=C2=A0

So, the processing flow in this case will be:=C2=A0<= u>

=C2=A0

  1. The client request an access to the resource type in the scope of the autho= rization request.=C2=A0
  2. The client request an access token to the resource type to the token endpoi= nt with audience/resource/scope parameter.=C2=A0
  3. The token endpoint responds with token response with oauth-meta header indi= cating the URL of the resource as in=C2=A0=C2=A0draft-sakimura-oauth-meta.= =C2=A0

Best,=C2=A0

=C2=A0

Nat

=C2=A0

=C2=A0

2016=E6=9C= =8821=E6=97=A5(=E6=9C=A8) 7:2= 7 John Bradley <v= e7jtb@ve7jtb.com>:

+1

=C2=A0

On Jan 20, 2016, at 7:25 PM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

=C2=A0

As mentioned in Prague, A= zure Active Directory uses a =E2=80=9Cresource=E2=80=9D request parameter t= o supply the URL of the resource server that the access token is intended for.=C2=A0 However, I believe that Google uses scope values for this and s= ome Microsoft services are moving towards using scope values as well.=C2=A0= Sorting this out soon would be good.

=C2=A0

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

=C2=A0

From:=C2=A0OAu= th [mailto:oauth-bounces@ietf.org]=C2=A0On Behalf Of=C2=A0Brian Campbell
Sent:=C2=A0Wednesday, January 20, 2016 2:18 PM
To:=C2=A0Hannes Tschofenig
Cc:=C2=A0oauth
Subject:=C2=A0Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audien= ce

=C2=A0

There does seem to be= a need to provide the client a means of telling the AS the place(s) and/or= entity(s) where it intends to use the token it's asking for. And that = it's common enough to warrant it's own small spec. This has come up several times before and I think has some consensus= behind doing it. What needs to happen to move forward?

The concept shows up in these three different drafts= (that I know of anyway):


https://tools.ietf= .org/html/draft-tschofenig-oauth-audience-00#section-3=C2=A0has = an audience parameter=C2=A0
https://tool= s.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3=C2=A0has an aud parameter=C2=A0
http://tools.ietf= .org/html/draft-ietf-oauth-token-exchange-03#section-2.1=C2=A0ha= s both an audience and a resource resource

All the above apply only to the token request. However, there are=C2=A0<= span style=3D"color:purple">ways of requesting/obtaining access tokens that= don't involve the token endpoint=C2=A0so I think it follows that=C2=A0 the same facility should be available for th= e authorization request too.=C2=A0

=C2=A0

On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig &= lt;hannes.tschofenig@gmx.net> wrote:<= u>

Hi Sergey,

that's a good question. After this document was published the
functionality had been integrated into the PoP solution document.
Recently, I got feedback that the functionality should be more generic
and it is independent of the PoP work.

So, I guess it is a good time to discuss the needed functionality and
where it should be included.

Ciao
Hannes



On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
> Hi
>
> Given that the draft-tschofenig-oauth-audience [1] has expired, I'= m
> wondering if it is still relevant.
>
> I know the token introspection response can provide the audience
> value(s), but the question is really how a client is associated with a= a
> given audience in the first place. As such [1] may still make sense, f= or
> example, I can think of two options:
> 1. the client audiences are set out of band during the client
> registration time and all the tokens issued to that client will be
> restricted accordingly
> 2. the client is requesting a specific audience during the grant to > token exchange as per [1]
>
> I guess 1. is how it is done in practice or is 2. is also a valid opti= on ?
>
>
> Thanks, Sergey
>
>
> [1]=C2=A0https://tools.= ietf.org/html/draft-tschofenig-oauth-audience-00
>
> _______________________________________________
> OAuth mailing list
>=C2=A0OAuth@ietf.org
>=C2=A0https://www.ietf.org/mailman/listinfo= /oauth


_______________________________________________
OAuth mailing list
OAuth@ietf.org
<= span style=3D"color:purple">https://www.ietf.org/mailman/listinfo/oauth

=C2=A0

______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut= h

=C2=A0

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

=C2=A0

--001a114495464d3d7a0529cc08a9-- From nobody Wed Jan 20 15:48:11 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B991B2AEA for ; Wed, 20 Jan 2016 15:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEqa99ytV_MI for ; Wed, 20 Jan 2016 15:48:08 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2B771B2AE6 for ; Wed, 20 Jan 2016 15:48:07 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id s68so9822930qkh.3 for ; Wed, 20 Jan 2016 15:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=16dJ4tHrPnAhUliOZzVsAnlERdER1A4z/O9THqUjxKU=; b=JplJy4qSpCoF56mVR93BO23SdBQz9uDxPjhDLWgWhAZ5bOlXYOrj2NNiFOb7bZgisP f2RMiggZ4Dy+qSEq+Zy6ViS5A1QJMbG8XRGYAT+K55DQXEFJIhrrlup0Ezd4ZALtR4/m apxXh6Ddn59cJkEjWGidgGYgLyn/JtdKF31ikMiBV7YEEk22A+bq+EUnp26LGnAZMW3Q mc3OsYo/Y3kfTRG0DgkIcfT3ZdJpQe5IOxl7XFUkOafC/k5/ddMwumYl9pDYAGrB0u5+ 1nOzushiVG2UFd/NXIIU8WmCIobm5uXareCCKveGukSI60D+NihRx6gQSpGftPk4vLML UYiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=16dJ4tHrPnAhUliOZzVsAnlERdER1A4z/O9THqUjxKU=; b=d/In374ToK2wAWcRV7vsYEIQx6fP/HHpwV7N1PQlYhhDeGaq8micBeHQvh0o32KY/U 88ZKIEox9X6ycZ7xWj08aiG7dgQXrcHKmTxNxL3K7G915+Wj3m64djgwjXX9g7bnwtNp VZ8L5XbGVgWSSGkud34eOyy0Lbt/mx+xhgKM9EkrkRCXIdM7FPqMnWWXZj0xfQfMHVo4 kwEL37Pt5HKLBhRG7KFL8XSVf5IY0LYXfOx5xdcIH5DR6hD3mcQoKVHPpbwL0vI7X+n2 3A+2/4AW1D/RB64DgFl01BZjh7cYLykHZfKlKDEYCUn6UBcrojZjddKv2E66aVbXnDvz ENjQ== X-Gm-Message-State: ALoCoQmLLSNXZ/vS2VWTpztiYKRiA9mNHS29gduO1IsGF67AbhQYhsRVxutOF4coQCVNdHLoZowHeZUK2W6Kv+teJ6zzNHmrSQ== X-Received: by 10.55.15.139 with SMTP id 11mr48214666qkp.50.1453333687184; Wed, 20 Jan 2016 15:48:07 -0800 (PST) MIME-Version: 1.0 References: <568D24DD.3050501@connect2id.com> <568D5610.6000506@lodderstedt.net> In-Reply-To: From: Nat Sakimura Date: Wed, 20 Jan 2016 23:47:56 +0000 Message-ID: To: William Denniss , Torsten Lodderstedt Content-Type: multipart/alternative; boundary=001a1147446e2a33f40529cc9ef5 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2016 23:48:10 -0000 --001a1147446e2a33f40529cc9ef5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I kind of prefer pkce_methods_supported as it scopes it more narrowly and less likely to be overloaded. 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 11:59 William Denniss : > Seems like we agree this should be added. How should it look? > > Two ideas: > > "code_challenge_methods_supported": ["plain", "S256"] > > or > > "pkce_methods_supported": ["plain", "S256"] > > > > On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> +1 >> >> >> Am 06.01.2016 um 18:25 schrieb William Denniss: >> >> +1 >> >> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley wrote: >> >>> Good point. Now that PKCE is a RFC we should add it to discovery. >>> >>> John B. >>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov < >>> vladimir@connect2id.com> wrote: >>> > >>> > I just noticed PKCE support is missing from the discovery metadata. >>> > >>> > Is it a good idea to add it? >>> > >>> > Cheers, >>> > >>> > Vladimir >>> > >>> > -- >>> > 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 >>> >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1147446e2a33f40529cc9ef5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I kind of prefer pkce_methods_supported as it scopes it more narrowly and l= ess likely to be overloaded.
2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 11:59 William Denniss <<= a href=3D"mailto:wdenniss@google.com">wdenniss@google.com>:
Seems like we agree this s= hould be added. How should it look?

Two ideas:

"code_cha= llenge_methods_supported": ["plain", "S256"]
<= br>
or

"pkce_methods_supported": [&q= uot;plain", "S256"]



On Wed, Jan 6, 2016 at 9:59= AM, Torsten Lodderstedt <torsten@lodderstedt.net> wro= te:
=20 =20 =20
+1


Am 06.01.2016 um 18:25 schrieb William Denniss:
+1

On Wed, Jan 6, 2016 at 6:40 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Good point.=C2=A0 Now that PKCE is a RFC we should add it to discovery.

John B.
> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
>
> I just noticed PKCE support is missing from the discovery metadata.
>
> Is it a good idea to add it?
>
> Cheers,
>
> Vladimir
>
> --
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@= ietf.org
> https://www.ietf.org/mailman/listinfo/oa= uth

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



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


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a1147446e2a33f40529cc9ef5-- From nobody Wed Jan 20 16:31:14 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40281ACE69 for ; Wed, 20 Jan 2016 16:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tSXpUrbK-qn for ; Wed, 20 Jan 2016 16:31:09 -0800 (PST) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 B50161B2B98 for ; Wed, 20 Jan 2016 16:31:07 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id n128so13113439pfn.3 for ; Wed, 20 Jan 2016 16:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=XJbFmfAlrVz4LltpFUmH6f9WMhrXAdBM/gW9J2j1vKI=; b=KIV+fYWxaSSyCc3azCTqEr1g9h1Dd/nbvfDDh7tIVZfiPxFlsXEDY08wnDPZt44l9y i3fqzfCLPO2DeHuUUezEnVBzjkNeDITJeeCEm72h+X5OS3o0tnr7P1B6EUsmCmhtsK5t fQZuypyI+D7hOGS5W3Hn5Lf6pv0Mf2A9wN9bb9t33YcD7BVQMjudQL67dbUJzSSJqJ6w UMsPi8a9bq032IdsNdohEeOX3psetF3wUU+qrP7qR4yroiEOpz3QryVXkDkkysAY4tTm vsgg5Jy5IVjKNLGNhMN9zLY9KFDNNO2trAfqy6gRObR8FvZ2zdzW0Pw2GQwAqH/UNpHH JS0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=XJbFmfAlrVz4LltpFUmH6f9WMhrXAdBM/gW9J2j1vKI=; b=Hk2eLlBdUb9THxjZgDLQa5QjpVFn9BgUEnJcJEIWte9xNP9d8Ht7+FRx4TK+i8HjFo WkY99TOFbDbulRcThQMjG9aBuywoXoAbdX1whWy20jhPpSy0DOAwKrD8GJJyhZ/l46On OG2bPaf43k1E99BhcsgKr66OodJDzQmeBFFgvwaKe2HH69HVvsiaR+vY94lkIuoV2036 8LSzXnlgJ3zPC3fYwwOX6cN9pJeeuH32uBPUU8HHGDJ4cl2HRlwxyoykL27P3By77YYQ NKG0xb6Wk4nDs9/2Yz4956YLEf2ngd3Qa1Gv37SpEAZGetvsQh3f49gaYnX+XxbOF9hZ BPBA== X-Gm-Message-State: ALoCoQk+ViIiL14VcZ3wsZUt7JOxhBzOCDFoUvUWjeOuJ4fkZY7ruOmea1VxbfSXy5ypvFcJ5e5Pu2HkFYReUbLmdyCDcYANiQ== X-Received: by 10.98.17.142 with SMTP id 14mr56056115pfr.37.1453336267231; Wed, 20 Jan 2016 16:31:07 -0800 (PST) Received: from [192.168.1.16] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id 72sm51268080pfk.28.2016.01.20.16.31.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 16:31:06 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_DFF07BB5-45F0-49E7-B03F-6A8FD2C984E1" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: nov matake In-Reply-To: Date: Thu, 21 Jan 2016 09:31:03 +0900 Message-Id: References: <568D24DD.3050501@connect2id.com> <568D5610.6000506@lodderstedt.net> To: William Denniss X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 00:31:10 -0000 --Apple-Mail=_DFF07BB5-45F0-49E7-B03F-6A8FD2C984E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since the = registered parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, = not =E2=80=9Cpkce_method". > On Jan 19, 2016, at 11:58, William Denniss = wrote: >=20 > Seems like we agree this should be added. How should it look? >=20 > Two ideas: >=20 > "code_challenge_methods_supported": ["plain", "S256"] >=20 > or >=20 > "pkce_methods_supported": ["plain", "S256"] >=20 >=20 >=20 > On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt = > wrote: > +1 >=20 >=20 > Am 06.01.2016 um 18:25 schrieb William Denniss: >> +1 >>=20 >> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley > wrote: >> Good point. Now that PKCE is a RFC we should add it to discovery. >>=20 >> John B. >> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov = > wrote: >> > >> > I just noticed PKCE support is missing from the discovery metadata. >> > >> > Is it a good idea to add it? >> > >> > Cheers, >> > >> > Vladimir >> > >> > -- >> > 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 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_DFF07BB5-45F0-49E7-B03F-6A8FD2C984E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, = since the registered parameter name is =E2=80=9Ccode_challenge_method=E2=80= =9D, not =E2=80=9Cpkce_method".

On = Jan 19, 2016, at 11:58, William Denniss <wdenniss@google.com>= wrote:

Seems like we agree this should be added. How = should it look?

Two ideas:

"code_challenge_methods_supported": ["plain", "S256"]

or

"pkce_methods_supported": = ["plain", "S256"]



On Wed, Jan 6, 2016 at 9:59 AM, = Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=20 =20 =20
+1


Am 06.01.2016 um 18:25 schrieb William Denniss:
+1

On Wed, Jan 6, 2016 at 6:40 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Good point.  Now that PKCE is a RFC we should add it to discovery.

John B.
> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
>
> I just noticed PKCE support is missing from the discovery metadata.
>
> Is it a good idea to add it?
>
> Cheers,
>
> Vladimir
>
> --
> 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



_______________________________________________
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=_DFF07BB5-45F0-49E7-B03F-6A8FD2C984E1-- From nobody Wed Jan 20 17:26:17 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7416F1B2C84 for ; Wed, 20 Jan 2016 17:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfYJbxOv7ao9 for ; Wed, 20 Jan 2016 17:26:15 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7F01B2C7C for ; Wed, 20 Jan 2016 17:26:14 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0L1QCrP027103 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jan 2016 01:26:12 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 u0L1QC8a015593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jan 2016 01:26:12 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u0L1QC7i019678; Thu, 21 Jan 2016 01:26:12 GMT Received: from [192.168.3.132] (/96.44.121.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Jan 2016 17:26:12 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-E8DB684A-F4BC-484A-8E5D-CA7066F8456F Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13C75) In-Reply-To: Date: Wed, 20 Jan 2016 17:26:00 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <569E22E1.5010402@gmx.net> To: Brian Campbell X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 01:26:16 -0000 --Apple-Mail-E8DB684A-F4BC-484A-8E5D-CA7066F8456F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 for adoption +1 for Brian's comments Phil > On Jan 20, 2016, at 14:42, Brian Campbell wro= te: >=20 > I conditionally accept this document as a starting point for work in the O= Auth working group on the assumption that the considerable simplifications d= iscussed and accepted at http://www.ietf.org/mail-archive/web/oauth/current/= msg15351.html will be incorporated. >=20 > This document is (should be) intended to provide a mitigation to a securit= y problem. As such, it would be nice to see it progress a little faster than= the typical WG document. The more quickly the document can progress and/or b= e perceived as stable, the better. >=20 >> On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig wrote: >> Hi all, >>=20 >> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 >>=20 >> Please let us know by Feb 9th whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >>=20 >> Note: This call is related to the announcement made on the list earlier >> this month, see >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More >> time for analysis is provided due to the complexity of the topic. >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-E8DB684A-F4BC-484A-8E5D-CA7066F8456F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 for adoption

+1 for Brian's commen= ts

Phil

On Jan 20, 2016, at 14:42, Brian Campbell <<= a href=3D"mailto:bcampbell@pingidentity.com">bcampbell@pingidentity.com&= gt; wrote:

I conditionally accept this document as a starting point for work in the OA= uth working group on the assumption that the considerable simplifications di= scussed and accepted at http://www.ietf.org/mail-archive/= web/oauth/current/msg15351.html will be incorporated.

= This document is (should be) intended to provide a mitigation to a security p= roblem. As such, it would be nice to see it progress a little faster than th= e typical WG document. The more quickly the document can progress and/or be p= erceived as stable, the better.
On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofe= nig <hannes.tschofenig@gmx.net> wrote:
Hi all,

this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
https://tools.ietf.org/html/draft-jo= nes-oauth-mix-up-mitigation-00

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

Note: This call is related to the announcement made on the list earlier
this month, see
http://www.ietf.org/mail-archive/web/o= auth/current/msg15336.html. More
time for analysis is provided due to the complexity of the topic.

Ciao
Hannes & Derek


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


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-E8DB684A-F4BC-484A-8E5D-CA7066F8456F-- From nobody Wed Jan 20 17:30:31 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBC61B2C8B for ; Wed, 20 Jan 2016 17:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t79edJVNWrp0 for ; Wed, 20 Jan 2016 17:30:28 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067E31B2C89 for ; Wed, 20 Jan 2016 17:30:27 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0L1UPKE030929 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jan 2016 01:30:26 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u0L1UPo4024601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 21 Jan 2016 01:30:25 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u0L1UPWZ020955; Thu, 21 Jan 2016 01:30:25 GMT Received: from [192.168.3.132] (/96.44.121.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Jan 2016 17:30:25 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13C75) In-Reply-To: <8A2DAF46-BAF7-439D-8FE3-65EA2DA8E692@mit.edu> Date: Wed, 20 Jan 2016 17:30:14 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <569E2276.5070407@gmx.net> <8A2DAF46-BAF7-439D-8FE3-65EA2DA8E692@mit.edu> To: Justin Richer X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for Adoption: Authentication Method Reference Values X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 01:30:29 -0000 Right but OAuth is the layer that needs to relay the request to the authen s= ervice.=20 +1 on adoption However we need to discuss more on w this as a registry or how it is used in= the overall architecture to pass signalling (hint maybe that falls to conne= ct?)=20 Phil > On Jan 20, 2016, at 12:37, Justin Richer wrote: >=20 > Just reiterating my stance that this document detailing user authenticatio= n methods has no place in the OAuth working group. >=20 > =E2=80=94 Justin >=20 >> On Jan 19, 2016, at 6:48 AM, Hannes Tschofenig wrote: >>=20 >> Hi all, >>=20 >> this is the call for adoption of Authentication Method Reference Values, s= ee >> https://tools.ietf.org/html/draft-jones-oauth-amr-values-03 >>=20 >> Please let us know by Feb 2nd whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >>=20 >> Note: The feedback during the Yokohama meeting was inconclusive, namely >> 9 for / zero against / 6 persons need more information. >>=20 >> You feedback will therefore be important to find out whether we should >> do this work in the OAuth working group. >>=20 >> Ciao >> Hannes & Derek >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Jan 20 17:48:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC281B2C90 for ; Wed, 20 Jan 2016 17:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSvr3jhZb0ou for ; Wed, 20 Jan 2016 17:48:15 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 BB36F1B2CC4 for ; Wed, 20 Jan 2016 17:48:14 -0800 (PST) Received: by mail-qg0-x234.google.com with SMTP id e32so21592094qgf.3 for ; Wed, 20 Jan 2016 17:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=xEFjPyrCiAb27j9o6YGCSXiI1mY5at7hw02mSytaCnw=; b=iE0F/On0dY9XppbLT9AA8Fh0nJ/DY2s5xyzxAYSyDfPqUStAcsTLV6/FnrLyezdlsk nfd2jKJCpAENXlr5ywFsh7h6fi4savz115HyInFIY7w0Zp1v1yTP0bqLn5KyWK7/+jiA puFRMjc4WUZgHslByL0siNz0rUxMkWAvRkVFIcUQ9d/gSOnWXN6gMs1TAFw2fEjhgGUl yXfLrGZCXYxG3IRo0tUQSYffAXG1d++Svebgk+AE/qcDyY/rTKzizZm2wfxgeYgCTChW N18q6AZQJIjG0H23P5u42Z3qEfh/KZenIzCayf/2MszHpjcvm5f7BTM+J+3Z0KLACeVt mO0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=xEFjPyrCiAb27j9o6YGCSXiI1mY5at7hw02mSytaCnw=; b=MR38P/0E0TI4Ht2CHFfZxGH7OSZxT5Ddl1GIH3Tme1fg67VXZwpaUZwISRUoNQJgSl bGz+xAs1THiTrTUAeL7r5JrjOEDDWFqtXctJgx8xU1JW0zMr9l/omLJSpASLsuVaw2W+ MURbpxkVt/wB7BcF3E8IVWwmn0VK/ThHu0eY7YPnqYNjL5Bl4HmHaipu5cv0UCdmdd6Y XaMdfhIIOCoi6ZWzD8T8Kt1eLw3Grei5lqEQCsd86bpKzMznipsl0vkEBNkrv90WfHQR sps3RfNQBY6/nfKc+rb7VJ6HXC84LO7T43g3M6l+yD+2sN03O8K0SLQk4plt9+GUkuhB pl1g== X-Gm-Message-State: ALoCoQlRm+fuyhbK0MvgyDraVeYIPQn27gE96WkvP8oA+oOa+2Wmu/zRgvFQWh+fjSpW//uO15UZRyw3462hia5zUx+peLppZQ== X-Received: by 10.140.221.70 with SMTP id r67mr52994483qhb.84.1453340893835; Wed, 20 Jan 2016 17:48:13 -0800 (PST) Received: from [192.168.8.101] ([181.202.164.7]) by smtp.gmail.com with ESMTPSA id l107sm15461374qge.22.2016.01.20.17.48.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 20 Jan 2016 17:48:13 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_E6BCC62D-EFFD-4680-9CF8-D7CFDEAF766D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Wed, 20 Jan 2016 22:48:10 -0300 Message-Id: <24B75197-1E94-4EE2-B51A-E5928D62BF3A@ve7jtb.com> References: <569E22E1.5010402@gmx.net> To: "Phil Hunt (IDM)" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 01:48:17 -0000 --Apple-Mail=_E6BCC62D-EFFD-4680-9CF8-D7CFDEAF766D Content-Type: multipart/alternative; boundary="Apple-Mail=_761C1590-49AE-4672-BC5D-D56DB6A4D667" --Apple-Mail=_761C1590-49AE-4672-BC5D-D56DB6A4D667 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 for adoption Mike and I are working on addressing the comments in a new draft for = your reading pleasure shortly. John B. > On Jan 20, 2016, at 10:26 PM, Phil Hunt (IDM) = wrote: >=20 > +1 for adoption >=20 > +1 for Brian's comments >=20 > Phil >=20 > On Jan 20, 2016, at 14:42, Brian Campbell > wrote: >=20 >> I conditionally accept this document as a starting point for work in = the OAuth working group on the assumption that the considerable = simplifications discussed and accepted at = http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html = will = be incorporated. >>=20 >> This document is (should be) intended to provide a mitigation to a = security problem. As such, it would be nice to see it progress a little = faster than the typical WG document. The more quickly the document can = progress and/or be perceived as stable, the better. >>=20 >> On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig = > wrote: >> Hi all, >>=20 >> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 = >>=20 >> Please let us know by Feb 9th whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >>=20 >> Note: This call is related to the announcement made on the list = earlier >> this month, see >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html = . More >> time for analysis is provided due to the complexity of the topic. >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_761C1590-49AE-4672-BC5D-D56DB6A4D667 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1 for adoption

Mike and I are working on addressing the comments in a new = draft for your reading pleasure shortly.

John B.

On = Jan 20, 2016, at 10:26 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

+1 for = adoption

+1 = for Brian's comments

Phil

On Jan 20, 2016, at 14:42, Brian Campbell = <bcampbell@pingidentity.com> wrote:

I conditionally accept this = document as a starting point for work in the OAuth working group on the = assumption that the considerable simplifications discussed and accepted = at http://www.ietf.org/mail-archive/web/oauth/current/msg15351.htm= l will be incorporated.

This document is (should be) intended to provide a mitigation = to a security problem. As such, it would be nice to see it progress a = little faster than the typical WG document. The more quickly the = document can progress and/or be perceived as stable, the better.

On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig = <hannes.tschofenig@gmx.net> wrote:
Hi all,

this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation= -00

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

Note: This call is related to the announcement made on the list = earlier
this month, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.htm= l. More
time for analysis is provided due to the complexity of the topic.

Ciao
Hannes & Derek


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


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

= --Apple-Mail=_761C1590-49AE-4672-BC5D-D56DB6A4D667-- --Apple-Mail=_E6BCC62D-EFFD-4680-9CF8-D7CFDEAF766D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMjEwMTQ4MTBaMCMGCSqGSIb3DQEJBDEWBBSuiHDkCPZ54f/5tgWwoP1Z 4AxkxDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCW8SoDIZRkYfw3U7/EykEwJWsa3DRMOLY8bU1BT8pcAy7u8TnONHk9 OsOaARsadjgSSLJcHlnPzBL4uCIKccmDDNJ1ap0DNZaIGxhGbI5TpEGLAo0YSSFl6mjTf9yoYV37 e5Wd3/YG4RNWackhopUNldY81hvAmoQSZaO8Z3GQZR/6es8m2/qPLQBt29jO+5ABXF6FMHDTc4SU dfd3PamGg+ocwJZZd0SL80XvZZu2oKdCdkWz9Ajq8Q9Aoz7dCNZTQJskEDC4NpR9EOfsOQA8pOov VrYmdYqk+KmzfKsEzjy0FlJLA6Mp/O8hwDvBOEv9jI3zNLFBetWaCu1pOiEwAAAAAAAA --Apple-Mail=_E6BCC62D-EFFD-4680-9CF8-D7CFDEAF766D-- From nobody Wed Jan 20 18:30:06 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3551B2D44 for ; Wed, 20 Jan 2016 18:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOOB6l7-45fD for ; Wed, 20 Jan 2016 18:30:02 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 A13031B2D43 for ; Wed, 20 Jan 2016 18:30:02 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id o124so18035509oia.3 for ; Wed, 20 Jan 2016 18:30:02 -0800 (PST) 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:content-type; bh=uDlyQEzvqQqX1c828NvVddnVOh3bOVPLHRng2xLSvkc=; b=gcEQgbCcS57UgBwoJIJ1Nl9WEJrB00t14qwmKhPRgU5azP4JwnDblMZ6qiAK++YGAn 7VrFZVbVUBjsYEx/19c6UZCsKYc5fjhYhuhwdnqNc1tKCwD74c56wuf9fDRBM+El7Fxq kh1zmW0ku/Uk/WKarD4IZe8IWXm+wK3toyNt3iQnHseNgUA8N2y0QzTZSMuN+RoZ6RkF ZUPMVkykvW46SMbZvfmc5sZ+XHKleibCgQPeZotrW1n6O7D+p4qsB+cJDh+Za2vwAjCY avkmaL3HssVzbkzQByt6pkGRONyQULR5PVqSxaxswdTiJ6UTH+5Lu8w4dlMwwBnxvELM mZ8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=uDlyQEzvqQqX1c828NvVddnVOh3bOVPLHRng2xLSvkc=; b=M/KsGuIfMNn1aJEz5IYFK/UCW3sGoyscniC/o9gdb9d4NSYPbQl3ta3eOq3cwCQxyo /Rq2aTbS8OBPEhW9BnaBC1SEoTKpL3IzM9Fmjccpanfu7vYtV87U1BR011yTs4cUjHaP edGfTfVd183jkuBO5Dz1SDKAK+yPhIMMoqhGhNp/xPSNwcd7VKkj8LD0OIIRvw0xxINy kPIyW334Yv+wjZWY3/bHQ+0ACdb1GtAjfsWBeoo+B/hsh4asdXIrIq2P0LExA7lGe7WW mnIJmclxY5/Kjvmd181GzreN5y9HypPqwuNBPhAU4wndWhdhdhL2VePJf2q54mIXyElB ZS0w== X-Gm-Message-State: AG10YORSnijXoGsFPs2oKCZSv9/QOFOjahul41Y2P4J2OkdE5TOCJrcjDu6cfQ2vIAAfe86RIIsJkN+PCrxCLiJi X-Received: by 10.202.53.86 with SMTP id c83mr5977678oia.13.1453343401915; Wed, 20 Jan 2016 18:30:01 -0800 (PST) MIME-Version: 1.0 References: <569E22E1.5010402@gmx.net> <24B75197-1E94-4EE2-B51A-E5928D62BF3A@ve7jtb.com> In-Reply-To: <24B75197-1E94-4EE2-B51A-E5928D62BF3A@ve7jtb.com> From: William Denniss Date: Thu, 21 Jan 2016 02:29:51 +0000 Message-ID: To: John Bradley , "Phil Hunt (IDM)" Content-Type: multipart/alternative; boundary=001a113d45d8357b940529cee1da Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 02:30:04 -0000 --001a113d45d8357b940529cee1da Content-Type: text/plain; charset=UTF-8 +1 for adoption, this is important work. On Thu, Jan 21, 2016, 9:48 AM John Bradley wrote: > +1 for adoption > > Mike and I are working on addressing the comments in a new draft for your > reading pleasure shortly. > > John B. > > On Jan 20, 2016, at 10:26 PM, Phil Hunt (IDM) > wrote: > > +1 for adoption > > +1 for Brian's comments > > Phil > > On Jan 20, 2016, at 14:42, Brian Campbell > wrote: > > I conditionally accept this document as a starting point for work in the > OAuth working group on the assumption that the considerable simplifications > discussed and accepted at > http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html will be > incorporated. > > This document is (should be) intended to provide a mitigation to a > security problem. As such, it would be nice to see it progress a little > faster than the typical WG document. The more quickly the document can > progress and/or be perceived as stable, the better. > > On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> Hi all, >> >> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 >> >> Please let us know by Feb 9th whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >> >> Note: This call is related to the announcement made on the list earlier >> this month, see >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More >> time for analysis is provided due to the complexity of the topic. >> >> Ciao >> Hannes & Derek >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113d45d8357b940529cee1da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for adoption, this is important work.

On Thu, Jan 21, 2016= , 9:48 AM=C2=A0John Bradley <ve7jtb@ve7jtb.com> wrote:
+1 for adoption

Mike and I are working on addressing the comments in a new draft for = your reading pleasure shortly.

John B.
=

On Jan 20, 2016, at 10:26 PM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:<= /div>
+1 for adoption

+1 for Brian's comments

Phil

On Jan 20, 2016, a= t 14:42, Brian Campbell <bcampbell@pingidentity.com> wrote:

I conditionally accept th= is document as a starting point for work in the OAuth working group on the = assumption that the considerable simplifications discussed and accepted at = http://www.ietf.org/mail-archive/web/oauth/current/msg1= 5351.html will be incorporated.

This document is (sho= uld be) intended to provide a mitigation to a security problem. As such, it= would be nice to see it progress a little faster than the typical WG docum= ent. The more quickly the document can progress and/or be perceived as stab= le, the better.

On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
https://tools.ietf.org/html/draft-= jones-oauth-mix-up-mitigation-00

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

Note: This call is related to the announcement made on the list earlier
this month, see
http://www.ietf.org/mail-archive/web= /oauth/current/msg15336.html. More
time for analysis is provided due to the complexity of the topic.

Ciao
Hannes & Derek


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


___________________= ____________________________
OAuth mailing list
<= span>OAuth@ietf.org=
https://www.ietf.org/mailman/listinfo/oauth
<= /div>
_______________________________________________
= OAuth mailing list
O= Auth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

______________________________________= _________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a113d45d8357b940529cee1da-- From nobody Wed Jan 20 19:43:27 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BEC1B2E0B for ; Wed, 20 Jan 2016 19:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvanNqYmvn-I for ; Wed, 20 Jan 2016 19:43:23 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0112.outbound.protection.outlook.com [65.55.169.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99A51B2E0F for ; Wed, 20 Jan 2016 19:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TutfgZfmoqSfGMB8lewly0AMp4c/tkICUNRPIslZv0k=; b=fKGDpz1kotSRJ/ZrmWO2YgaMEkHlFJyfXc9XvoFvoVbNP3eDDbYDzhgBsK+iyDgs+EDO+puIb6OSELM4Lm5Vn5T/2AfAVuzXzT3vZLNB1VrV0dl11YF5G8Mi44A1sykCcb82a+2pikw09TN0F4xP6HbTJavXyGhfSiamW5xvoDs= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 21 Jan 2016 03:43:19 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0365.024; Thu, 21 Jan 2016 03:43:19 +0000 From: Anthony Nadalin To: William Denniss , John Bradley , "Phil Hunt (IDM)" Thread-Topic: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation Thread-Index: AQHRUq+JB8nZ+FFX60KhN+fitr/iZZ8FAlEAgAAtrgCAAAYyAIAAC6WAgAAUeHA= Date: Thu, 21 Jan 2016 03:43:19 +0000 Message-ID: References: <569E22E1.5010402@gmx.net> <24B75197-1E94-4EE2-B51A-E5928D62BF3A@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [118.163.65.13] x-ms-office365-filtering-correlation-id: 01655081-697a-48e0-e860-08d32215011f x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1234; 5:lQNOgWsbmLXQZQ0/AYtBDro3knmX/LOZ2nGXyB2yfppY8K9tgMpo4lHIXBsRmm//N2TseMPn4cOQ4ctMmZZMTI86qryQC13l27LtwokULBMoPNoCTJqM2SjFTf/jdZiAZ14LIWuhKWTu8WQ66xsFrA==; 24:WpNLW/STIpEHcpkXZkaqpAyXzLWE2+otTP9TpTEOdc/wCV/3FOAGLjZ+uueCZau+Xq3lRrg+hraMU41mwzBmtkTEmOMefZ+H/WAQuUdTT/U= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; UriScan:(189930954265078)(146099531331640); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001)(61426038)(61427038); SRVR:BN3PR0301MB1234; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(53754006)(199003)(24454002)(36944003)(189002)(86612001)(76176999)(5005710100001)(1096002)(6116002)(40100003)(1220700001)(3846002)(5002640100001)(81156007)(19580395003)(93886004)(97736004)(10400500002)(54356999)(87936001)(86362001)(5003600100002)(189998001)(586003)(101416001)(102836003)(16236675004)(33656002)(5001770100001)(122556002)(105586002)(92566002)(15975445007)(19617315012)(19625215002)(790700001)(106116001)(5004730100002)(2900100001)(19580405001)(11100500001)(5001960100002)(50986999)(106356001)(77096005)(10090500001)(2950100001)(19609705001)(74316001)(76576001)(5008740100001)(4326007)(2906002)(99286002)(66066001)(10290500002)(19300405004)(8990500004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234F6D1E61154DBD11C4A3EA6C30BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2016 03:43:19.3210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 03:43:26 -0000 --_000_BN3PR0301MB1234F6D1E61154DBD11C4A3EA6C30BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgV2lsbGlhbSBEZW5uaXNzDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjAsIDIwMTYg NjozMCBQTQ0KVG86IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+OyBQaGlsIEh1bnQg KElETSkgPHBoaWwuaHVudEBvcmFjbGUuY29tPg0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBBZG9wdGlvbjogT0F1dGggMi4wIE1peC1VcCBNaXRp Z2F0aW9uDQoNCisxIGZvciBhZG9wdGlvbiwgdGhpcyBpcyBpbXBvcnRhbnQgd29yay4NCg0KT24g VGh1LCBKYW4gMjEsIDIwMTYsIDk6NDggQU0gSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNv bTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCisxIGZvciBhZG9wdGlvbg0KDQpN aWtlIGFuZCBJIGFyZSB3b3JraW5nIG9uIGFkZHJlc3NpbmcgdGhlIGNvbW1lbnRzIGluIGEgbmV3 IGRyYWZ0IGZvciB5b3VyIHJlYWRpbmcgcGxlYXN1cmUgc2hvcnRseS4NCg0KSm9obiBCLg0KDQpP biBKYW4gMjAsIDIwMTYsIGF0IDEwOjI2IFBNLCBQaGlsIEh1bnQgKElETSkgPHBoaWwuaHVudEBv cmFjbGUuY29tPG1haWx0bzpwaGlsLmh1bnRAb3JhY2xlLmNvbT4+IHdyb3RlOg0KDQorMSBmb3Ig YWRvcHRpb24NCg0KKzEgZm9yIEJyaWFuJ3MgY29tbWVudHMNCg0KUGhpbA0KDQpPbiBKYW4gMjAs IDIwMTYsIGF0IDE0OjQyLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpJIGNvbmRpdGlv bmFsbHkgYWNjZXB0IHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3Igd29yayBp biB0aGUgT0F1dGggd29ya2luZyBncm91cCBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBjb25z aWRlcmFibGUgc2ltcGxpZmljYXRpb25zIGRpc2N1c3NlZCBhbmQgYWNjZXB0ZWQgYXQgaHR0cDov L3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTUzNTEuaHRt bDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw JTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbC1hcmNoaXZlJTJmd2ViJTJmb2F1dGglMmZjdXJy ZW50JTJmbXNnMTUzNTEuaHRtbCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNv bSU3YzU3YjUxMTFhMzVmYzQzZTMyNzYyMDhkMzIyMGFjOGI2JTdjNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPXNYNTYzb2UlMmJnaElWOU9BNmVaUjJjWVVNa1pZekNJ M2FzakV4a05YNlhwMCUzZD4gd2lsbCBiZSBpbmNvcnBvcmF0ZWQuDQpUaGlzIGRvY3VtZW50IGlz IChzaG91bGQgYmUpIGludGVuZGVkIHRvIHByb3ZpZGUgYSBtaXRpZ2F0aW9uIHRvIGEgc2VjdXJp dHkgcHJvYmxlbS4gQXMgc3VjaCwgaXQgd291bGQgYmUgbmljZSB0byBzZWUgaXQgcHJvZ3Jlc3Mg YSBsaXR0bGUgZmFzdGVyIHRoYW4gdGhlIHR5cGljYWwgV0cgZG9jdW1lbnQuIFRoZSBtb3JlIHF1 aWNrbHkgdGhlIGRvY3VtZW50IGNhbiBwcm9ncmVzcyBhbmQvb3IgYmUgcGVyY2VpdmVkIGFzIHN0 YWJsZSwgdGhlIGJldHRlci4NCg0KT24gVHVlLCBKYW4gMTksIDIwMTYgYXQgNDo0OSBBTSwgSGFu bmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOmhhbm5lcy50 c2Nob2ZlbmlnQGdteC5uZXQ+PiB3cm90ZToNCkhpIGFsbCwNCg0KdGhpcyBpcyB0aGUgY2FsbCBm b3IgYWRvcHRpb24gb2YgT0F1dGggMi4wIE1peC1VcCBNaXRpZ2F0aW9uLCBzZWUNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1taXgtdXAtbWl0aWdhdGlvbi0w MDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWpvbmVzLW9hdXRoLW1peC11 cC1taXRpZ2F0aW9uLTAwJmRhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdj NTdiNTExMWEzNWZjNDNlMzI3NjIwOGQzMjIwYWM4YjYlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3YzEmc2RhdGE9OVhyZjN3TCUyZjdVZkolMmZkcFdSVCUyZkNXU2FzZ0tUUmNx c3JTU01LTEd3VXRKMCUzZD4NCg0KUGxlYXNlIGxldCB1cyBrbm93IGJ5IEZlYiA5dGggd2hldGhl ciB5b3UgYWNjZXB0IC8gb2JqZWN0IHRvIHRoZQ0KYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBh cyBhIHN0YXJ0aW5nIHBvaW50IGZvciB3b3JrIGluIHRoZSBPQXV0aA0Kd29ya2luZyBncm91cC4N Cg0KTm90ZTogVGhpcyBjYWxsIGlzIHJlbGF0ZWQgdG8gdGhlIGFubm91bmNlbWVudCBtYWRlIG9u IHRoZSBsaXN0IGVhcmxpZXINCnRoaXMgbW9udGgsIHNlZQ0KaHR0cDovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTUzMzYuaHRtbDxodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmd3d3Lmll dGYub3JnJTJmbWFpbC1hcmNoaXZlJTJmd2ViJTJmb2F1dGglMmZjdXJyZW50JTJmbXNnMTUzMzYu aHRtbCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzU3YjUxMTFhMzVm YzQzZTMyNzYyMDhkMzIyMGFjOGI2JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N2MxJnNkYXRhPVdQUVFjRDlHODIzQWI0b3Nyakt3ZnFGbHU1V3haR1d6RnZqUWMzZTRzRjglM2Q+ LiBNb3JlDQp0aW1lIGZvciBhbmFseXNpcyBpcyBwcm92aWRlZCBkdWUgdG8gdGhlIGNvbXBsZXhp dHkgb2YgdGhlIHRvcGljLg0KDQpDaWFvDQpIYW5uZXMgJiBEZXJlaw0KDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QN Ck9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFu JTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNv bSU3YzU3YjUxMTFhMzVmYzQzZTMyNzYyMDhkMzIyMGFjOGI2JTdjNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPTAwaG9YaDJEbE85UXlKclhNZGFyeFFOaXVTUUlLYWVM NDkwcUJyeENZRmMlM2Q+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8 aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZkYXRhPTAx JTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3YzU3YjUxMTFhMzVmYzQzZTMyNzYyMDhk MzIyMGFjOGI2JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPTAw aG9YaDJEbE85UXlKclhNZGFyeFFOaXVTUUlLYWVMNDkwcUJyeENZRmMlM2Q+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0 DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1h biUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5j b20lN2M1N2I1MTExYTM1ZmM0M2UzMjc2MjA4ZDMyMjBhYzhiNiU3YzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT0wMGhvWGgyRGxPOVF5SnJYTWRhcnhRTml1U1FJS2Fl TDQ5MHFCcnhDWUZjJTNkPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1 dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0w MSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M1N2I1MTExYTM1ZmM0M2UzMjc2MjA4 ZDMyMjBhYzhiNiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT0w MGhvWGgyRGxPOVF5SnJYTWRhcnhRTml1U1FJS2FlTDQ5MHFCcnhDWUZjJTNkPg0K --_000_BN3PR0301MB1234F6D1E61154DBD11C4A3EA6C30BN3PR0301MB1234_ 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 YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1 dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5X aWxsaWFtIERlbm5pc3M8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDIwLCAy MDE2IDY6MzAgUE08YnI+DQo8Yj5Ubzo8L2I+IEpvaG4gQnJhZGxleSAmbHQ7dmU3anRiQHZlN2p0 Yi5jb20mZ3Q7OyBQaGlsIEh1bnQgKElETSkgJmx0O3BoaWwuaHVudEBvcmFjbGUuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtP QVVUSC1XR10gQ2FsbCBmb3IgQWRvcHRpb246IE9BdXRoIDIuMCBNaXgtVXAgTWl0aWdhdGlvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSBmb3IgYWRvcHRpb24s IHRoaXMgaXMgaW1wb3J0YW50IHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUaHUsIEphbiAyMSwgMjAxNiwgOTo0OCBBTSZuYnNwO0pvaG4gQnJh ZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgZm9yIGFk b3B0aW9uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWtl IGFuZCBJIGFyZSB3b3JraW5nIG9uIGFkZHJlc3NpbmcgdGhlIGNvbW1lbnRzIGluIGEgbmV3IGRy YWZ0IGZvciB5b3VyIHJlYWRpbmcgcGxlYXN1cmUgc2hvcnRseS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gSmFuIDIwLCAyMDE2LCBhdCAxMDoyNiBQTSwgUGhpbCBIdW50IChJRE0pICZsdDs8YSBocmVm PSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRA b3JhY2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSBmb3IgYWRvcHRpb248bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxIGZvciBCcmlhbidz IGNvbW1lbnRzPGJyPg0KPGJyPg0KUGhpbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpP biBKYW4gMjAsIDIwMTYsIGF0IDE0OjQyLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPkkgY29uZGl0aW9uYWxseSBhY2NlcHQgdGhpcyBkb2N1bWVudCBhcyBh IHN0YXJ0aW5nIHBvaW50IGZvciB3b3JrIGluIHRoZSBPQXV0aCB3b3JraW5nIGdyb3VwIG9uIHRo ZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGNvbnNpZGVyYWJsZSBzaW1wbGlmaWNhdGlvbnMgZGlzY3Vz c2VkIGFuZCBhY2NlcHRlZCBhdA0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWwt YXJjaGl2ZSUyZndlYiUyZm9hdXRoJTJmY3VycmVudCUyZm1zZzE1MzUxLmh0bWwmYW1wO2RhdGE9 MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjNTdiNTExMWEzNWZjNDNlMzI3NjIw OGQzMjIwYWM4YjYlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3Nk YXRhPXNYNTYzb2UlMmJnaElWOU9BNmVaUjJjWVVNa1pZekNJM2FzakV4a05YNlhwMCUzZCIgdGFy Z2V0PSJfYmxhbmsiPg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRo L2N1cnJlbnQvbXNnMTUzNTEuaHRtbDwvYT4gd2lsbCBiZSBpbmNvcnBvcmF0ZWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGRvY3VtZW50 IGlzIChzaG91bGQgYmUpIGludGVuZGVkIHRvIHByb3ZpZGUgYSBtaXRpZ2F0aW9uIHRvIGEgc2Vj dXJpdHkgcHJvYmxlbS4gQXMgc3VjaCwgaXQgd291bGQgYmUgbmljZSB0byBzZWUgaXQgcHJvZ3Jl c3MgYSBsaXR0bGUgZmFzdGVyIHRoYW4gdGhlIHR5cGljYWwgV0cgZG9jdW1lbnQuIFRoZSBtb3Jl IHF1aWNrbHkgdGhlIGRvY3VtZW50IGNhbiBwcm9ncmVzcyBhbmQvb3IgYmUgcGVyY2VpdmVkDQog YXMgc3RhYmxlLCB0aGUgYmV0dGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEphbiAxOSwgMjAxNiBhdCA0OjQ5IEFNLCBIYW5u ZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQGdteC5u ZXQiIHRhcmdldD0iX2JsYW5rIj5oYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBhbGwsPGJyPg0KPGJyPg0KdGhpcyBpcyB0aGUg Y2FsbCBmb3IgYWRvcHRpb24gb2YgT0F1dGggMi4wIE1peC1VcCBNaXRpZ2F0aW9uLCBzZWU8YnI+ DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LWpvbmVzLW9h dXRoLW1peC11cC1taXRpZ2F0aW9uLTAwJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWlj cm9zb2Z0LmNvbSU3YzU3YjUxMTFhMzVmYzQzZTMyNzYyMDhkMzIyMGFjOGI2JTdjNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT05WHJmM3dMJTJmN1VmSiUyZmRw V1JUJTJmQ1dTYXNnS1RSY3FzclNTTUtMR3dVdEowJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLW1peC11cC1taXRpZ2F0aW9u LTAwPC9hPjxicj4NCjxicj4NClBsZWFzZSBsZXQgdXMga25vdyBieSBGZWIgOXRoIHdoZXRoZXIg eW91IGFjY2VwdCAvIG9iamVjdCB0byB0aGU8YnI+DQphZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50 IGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHdvcmsgaW4gdGhlIE9BdXRoPGJyPg0Kd29ya2luZyBn cm91cC48YnI+DQo8YnI+DQpOb3RlOiBUaGlzIGNhbGwgaXMgcmVsYXRlZCB0byB0aGUgYW5ub3Vu Y2VtZW50IG1hZGUgb24gdGhlIGxpc3QgZWFybGllcjxicj4NCnRoaXMgbW9udGgsIHNlZTxicj4N CjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHAlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsLWFyY2hpdmUlMmZ3ZWIlMmZvYXV0 aCUyZmN1cnJlbnQlMmZtc2cxNTMzNi5odG1sJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQw bWljcm9zb2Z0LmNvbSU3YzU3YjUxMTFhMzVmYzQzZTMyNzYyMDhkMzIyMGFjOGI2JTdjNzJmOTg4 YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1XUFFRY0Q5RzgyM0FiNG9z cmpLd2ZxRmx1NVd4WkdXekZ2alFjM2U0c0Y4JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTUzMzYuaHRtbDwv YT4uDQogTW9yZTxicj4NCnRpbWUgZm9yIGFuYWx5c2lzIGlzIHByb3ZpZGVkIGR1ZSB0byB0aGUg Y29tcGxleGl0eSBvZiB0aGUgdG9waWMuPGJyPg0KPGJyPg0KQ2lhbzxicj4NCkhhbm5lcyAmYW1w OyBEZXJlazxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Lz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZv YXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2M1N2I1MTEx YTM1ZmM0M2UzMjc2MjA4ZDMyMjBhYzhiNiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdjMSZhbXA7c2RhdGE9MDBob1hoMkRsTzlReUpyWE1kYXJ4UU5pdVNRSUthZUw0OTBxQnJ4 Q1lGYyUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZt YWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1p Y3Jvc29mdC5jb20lN2M1N2I1MTExYTM1ZmM0M2UzMjc2MjA4ZDMyMjBhYzhiNiU3YzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9MDBob1hoMkRsTzlReUpyWE1k YXJ4UU5pdVNRSUthZUw0OTBxQnJ4Q1lGYyUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUy Zm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQw bWljcm9zb2Z0LmNvbSU3YzU3YjUxMTFhMzVmYzQzZTMyNzYyMDhkMzIyMGFjOGI2JTdjNzJmOTg4 YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT0wMGhvWGgyRGxPOVF5SnJY TWRhcnhRTml1U1FJS2FlTDQ5MHFCcnhDWUZjJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYu b3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmYW1wO2RhdGE9MDElN2MwMSU3Y3Rvbnlu YWQlNDBtaWNyb3NvZnQuY29tJTdjNTdiNTExMWEzNWZjNDNlMzI3NjIwOGQzMjIwYWM4YjYlN2M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPTAwaG9YaDJEbE85 UXlKclhNZGFyeFFOaXVTUUlLYWVMNDkwcUJyeENZRmMlM2QiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN3PR0301MB1234F6D1E61154DBD11C4A3EA6C30BN3PR0301MB1234_-- From nobody Wed Jan 20 20:12:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21E21B2E71 for ; Wed, 20 Jan 2016 20:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9d_8tLoUmpA for ; Wed, 20 Jan 2016 20:12:47 -0800 (PST) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 3956D1B2E43 for ; Wed, 20 Jan 2016 20:12:47 -0800 (PST) Received: by mail-qg0-x234.google.com with SMTP id 6so23307870qgy.1 for ; Wed, 20 Jan 2016 20:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=PPFTUFimfZ6c0ZciKTGaSVTsmno53UfAdiKQxSUtwB0=; b=abWx6xTNJ4j6v2DY0JcQ/F6tFCWOsES4yi6l0ll2ltrmDmt+Sq9x/fdPWG4cdrmdVX s5g/IIYfMe5VrUnYPu7vikHYaFI0SkLxvOF9/bOOpNtPufj7DPGW+41AXTKOKOQxyliH 7ZjIxnwD3pKXqisYc9btK4PV6zu4IJhqVB+AaOXIMnWMs7fYRGrvifp32jAegrfk/BKE cajioRLsptsrdk9f2KLtMO/ZW8dWVIXQbxXIypYprqEObVS0XkwuBpdgbLxSN17p9qx0 ENMXxylE+W/JGM3Iw36/qpsKpzQSny7P9PSZD06mn0b8KI1XW+6u42Sl1nzFCBbBfW20 lLiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=PPFTUFimfZ6c0ZciKTGaSVTsmno53UfAdiKQxSUtwB0=; b=XDJ54hI8itKi0K/Bm8tLIuL5xPOszBD0bBAjQ5TPA94ccykA7MVsiDjtqTqTu9BjtN AJhKZWAUoXYhL/WUJ58SWMgNKFVCKLcOoXPu4Fg4cJbeQEomynJPtSvuoWyv4rLk2vRq VD8VMlpPgk6dt3NnfWWYZIIFAFAjsGMWDBlPqIwNkTTa4YDVBKJZrb+jyTRMJuDtr59x ebDf6uFWriGpIkqSoVIhgvbCXNIxI+WuLKZN3zXZPYJgK+ZaZzTNzftN7pZa8mV/e7Dy zemN035HHX+6DvJXuylYsl+VR3Wm+t4osIuu1Uw4Fh02V4Zb01GnGnXtDIQEfN2AVwrB wgjQ== X-Gm-Message-State: AG10YORDKQKeT/C/Z/wk3gKRJLEckbrV3Os4WcMPH4CCAsOphZfyiy/Ev3utCOH+S/lj55iu4ynojdt0ZAzTRg== X-Received: by 10.140.144.16 with SMTP id 16mr7160052qhq.81.1453349566335; Wed, 20 Jan 2016 20:12:46 -0800 (PST) MIME-Version: 1.0 References: <569E22E1.5010402@gmx.net> <24B75197-1E94-4EE2-B51A-E5928D62BF3A@ve7jtb.com> In-Reply-To: From: Nat Sakimura Date: Thu, 21 Jan 2016 04:12:37 +0000 Message-ID: To: Anthony Nadalin , William Denniss , John Bradley , "Phil Hunt (IDM)" Content-Type: multipart/alternative; boundary=001a11355ee2a2d18a0529d050e6 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 04:12:50 -0000 --001a11355ee2a2d18a0529d050e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thought I did, but apparently not. A belated +1. 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 12:43 Anthony Nadalin : > +1 > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William > Denniss > *Sent:* Wednesday, January 20, 2016 6:30 PM > *To:* John Bradley ; Phil Hunt (IDM) < > phil.hunt@oracle.com> > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation > > > > +1 for adoption, this is important work. > > > > On Thu, Jan 21, 2016, 9:48 AM John Bradley wrote: > > +1 for adoption > > > > Mike and I are working on addressing the comments in a new draft for your > reading pleasure shortly. > > > > John B. > > > > On Jan 20, 2016, at 10:26 PM, Phil Hunt (IDM) > wrote: > > > > +1 for adoption > > > > +1 for Brian's comments > > Phil > > > On Jan 20, 2016, at 14:42, Brian Campbell > wrote: > > I conditionally accept this document as a starting point for work in the > OAuth working group on the assumption that the considerable simplificatio= ns > discussed and accepted at > http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html > > will be incorporated. > > This document is (should be) intended to provide a mitigation to a > security problem. As such, it would be nice to see it progress a little > faster than the typical WG document. The more quickly the document can > progress and/or be perceived as stable, the better. > > > > On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > > Hi all, > > this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see > https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 > > > Please let us know by Feb 9th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Note: This call is related to the announcement made on the list earlier > this month, see > http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html > . > More > time for analysis is provided due to the complexity of the topic. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11355ee2a2d18a0529d050e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thought I did, but apparently not. A belated=C2=A0+1.=C2= =A0

2016=E5=B9=B41=E6= =9C=8821=E6=97=A5(=E6=9C=A8) 12:43 Anthony Nadalin <tonynad@microsoft.com>:

+1

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of William Denniss
Sent: Wednesday, January 20, 2016 6:30 PM
To: John Bradley <ve7jtb@ve7jtb.com>; Phil Hunt (IDM) <phil.hunt@oracle.com>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigati= on

=C2=A0

+1 for adoption, this is important work.

=C2=A0

On Thu, Jan 21, 2016, 9:48 AM=C2=A0John Bradley <= ve7jtb@ve7jtb.com> wrote:

+1 for adoption

=C2=A0

Mike and I are working on addressing the comments in= a new draft for your reading pleasure shortly.

=C2=A0

John B.

=C2=A0

=C2=A0

+1 for adoption

=C2=A0

+1 for Brian's comments

Phil


On Jan 20, 2016, at 14:42, Brian Campbell <bcampbell@pingidentity.com> wrote= :

I conditionally accep= t this document as a starting point for work in the OAuth working group on = the assumption that the considerable simplifications discussed and accepted= at http://www.ietf.org/mail-archive/web/oauth/current/msg15351.html will b= e incorporated.

This document is (should be) intended to provide a m= itigation to a security problem. As such, it would be nice to see it progre= ss a little faster than the typical WG document. The more quickly the docum= ent can progress and/or be perceived as stable, the better.

=C2=A0

On Tue, Jan 19, 2016 at 4:49 AM, Hannes Tschofenig &= lt;hannes.ts= chofenig@gmx.net> wrote:

Hi all,

this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
https://tools.ietf.org/html/dr= aft-jones-oauth-mix-up-mitigation-00

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

Note: This call is related to the announcement made on the list earlier
this month, see
http://www.ietf.org/mail-archive/= web/oauth/current/msg15336.html. More
time for analysis is provided due to the complexity of the topic.

Ciao
Hannes & Derek


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

=C2=A0

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

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

=C2=A0

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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a11355ee2a2d18a0529d050e6-- From nobody Wed Jan 20 20:33:59 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9991B2EA0 for ; Wed, 20 Jan 2016 20:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHT5X5pw0NME for ; Wed, 20 Jan 2016 20:33:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E78AF1B2E9E for ; Wed, 20 Jan 2016 20:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IwWmzc0tMudPiBc3NU7jki1mDZMWhvQ1fjock7EXsKI=; b=nToN8nBunLt+f1LEdWKTEAxzi3uBD8edLWxLnD3VsTjo63AeKOla16Y4n6X1wYnNZIsL26i8Hxm1ABdZLa/c8b7tZGGBuGZO3nhFLo0g4W7IXxt5rp/6M4cr6uk88Dqj78/5WGrQYJJwQlmX5thRilmk1HStGhENE2yBPVj4H3c= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BN3PR0301MB1233.namprd03.prod.outlook.com (10.161.207.21) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 21 Jan 2016 04:33:32 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0365.024; Thu, 21 Jan 2016 04:33:31 +0000 From: Anthony Nadalin To: John Bradley , Nat Sakimura Thread-Topic: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps Thread-Index: AQHRUq8iYUfUsD4JqEqyJO5z+rZonp8EjGGAgAAi5ICAAA74AIAAEWeAgAAHwwCAAACSAIAAixdA Date: Thu, 21 Jan 2016 04:33:31 +0000 Message-ID: References: <569E2231.1010107@gmx.net> <6ADAA1B5-7EF9-49EA-A3D9-6EFC57275EB9@ve7jtb.com> <9062E913-39FB-4610-80FE-70796CBDEAC1@ve7jtb.com> In-Reply-To: <9062E913-39FB-4610-80FE-70796CBDEAC1@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [118.163.65.13] x-ms-office365-filtering-correlation-id: 9bc000d8-5bdd-40e1-2077-08d3221c047a x-microsoft-exchange-diagnostics: 1; BN3PR0301MB1233; 5:bBSr+OjZew9qEervtgxU3q/l30vKr8/3STq6Rt2vh0d2AaO/UvqATtKhPuGEJ3k+VQ24FysuHtw63v51hezsW6RTO914cRMQUtowAIvEZFXsPrQ6PDGVzRl6My/qiijk1O/c8Gl5hhzMrDV5R52u3Q==; 24:65l7mGwQY8KtmcseJm3g5XBM/fI0+8AYtu6pGtfOyDKU1HRNoHkGAXDFMhMDal17Bw+PpryxSEw8eIFsH69EuReMLphl08yPy6eZ7R6w9uQ= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; UriScan:(189930954265078); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BN3PR0301MB1233; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1233; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(24454002)(377454003)(189002)(11905935001)(53754006)(199003)(77096005)(76576001)(19580395003)(19617315012)(5005710100001)(8990500004)(2900100001)(6116002)(3846002)(16236675004)(93886004)(10290500002)(10400500002)(5008740100001)(1220700001)(122556002)(92566002)(50986999)(790700001)(19300405004)(102836003)(19580405001)(586003)(1096002)(54356999)(5002640100001)(5001960100002)(87936001)(189998001)(2950100001)(33656002)(76176999)(81156007)(5003600100002)(101416001)(105586002)(40100003)(5004730100002)(74316001)(86362001)(5001770100001)(10090500001)(66066001)(99286002)(4326007)(106116001)(5890100001)(106356001)(19625215002)(86612001)(97736004)(15975445007)(2906002)(42262002)(9078065003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1233; H:BN3PR0301MB1234.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1234046860E5CD9E774DB473A6C30BN3PR0301MB1234_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2016 04:33:31.5006 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1233 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 04:33:58 -0000 --_000_BN3PR0301MB1234046860E5CD9E774DB473A6C30BN3PR0301MB1234_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyB3b3JrIGhhZCBtYW55IGlzc3VlcyBpbiB0aGUgT3BlbklEIFdHIHdoZXJlIGl0IGZhaWxl ZCB3aHkgc2hvdWxkIHRoaXMgYmUgYSBXRyBpdGVtIGhlcmUgPyBUaGUgZG9lcyBtZWV0IHRoZSBy ZXF1aXJlbWVudHMgZm9yIGV4cGVyaW1lbnRhbCwgdGhlcmUgaXMgYSBmaW5lIGxpbmUgYmV0d2Vl biBpbmZvcm1hdGlvbmFsIGFuZCBleHBlcmltZW50YWwsIEkgd291bGQgYmUgT0sgd2l0aCBlaXRo ZXIgYnV0IHByZWZlciBleHBlcmltZW50YWwsIEkgZG9u4oCZdCB0aGluayB0aGF0IHRoaXMgc2hv dWxkIGJlY29tZSBhIHN0YW5kYXJkLg0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNClNlbnQ6IFdlZG5lc2RheSwg SmFudWFyeSAyMCwgMjAxNiAxMjoxMSBQTQ0KVG86IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21h aWwuY29tPg0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBDYWxs IGZvciBhZG9wdGlvbjogT0F1dGggMi4wIGZvciBOYXRpdmUgQXBwcw0KDQpQUyBhcyB5b3UgcHJv YmFibHkgc3VzcGVjdGVkIEkgYW0gaW4gZmF2b3VyIG9mIG1vdmluZyB0aGlzIGZvcndhcmQuDQoN Cg0KT24gSmFuIDIwLCAyMDE2LCBhdCA1OjA4IFBNLCBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdt YWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4gd3JvdGU6DQoNCisxIGZvciBtb3Zp bmcgdGhpcyBmb3J3YXJkLg0KDQoyMDE25bm0MeaciDIx5pel5pyo5puc5pel44CBSm9obiBCcmFk bGV5PHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+44GV44KT44Gv 5pu444GN44G+44GX44GfOg0KWWVzIG1vcmUgaXMgbmVlZGVkLiAgIEl0IHdhcyB0aGVvcmV0aWNh bCBhdCB0aGF0IHBvaW50LiAgTm93IHdlIGhhdmUgaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZS4N Cg0KT24gSmFuIDIwLCAyMDE2LCBhdCAzOjM4IFBNLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb208amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdiY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbScpOz4+IHdyb3RlOg0KDQpUaGVyZSBpcyBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtd2Rlbm5pc3Mtb2F1dGgtbmF0aXZlLWFwcHMtMDAjYXBwZW5kaXgt QTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzYSUyZiUyZnRvb2xzLmlldGYub3JnJTJmaHRtbCUyZmRyYWZ0LXdkZW5uaXNzLW9hdXRoLW5h dGl2ZS1hcHBzLTAwJTIzYXBwZW5kaXgtQSZkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWljcm9z b2Z0LmNvbSU3Y2ZkOTNhM2Q0NDE1MjQ3NmIxODZlMDhkMzIxZDVkNTc5JTdjNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPUpXSm1nTE5QWWU5NkdIVXU2N0paMXhkVU4z VDNjN2tETkxRYzh3bmlhRFElM2Q+IHdoaWNoIGhhcyBzb21lIG1lbnRpb24gb2YgU0ZTYWZhcmlW aWV3Q29udHJvbGxlciBhbmQgQ2hyb21lIEN1c3RvbSBUYWJzLg0KTWF5YmUgbW9yZSBpcyBuZWVk ZWQ/DQoNCk9uIFdlZCwgSmFuIDIwLCAyMDE2IGF0IDEwOjQ1IEFNLCBKb2huIEJyYWRsZXkgPHZl N2p0YkB2ZTdqdGIuY29tPGphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywndmU3anRiQHZlN2p0 Yi5jb20nKTs+PiB3cm90ZToNClllcywgaW4gSnVseSB3ZSByZWNvbW1lbmRlZCB1c2luZyB0aGUg c3lzdGVtIGJyb3dzZXIgcmF0aGVyIHRoYW4gV2ViVmlld3MuDQoNCkFib3V0IHRoYXQgdGltZSBB cHBsZSBhbm5vdW5jZWQgU2FmYXJpIHZpZXcgY29udHJvbGxlciBhbmQgR29vZ2xlIENocm9tZSBj dXN0b20gdGFicy4gICBUaGUgY29kZSBpbiB0aGUgT1MgaXMgbm93IHN0YWJsZSBhbmQgd2UgaGF2 ZSBkb25lIGEgZmFpciBhbW91bnQgb2YgdGVzdGluZy4NCg0KVGhlIE9JREYgd2lsbCBzaG9ydGx5 IGJlIHB1Ymxpc2hpbmcgcmVmZXJlbmNlIGxpYnJhcmllcyBmb3IgaU9TIGFuZCBBbmRyb2lkIHRv IGhvdyBob3cgdG8gYmVzdCB1c2UgVmlldyBDb250cm9sbGVycywgYW5kIFBLQ0UgaW4gbmF0aXZl IGFwcHMgb24gdGhvc2UgcGxhdGZvcm1zLg0KDQpXZSBkbyBuZWVkIHRvIHVwZGF0ZSB0aGlzIGRv YyB0byByZWZsZWN0IHdoYXQgd2UgaGF2ZSBsZWFybmVkIGluIHRoZSBsYXN0IDYgbW9udGhzLg0K DQpPbmUgcHJvYmxlbSB3ZSBkbyBzdGlsbCBoYXZlIGlzIG5vdCBoYXZpbmcgc29tZW9uZSB3aXRo IFdpbiAxMCBtb2JpbGUgZXhwZXJpZW5jZSB0byBoZWxwIGRvY3VtZW50IHRoZSBiZXN0IHByYWN0 aWNlcyBmb3IgdGhhdCBwbGF0Zm9ybS4NCkkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoYXQgcGxhdGZv cm0gd2VsbCBlbm91Z2ggeWV0IHRvIGluY2x1ZGUgYW55dGhpbmcuDQoNCkpvaG4gQi4NCg0KT24g SmFuIDIwLCAyMDE2LCBhdCAxMjo0MCBQTSwgQWFyb24gUGFyZWNraSA8YWFyb25AcGFyZWNraS5j b208amF2YXNjcmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdhYXJvbkBwYXJlY2tpLmNvbScpOz4+IHdy b3RlOg0KDQpUaGUgc2VjdGlvbiBvbiBlbWJlZGRlZCB3ZWIgdmlld3MgZG9lc24ndCBtZW50aW9u IHRoZSBuZXcgaU9TIDkgU0ZTYWZhcmlWaWV3Q29udHJvbGxlciB3aGljaCBhbGxvd3MgYXBwcyB0 byBkaXNwbGF5IGEgc3lzdGVtIGJyb3dzZXIgd2l0aGluIHRoZSBhcHBsaWNhdGlvbi4gVGhlIG5l dyBBUEkgZG9lc24ndCBnaXZlIHRoZSBjYWxsaW5nIGFwcGxpY2F0aW9uIGFjY2VzcyB0byBhbnl0 aGluZyBpbnNpZGUgdGhlIGJyb3dzZXIsIHNvIGl0IGlzIGFjY2VwdGFibGUgZm9yIHVzaW5nIHdp dGggT0F1dGggZmxvd3MuIEkgdGhpbmsgaXQncyBpbXBvcnRhbnQgdG8gbWVudGlvbiB0aGlzIG5l dyBjYXBhYmlsaXR5IGZvciBhcHBzIHRvIGxldmVyYWdlIHNpbmNlIGl0IGxlYWRzIHRvIGEgYmV0 dGVyIHVzZXIgZXhwZXJpZW5jZS4NCg0KSSdtIHN1cmUgdGhhdCBjYW4gYmUgYWRkcmVzc2VkIGlu IHRoZSBjb21pbmcgbW9udGhzIGlmIHRoaXMgZG9jdW1lbnQgaXMganVzdCB0aGUgc3RhcnRpbmcg cG9pbnQuDQoNCkkgZGVmaW5pdGVseSBhZ3JlZSB0aGF0IGEgZG9jdW1lbnQgYWJvdXQgbmF0aXZl IGFwcHMgaXMgbmVjZXNzYXJ5IHNpbmNlIHRoZSBjb3JlIGxlYXZlcyBhIGxvdCBvZiBndWVzc2lu ZyByb29tIGZvciBhbiBpbXBsZW1lbnRhdGlvbi4NCg0KRm9yIHJlZmVyZW5jZSwgaHR0cHM6Ly9k ZXZlbG9wZXIuYXBwbGUuY29tL2xpYnJhcnkvcHJlcmVsZWFzZS9pb3MvcmVsZWFzZW5vdGVzL0dl bmVyYWwvV2hhdHNOZXdJbmlPUy9BcnRpY2xlcy9pT1M5Lmh0bWwjLy9hcHBsZV9yZWYvZG9jL3Vp ZC9UUDQwMDE2MTk4LURvbnRMaW5rRWxlbWVudElEXzI2PGh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmZGV2ZWxvcGVyLmFwcGxl LmNvbSUyZmxpYnJhcnklMmZwcmVyZWxlYXNlJTJmaW9zJTJmcmVsZWFzZW5vdGVzJTJmR2VuZXJh bCUyZldoYXRzTmV3SW5pT1MlMmZBcnRpY2xlcyUyZmlPUzkuaHRtbCUyMyUyZiUyZmFwcGxlX3Jl ZiUyZmRvYyUyZnVpZCUyZlRQNDAwMTYxOTgtRG9udExpbmtFbGVtZW50SURfMjYmZGF0YT0wMSU3 YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmZDkzYTNkNDQxNTI0NzZiMTg2ZTA4ZDMy MWQ1ZDU3OSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1oUTZK R0JKalglMmZ3bTM2TjZNcEdlWGJOUXp3SmFmNkc2ZXlHeFJWUUg0WkElM2Q+DQoNCkFuZCBzZWUg dGhlIGF0dGFjaGVkIHNjcmVlbnNob3QgZm9yIGFuIGV4YW1wbGUgb2Ygd2hhdCBpdCBsb29rcyBs aWtlLg0KDQo8ZW1iZWRkZWQtb2F1dGgtdmlldy5wbmc+DQoNCi0tLS0NCkFhcm9uIFBhcmVja2kN CmFhcm9ucGFyZWNraS5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmFhcm9ucGFyZWNraS5jb20lMmYmZGF0YT0wMSU3YzAx JTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmZDkzYTNkNDQxNTI0NzZiMTg2ZTA4ZDMyMWQ1 ZDU3OSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1TNWFvRDJY MXB6QnZ5M3FzRWZQZnlEQ1kwU1FScU43SjZNJTJmRExKeiUyZlVldyUzZD4NCkBhYXJvbnBrPGh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2El MmYlMmZ0d2l0dGVyLmNvbSUyZmFhcm9ucGsmZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jv c29mdC5jb20lN2NmZDkzYTNkNDQxNTI0NzZiMTg2ZTA4ZDMyMWQ1ZDU3OSU3YzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1uRU4yanoyenNJV2xjSiUyYlNXb3RVSDhv TFBGSjhpaTRvNDlHMGNFSFltUW8lM2Q+DQoNCg0KT24gVHVlLCBKYW4gMTksIDIwMTYgYXQgMzo0 NiBBTSwgSGFubmVzIFRzY2hvZmVuaWcgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ8amF2YXNj cmlwdDpfZSglN0IlN0QsJ2N2bWwnLCdoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Jyk7Pj4gd3Jv dGU6DQpIaSBhbGwsDQoNCnRoaXMgaXMgdGhlIGNhbGwgZm9yIGFkb3B0aW9uIG9mIE9BdXRoIDIu MCBmb3IgTmF0aXZlIEFwcHMsIHNlZQ0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC13ZGVubmlzcy1vYXV0aC1uYXRpdmUtYXBwcy88aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmRhdGF0cmFja2VyLmlldGYu b3JnJTJmZG9jJTJmZHJhZnQtd2Rlbm5pc3Mtb2F1dGgtbmF0aXZlLWFwcHMlMmYmZGF0YT0wMSU3 YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmZDkzYTNkNDQxNTI0NzZiMTg2ZTA4ZDMy MWQ1ZDU3OSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT0yY1F3 TFFMa0NpRld4SUlhdjVUTVpGZTVWRkUlMmJYcmMzT1FxNDZxMEQwVTglM2Q+DQoNClBsZWFzZSBs ZXQgdXMga25vdyBieSBGZWIgMm5kIHdoZXRoZXIgeW91IGFjY2VwdCAvIG9iamVjdCB0byB0aGUN CmFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGluZyBwb2ludCBmb3Igd29yayBp biB0aGUgT0F1dGgNCndvcmtpbmcgZ3JvdXAuDQoNCk5vdGU6IElmIHlvdSBhbHJlYWR5IHN0YXRl ZCB5b3VyIG9waW5pb24gYXQgdGhlIElFVEYgbWVldGluZyBpbiBZb2tvaGFtYQ0KdGhlbiB5b3Ug ZG9uJ3QgbmVlZCB0byByZS1zdGF0ZSB5b3VyIG9waW5pb24sIGlmIHlvdSB3YW50Lg0KDQpUaGUg ZmVlZGJhY2sgYXQgdGhlIFlva29oYW1hIElFVEYgbWVldGluZyB3YXMgdGhlIGZvbGxvd2luZzog MTYgcGVyc29ucw0KZm9yIGRvaW5nIHRoZSB3b3JrIC8gMCBwZXJzb25zIGFnYWluc3QgLyAyIHBl cnNvbnMgbmVlZCBtb3JlIGluZm8NCg0KQ2lhbw0KSGFubmVzICYgRGVyZWsNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs aXN0DQpPQXV0aEBpZXRmLm9yZzxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ09BdXRoQGll dGYub3JnJyk7Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxo dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz YSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDEl N2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZmQ5M2EzZDQ0MTUyNDc2YjE4NmUwOGQz MjFkNWQ1NzklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9bTUl MmYzeWQ2SnR3dTBtVk9lamZaaTFCUXNZdEJaMFdqZkhUYUM0ZzlHbUswJTNkPg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs aXN0DQpPQXV0aEBpZXRmLm9yZzxqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ09BdXRoQGll dGYub3JnJyk7Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxo dHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUz YSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmRhdGE9MDEl N2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZmQ5M2EzZDQ0MTUyNDc2YjE4NmUwOGQz MjFkNWQ1NzklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9bTUl MmYzeWQ2SnR3dTBtVk9lamZaaTFCUXNZdEJaMFdqZkhUYUM0ZzlHbUswJTNkPg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n IGxpc3QNCk9BdXRoQGlldGYub3JnPGphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnT0F1dGhA aWV0Zi5vcmcnKTs+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmb2F1dGgmZGF0YT0w MSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmZDkzYTNkNDQxNTI0NzZiMTg2ZTA4 ZDMyMWQ1ZDU3OSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1t NSUyZjN5ZDZKdHd1MG1WT2VqZlppMUJRc1l0QlowV2pmSFRhQzRnOUdtSzAlM2Q+DQoNCg0KDQoN Ci0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0 dHA6Ly9uYXQuc2FraW11cmEub3JnLzxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmbmF0LnNha2ltdXJhLm9yZyUyZiZkYXRhPTAx JTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2ZkOTNhM2Q0NDE1MjQ3NmIxODZlMDhk MzIxZDVkNTc5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPUxL alVmZlhGSmpjNEhKcWN3a2dXSU5RSzY1QVNkTDI5bmZlblNpSnNwakElM2Q+DQpAX25hdF9lbg0K DQoNCg== --_000_BN3PR0301MB1234046860E5CD9E774DB473A6C30BN3PR0301MB1234_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNv LXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDstd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5UaGlzIHdvcmsgaGFkIG1hbnkgaXNzdWVzIGluIHRoZSBPcGVuSUQgV0cgd2hl cmUgaXQgZmFpbGVkIHdoeSBzaG91bGQgdGhpcyBiZSBhIFdHIGl0ZW0gaGVyZSA/IFRoZSBkb2Vz IG1lZXQgdGhlIHJlcXVpcmVtZW50cyBmb3IgZXhwZXJpbWVudGFsLCB0aGVyZSBpcyBhIGZpbmUg bGluZSBiZXR3ZWVuDQogaW5mb3JtYXRpb25hbCBhbmQgZXhwZXJpbWVudGFsLCBJIHdvdWxkIGJl IE9LIHdpdGggZWl0aGVyIGJ1dCBwcmVmZXIgZXhwZXJpbWVudGFsLCBJIGRvbuKAmXQgdGhpbmsg dGhhdCB0aGlzIHNob3VsZCBiZWNvbWUgYSBzdGFuZGFyZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0aCBbbWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvaG4gQnJhZGxleTxicj4N CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjAsIDIwMTYgMTI6MTEgUE08YnI+DQo8 Yj5Ubzo8L2I+IE5hdCBTYWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29tJmd0Ozxicj4NCjxi PkNjOjwvYj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X R10gQ2FsbCBmb3IgYWRvcHRpb246IE9BdXRoIDIuMCBmb3IgTmF0aXZlIEFwcHM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QUyBhcyB5b3UgcHJvYmFibHkg c3VzcGVjdGVkIEkgYW0gaW4gZmF2b3VyIG9mIG1vdmluZyB0aGlzIGZvcndhcmQuPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKYW4gMjAsIDIwMTYs IGF0IDU6MDggUE0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdt YWlsLmNvbSI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSBmb3IgbW92aW5nIHRoaXMgZm9yd2FyZC4m bmJzcDs8YnI+DQo8YnI+DQoyMDE2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5bm0 PC9zcGFuPjE8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7mnIg8L3NwYW4+MjE8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7ml6XmnKjmm5zml6XjgIE8L3NwYW4+Sm9obiBC cmFkbGV5Jmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0 Yi5jb208L2E+Jmd0OzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPuOBleOCk+OBr+ab uOOBjeOBvuOBl+OBnzwvc3Bhbj46PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcyBtb3JlIGlzIG5lZWRlZC4gJm5ic3A7IEl0IHdhcyB0 aGVvcmV0aWNhbCBhdCB0aGF0IHBvaW50LiZuYnNwOyBOb3cgd2UgaGF2ZSBpbXBsZW1lbnRhdGlv biBleHBlcmllbmNlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIEphbiAyMCwgMjAxNiwgYXQgMzozOCBQTSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhy ZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnYmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b20nKTsiIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlcmUgaXMgPGEgaHJlZj0iaHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYl MmZ0b29scy5pZXRmLm9yZyUyZmh0bWwlMmZkcmFmdC13ZGVubmlzcy1vYXV0aC1uYXRpdmUtYXBw cy0wMCUyM2FwcGVuZGl4LUEmYW1wO2RhdGE9MDElN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQu Y29tJTdjZmQ5M2EzZDQ0MTUyNDc2YjE4NmUwOGQzMjFkNWQ1NzklN2M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPUpXSm1nTE5QWWU5NkdIVXU2N0paMXhkVU4z VDNjN2tETkxRYzh3bmlhRFElM2QiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC13ZGVubmlzcy1vYXV0aC1uYXRpdmUtYXBwcy0wMCNhcHBlbmRpeC1B PC9hPiB3aGljaCBoYXMgc29tZSBtZW50aW9uIG9mIFNGU2FmYXJpVmlld0NvbnRyb2xsZXIgYW5k IENocm9tZSBDdXN0b20gVGFicy4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NYXliZSBtb3JlIGlzIG5lZWRlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSmFuIDIwLCAyMDE2IGF0IDEwOjQ1IEFNLCBK b2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywndmU3 anRiQHZlN2p0Yi5jb20nKTsiIHRhcmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5ZZXMsIGluIEp1bHkgd2UgcmVjb21tZW5kZWQgdXNpbmcgdGhlIHN5c3RlbSBi cm93c2VyIHJhdGhlciB0aGFuIFdlYlZpZXdzLiAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFib3V0IHRoYXQgdGltZSBBcHBsZSBhbm5v dW5jZWQgU2FmYXJpIHZpZXcgY29udHJvbGxlciBhbmQgR29vZ2xlIENocm9tZSBjdXN0b20gdGFi cy4gJm5ic3A7IFRoZSBjb2RlIGluIHRoZSBPUyBpcyBub3cgc3RhYmxlIGFuZCB3ZSBoYXZlIGRv bmUgYSBmYWlyIGFtb3VudCBvZiB0ZXN0aW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgT0lERiB3aWxsIHNob3J0bHkgYmUgcHVibGlz aGluZyByZWZlcmVuY2UgbGlicmFyaWVzIGZvciBpT1MgYW5kIEFuZHJvaWQgdG8gaG93IGhvdyB0 byBiZXN0IHVzZSBWaWV3IENvbnRyb2xsZXJzLCBhbmQgUEtDRSBpbiBuYXRpdmUgYXBwcyBvbiB0 aG9zZSBwbGF0Zm9ybXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPldlIGRvIG5lZWQgdG8gdXBkYXRlIHRoaXMgZG9jIHRvIHJlZmxlY3Qgd2hh dCB3ZSBoYXZlIGxlYXJuZWQgaW4gdGhlIGxhc3QgNiBtb250aHMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBwcm9ibGVtIHdlIGRvIHN0 aWxsIGhhdmUgaXMgbm90IGhhdmluZyBzb21lb25lIHdpdGggV2luIDEwIG1vYmlsZSBleHBlcmll bmNlIHRvIGhlbHAgZG9jdW1lbnQgdGhlIGJlc3QgcHJhY3RpY2VzIGZvciB0aGF0IHBsYXRmb3Jt LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBkb27igJl0IHVuZGVyc3RhbmQgdGhhdCBwbGF0Zm9ybSB3ZWxsIGVub3VnaCB5ZXQgdG8g aW5jbHVkZSBhbnl0aGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSmFuIDIwLCAyMDE2LCBhdCAx Mjo0MCBQTSwgQWFyb24gUGFyZWNraSAmbHQ7PGEgaHJlZj0iamF2YXNjcmlwdDpfZSglN0IlN0Qs J2N2bWwnLCdhYXJvbkBwYXJlY2tpLmNvbScpOyIgdGFyZ2V0PSJfYmxhbmsiPmFhcm9uQHBhcmVj a2kuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgc2VjdGlvbiBvbiBlbWJlZGRlZCB3ZWIgdmlld3MgZG9lc24ndCBtZW50 aW9uIHRoZSBuZXcgaU9TIDkgU0ZTYWZhcmlWaWV3Q29udHJvbGxlciB3aGljaCBhbGxvd3MgYXBw cyB0byBkaXNwbGF5IGEgc3lzdGVtIGJyb3dzZXIgd2l0aGluIHRoZSBhcHBsaWNhdGlvbi4gVGhl IG5ldyBBUEkgZG9lc24ndCBnaXZlIHRoZSBjYWxsaW5nIGFwcGxpY2F0aW9uIGFjY2VzcyB0byBh bnl0aGluZyBpbnNpZGUgdGhlDQogYnJvd3Nlciwgc28gaXQgaXMgYWNjZXB0YWJsZSBmb3IgdXNp bmcgd2l0aCBPQXV0aCBmbG93cy4gSSB0aGluayBpdCdzIGltcG9ydGFudCB0byBtZW50aW9uIHRo aXMgbmV3IGNhcGFiaWxpdHkgZm9yIGFwcHMgdG8gbGV2ZXJhZ2Ugc2luY2UgaXQgbGVhZHMgdG8g YSBiZXR0ZXIgdXNlciBleHBlcmllbmNlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSdtIHN1cmUgdGhhdCBjYW4gYmUgYWRkcmVzc2VkIGluIHRoZSBjb21p bmcgbW9udGhzIGlmIHRoaXMgZG9jdW1lbnQgaXMganVzdCB0aGUgc3RhcnRpbmcgcG9pbnQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZGVm aW5pdGVseSBhZ3JlZSB0aGF0IGEgZG9jdW1lbnQgYWJvdXQgbmF0aXZlIGFwcHMgaXMgbmVjZXNz YXJ5IHNpbmNlIHRoZSBjb3JlIGxlYXZlcyBhIGxvdCBvZiBndWVzc2luZyByb29tIGZvciBhbiBp bXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkZvciByZWZlcmVuY2UsIDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmZGV2ZWxvcGVyLmFwcGxlLmNvbSUy ZmxpYnJhcnklMmZwcmVyZWxlYXNlJTJmaW9zJTJmcmVsZWFzZW5vdGVzJTJmR2VuZXJhbCUyZldo YXRzTmV3SW5pT1MlMmZBcnRpY2xlcyUyZmlPUzkuaHRtbCUyMyUyZiUyZmFwcGxlX3JlZiUyZmRv YyUyZnVpZCUyZlRQNDAwMTYxOTgtRG9udExpbmtFbGVtZW50SURfMjYmYW1wO2RhdGE9MDElN2Mw MSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZmQ5M2EzZDQ0MTUyNDc2YjE4NmUwOGQzMjFk NWQ1NzklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPWhR NkpHQkpqWCUyZndtMzZONk1wR2VYYk5RendKYWY2RzZleUd4UlZRSDRaQSUzZCIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly9kZXZlbG9wZXIuYXBwbGUuY29tL2xpYnJhcnkvcHJlcmVsZWFzZS9p b3MvcmVsZWFzZW5vdGVzL0dlbmVyYWwvV2hhdHNOZXdJbmlPUy9BcnRpY2xlcy9pT1M5Lmh0bWwj Ly9hcHBsZV9yZWYvZG9jL3VpZC9UUDQwMDE2MTk4LURvbnRMaW5rRWxlbWVudElEXzI2PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQg c2VlIHRoZSBhdHRhY2hlZCBzY3JlZW5zaG90IGZvciBhbiBleGFtcGxlIG9mIHdoYXQgaXQgbG9v a3MgbGlrZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmx0O2VtYmVkZGVkLW9hdXRoLXZpZXcucG5nJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BYXJvbiBQYXJlY2tpPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmYWFyb25w YXJlY2tpLmNvbSUyZiZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20l N2NmZDkzYTNkNDQxNTI0NzZiMTg2ZTA4ZDMyMWQ1ZDU3OSU3YzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9UzVhb0QyWDFwekJ2eTNxc0VmUGZ5RENZMFNRUnFO N0o2TSUyZkRMSnolMmZVZXclM2QiIHRhcmdldD0iX2JsYW5rIj5hYXJvbnBhcmVja2kuY29tPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg aHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cCUzYSUyZiUyZnR3aXR0ZXIuY29tJTJmYWFyb25wayZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9u eW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmZDkzYTNkNDQxNTI0NzZiMTg2ZTA4ZDMyMWQ1ZDU3OSU3 YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9bkVOMmp6Mnpz SVdsY0olMmJTV290VUg4b0xQRko4aWk0bzQ5RzBjRUhZbVFvJTNkIiB0YXJnZXQ9Il9ibGFuayI+ QGFhcm9ucGs8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFR1ZSwgSmFuIDE5LCAyMDE2IGF0IDM6NDYgQU0sIEhhbm5lcyBUc2No b2ZlbmlnICZsdDs8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ2hhbm5lcy50 c2Nob2ZlbmlnQGdteC5uZXQnKTsiIHRhcmdldD0iX2JsYW5rIj5oYW5uZXMudHNjaG9mZW5pZ0Bn bXgubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBhbGwsPGJyPg0K PGJyPg0KdGhpcyBpcyB0aGUgY2FsbCBmb3IgYWRvcHRpb24gb2YgT0F1dGggMi4wIGZvciBOYXRp dmUgQXBwcywgc2VlPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmRhdGF0cmFja2VyLmlldGYub3JnJTJm ZG9jJTJmZHJhZnQtd2Rlbm5pc3Mtb2F1dGgtbmF0aXZlLWFwcHMlMmYmYW1wO2RhdGE9MDElN2Mw MSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjZmQ5M2EzZDQ0MTUyNDc2YjE4NmUwOGQzMjFk NWQ1NzklN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmYW1wO3NkYXRhPTJj UXdMUUxrQ2lGV3hJSWF2NVRNWkZlNVZGRSUyYlhyYzNPUXE0NnEwRDBVOCUzZCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2Rlbm5pc3Mtb2F1 dGgtbmF0aXZlLWFwcHMvPC9hPjxicj4NCjxicj4NClBsZWFzZSBsZXQgdXMga25vdyBieSBGZWIg Mm5kIHdoZXRoZXIgeW91IGFjY2VwdCAvIG9iamVjdCB0byB0aGU8YnI+DQphZG9wdGlvbiBvZiB0 aGlzIGRvY3VtZW50IGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHdvcmsgaW4gdGhlIE9BdXRoPGJy Pg0Kd29ya2luZyBncm91cC48YnI+DQo8YnI+DQpOb3RlOiBJZiB5b3UgYWxyZWFkeSBzdGF0ZWQg eW91ciBvcGluaW9uIGF0IHRoZSBJRVRGIG1lZXRpbmcgaW4gWW9rb2hhbWE8YnI+DQp0aGVuIHlv dSBkb24ndCBuZWVkIHRvIHJlLXN0YXRlIHlvdXIgb3BpbmlvbiwgaWYgeW91IHdhbnQuPGJyPg0K PGJyPg0KVGhlIGZlZWRiYWNrIGF0IHRoZSBZb2tvaGFtYSBJRVRGIG1lZXRpbmcgd2FzIHRoZSBm b2xsb3dpbmc6IDE2IHBlcnNvbnM8YnI+DQpmb3IgZG9pbmcgdGhlIHdvcmsgLyAwIHBlcnNvbnMg YWdhaW5zdCAvIDIgcGVyc29ucyBuZWVkIG1vcmUgaW5mbzxicj4NCjxicj4NCkNpYW88YnI+DQpI YW5uZXMgJmFtcDsgRGVyZWs8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9ImphdmFzY3JpcHQ6X2UoJTdCJTdELCdjdm1sJywnT0F1dGhAaWV0Zi5vcmcnKTsiIHRh cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3 dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDEl N2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2ZkOTNhM2Q0NDE1MjQ3NmIxODZlMDhkMzIxZDVk NTc5JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1tNSUy ZjN5ZDZKdHd1MG1WT2VqZlppMUJRc1l0QlowV2pmSFRhQzRnOUdtSzAlM2QiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJqYXZhc2NyaXB0Ol9lKCU3QiU3RCwnY3ZtbCcsJ09BdXRo QGlldGYub3JnJyk7IiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZvYXV0aCZh bXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NmZDkzYTNkNDQxNTI0 NzZiMTg2ZTA4ZDMyMWQ1ZDU3OSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdj MSZhbXA7c2RhdGE9bTUlMmYzeWQ2SnR3dTBtVk9lamZaaTFCUXNZdEJaMFdqZkhUYUM0ZzlHbUsw JTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9ImphdmFzY3Jp cHQ6X2UoJTdCJTdELCdjdm1sJywnT0F1dGhAaWV0Zi5vcmcnKTsiIHRhcmdldD0iX2JsYW5rIj5P QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1h aWxtYW4lMmZsaXN0aW5mbyUyZm9hdXRoJmFtcDtkYXRhPTAxJTdjMDElN2N0b255bmFkJTQwbWlj cm9zb2Z0LmNvbSU3Y2ZkOTNhM2Q0NDE1MjQ3NmIxODZlMDhkMzIxZDVkNTc5JTdjNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1tNSUyZjN5ZDZKdHd1MG1WT2Vq ZlppMUJRc1l0QlowV2pmSFRhQzRnOUdtSzAlM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCi0tIDxicj4NCk5hdCBTYWtp bXVyYSAoPW5hdCk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D aGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2Fm ZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmbmF0LnNha2lt dXJhLm9yZyUyZiZhbXA7ZGF0YT0wMSU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2Nm ZDkzYTNkNDQxNTI0NzZiMTg2ZTA4ZDMyMWQ1ZDU3OSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3 Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9TEtqVWZmWEZKamM0SEpxY3drZ1dJTlFLNjVBU2RMMjlu ZmVuU2lKc3BqQSUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwv YT48YnI+DQpAX25hdF9lbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN3PR0301MB1234046860E5CD9E774DB473A6C30BN3PR0301MB1234_-- From nobody Wed Jan 20 21:38:13 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDEB1B2F9B for ; Wed, 20 Jan 2016 21:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yJ9jXMN1f1h for ; Wed, 20 Jan 2016 21:38:11 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 C3E191B2F9A for ; Wed, 20 Jan 2016 21:38:10 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id o6so12195944qkc.2 for ; Wed, 20 Jan 2016 21:38:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=l3fMnafhnmTvbmAL8etNyfZ9RMDq5TKG8Y2ZHgZbezg=; b=R76Xs6sxBmIH5inHVvOsV8S/XHN7FWJkd56cnLlUxgHSmlWBNLu6FYaj0SG6yQD8lR TjIsQgJLQHCxNsxoVPPz7BoRYLbLurr2V76JkkhCWxBpBYA0U5imhKW+ajB4tu1ow7P9 DLD/dYhwRkV6/AsB0DBqi7LygDgCxhiVJRuAuqzATlBoBw4vuKKB3kGKNjg6jHRLdylB IyvvoKz6ZyaIiN+1X+3cd/BxuMAeJNaQMF8Eee9uyCXPgy42teukJ9AUX2uVk9/cZ2hQ Z69lx5AYGsAEaWWM432WioCXJY5I+hIartSM0G7HzDMVWbDa3itVp4SALeYFgmr3w2rC pXCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=l3fMnafhnmTvbmAL8etNyfZ9RMDq5TKG8Y2ZHgZbezg=; b=GQSRN8AJIdWv3AmQ4UE9K0Tz6sXzI+U8ZpuCETd5dSeDvY+bl+SycIkrcpB69qQma1 US7DSOn+cVo8C4rdj4N7wds1sV7tR7S+W3IdAuFTjqHVSSiN9D4+uzwUXoR616ze1+Ug PuYWV2HuWJ+oEucRi2Blptin6pxj+WCXqYlWDbZXDCOv2w+7iYqgA/nmCd/x9y3BhwKJ Dosu1Fg3gbRbPu127WdNHvsSXj7+zoFxBGWdPM+LP5GtFrOf1ewAbMNNK/G+nLyx+2nB e9DEiOIsNxqNwNo62P+re//ttfbAyJM0ERaBPK71jVHcm7kflupeMh1ACDFSlK7ZFwRD BChw== X-Gm-Message-State: ALoCoQl71hFqYEXIE2V1X0Msr91NMuzUIh4+rdOXY92py6IYPZZRsHxu2Gl6WClyAiK6NWYBhCZtkgQcnT2Uk2yrhmV4iTfqGA== X-Received: by 10.55.20.211 with SMTP id 80mr49511784qku.67.1453354689927; Wed, 20 Jan 2016 21:38:09 -0800 (PST) MIME-Version: 1.0 References: <568D24DD.3050501@connect2id.com> <568D5610.6000506@lodderstedt.net> In-Reply-To: From: Nat Sakimura Date: Thu, 21 Jan 2016 05:37:59 +0000 Message-ID: To: nov matake , William Denniss Content-Type: multipart/alternative; boundary=001a11449546069dc00529d18245 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 05:38:13 -0000 --001a11449546069dc00529d18245 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ah, OK. That's actually reasonable. 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matake : > I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since the re= gistered > parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, not =E2=80=9Cp= kce_method". > > On Jan 19, 2016, at 11:58, William Denniss wrote: > > Seems like we agree this should be added. How should it look? > > Two ideas: > > "code_challenge_methods_supported": ["plain", "S256"] > > or > > "pkce_methods_supported": ["plain", "S256"] > > > > On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt < > torsten@lodderstedt.net> wrote: > >> +1 >> >> >> Am 06.01.2016 um 18:25 schrieb William Denniss: >> >> +1 >> >> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley wrote: >> >>> Good point. Now that PKCE is a RFC we should add it to discovery. >>> >>> John B. >>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov < >>> vladimir@connect2id.com> wrote: >>> > >>> > I just noticed PKCE support is missing from the discovery metadata. >>> > >>> > Is it a good idea to add it? >>> > >>> > Cheers, >>> > >>> > Vladimir >>> > >>> > -- >>> > 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 >>> >> >> >> >> _______________________________________________ >> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa= uth >> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11449546069dc00529d18245 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ah, OK. That's actually reasonable.=C2=A0

2016=E5=B9=B41=E6=9C=8821=E6=97=A5= (=E6=9C=A8) 9:31 nov matake <matake@= gmail.com>:
I prefer =E2=80=9Ccode_challenge_methods_supported=E2= =80=9D, since the registered parameter name is =E2=80=9Ccode_challenge_meth= od=E2=80=9D, not =E2=80=9Cpkce_method".

On Jan 19, 2016, at= 11:58, William Denniss <wdenniss@google.com> wrote:

Seems like we agree this should be added. How should it look?

Two= ideas:

"code_challenge_methods_supported": ["plain&q= uot;, "S256"]

or

"pkce= _methods_supported": ["plain", "S256"]


=

On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt <= torsten@lodder= stedt.net> wrote:
=20 =20 =20
+1


Am 06.01.2016 um 18:25 schrieb William Denniss:
+1

On Wed, Jan 6, 2016 at 6:40 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Good point.=C2=A0 Now that PKCE is a RFC we should add it to discovery.

John B.
> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
>
> I just noticed PKCE support is missing from the discovery metadata.
>
> Is it a good idea to add it?
>
> Cheers,
>
> Vladimir
>
> --
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@= ietf.org
> https://www.ietf.org/mailman/listinfo/oa= uth

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



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


_______________________________________________
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
--001a11449546069dc00529d18245-- From nobody Wed Jan 20 22:11:27 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7C31B3016 for ; Wed, 20 Jan 2016 22:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQg_5zq3kLLd for ; Wed, 20 Jan 2016 22:11:23 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33D31B3014 for ; Wed, 20 Jan 2016 22:11:22 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id w75so20399511oie.0 for ; Wed, 20 Jan 2016 22:11:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iYEwXqWvquqFUfcq4IluohP3xM//nVIz934IwsOgUk4=; b=iR3UMM0s6C93QIwHlZlF4H5OFUHK/UnRSNQXO+5jGiiJpDBYZzKEJFX5P4Kdx8aelX txDg6NUml+9VAt7hONfDdY0j5P8ldJFGB0HoUaJ/JuYa6IlLEofneNjFnhE7Ln9QUOnk TligTGM8LDTrdtYdxSXDladLaQE49Daw7OkqNHm+ZMsEbMdA2NKSM4d2cjtB5wbCmVF8 jZrA5vsx8ph2+vZ7OcPd/B2o37I46YJ4qZ1KttNlSg2sJd6+nOwpgyvQBaoYNt8WFqQa FfNh/R94Hmg/0jCAvbq4+37paDhMOKyEfhyZvdTAxK73Jp5yHVz3N0tvQWKqj4E2HF3h YWMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iYEwXqWvquqFUfcq4IluohP3xM//nVIz934IwsOgUk4=; b=kr+ToBdAHt8SMmzy642ZYYCXm2w2QwXNZXnP3vZw8DwcBhszFvHL2zSrzRmhuQGn+T KMhfvjgAJe9IqfF3aYv9xMyvhjd+0y5UEqZtKGpdICv49O69REr3kDu6EOzZTVSq9A4E G3Jk9SSSVz/N4/350Elpr/TqnHNZ9L3bacYzQ0cZ2ZQTKmh0wZ1g0Xu92co+7jp3ko9u 5D3s+a/JrUZml03Qz4fn7YvHo4RRGpOx2N/zFn6ilZNubUYWBw1BAOQYSSdN/J0qHhbC sYb0DMR98CT69rBmepEIYcL9sp1X2cULmBCiRS0Et7PxRzgFftrcvQylxDT4dx6nE9YI kTRw== X-Gm-Message-State: ALoCoQk7ctrCZ2OR77KxIJdF01fUYF92ebvb67vCTyi6WGEcksYoW0rFbzQFx3Af+c5jFg9D4/xogR9ZeCcjdJbIU2JpBxk+3CAnaGy157aqWrZMwCeQNZU= X-Received: by 10.202.226.141 with SMTP id z135mr29482628oig.21.1453356681761; Wed, 20 Jan 2016 22:11:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Wed, 20 Jan 2016 22:11:02 -0800 (PST) In-Reply-To: References: <569E2231.1010107@gmx.net> <6ADAA1B5-7EF9-49EA-A3D9-6EFC57275EB9@ve7jtb.com> <9062E913-39FB-4610-80FE-70796CBDEAC1@ve7jtb.com> From: William Denniss Date: Thu, 21 Jan 2016 14:11:02 +0800 Message-ID: To: Anthony Nadalin Content-Type: multipart/alternative; boundary=001a11408cf8bffef40529d1f858 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 06:11:27 -0000 --001a11408cf8bffef40529d1f858 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe this is important work. The original OAuth 2 spec left the topic of native apps largely undefined which is fair enough, the mobile-first revolution had yet to really take hold and people didn't have much implementation experience for OAuth on mobile. But we've come a long way since then, we have the experience now and I think there is a need for leadership in this space, and that it makes sense for the OAUTH-WG to continue our work and provide that leadership. The risk of not defining a best practice for native apps is dilution of the open standards =E2=80=93 if everyone implements OAuth differently for nativ= e apps, and RPs have to write IDP-specific code then what is the point of having OAuth as a standard in the first place? Security is a major concern as well, there are a lot of ways to mess this up and the security situation for OAuth in many native apps is not nearly as good as it could be. By providing leadership in the form of a working group document, we can present community advice with the hope that IDPs and RPs alike will follow our recommendations, resulting in more interoperability, better usability and higher security. The best part about this spec is that it's pure OAuth! Just wrapped with some native app specific recommendations for both RPs and IDPs, to achieve the desired levels of usability and security on mobile. I will point out that we have rough consensus and running code. The rough consensus can be seen from the WG votes, and the sentiment on this thread (your dissenting opinion notwithstanding). Regarding running code, my team is in the process of open sourcing libraries that will implement this best practice to the letter (and the code's already running, I assure you). The proprietary Google Sign-in and Facebook Sign-in SDKs are also using in-app browser tabs for OAuth flows in production today, which I think is further evidence that this is a viable pattern. This document and proposal was never part of the OpenID working group that you refer to below. I'm not saying the document is perfect, and it is definitely in need of an update! But I'm committed to listening to the community and taking it forward. Now that the dependencies have launched, and our library implementations are done, I plan to update the doc with the feedback from this community, and the lessons we and others have learnt from our implementations. I hope the working group will consider adopting this document. Kind Regards, William On Thu, Jan 21, 2016 at 12:33 PM, Anthony Nadalin wrote: > This work had many issues in the OpenID WG where it failed why should thi= s > be a WG item here ? The does meet the requirements for experimental, ther= e > is a fine line between informational and experimental, I would be OK with > either but prefer experimental, I don=E2=80=99t think that this should be= come a > standard. > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley > *Sent:* Wednesday, January 20, 2016 12:11 PM > *To:* Nat Sakimura > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps > > > > PS as you probably suspected I am in favour of moving this forward. > > > > > > On Jan 20, 2016, at 5:08 PM, Nat Sakimura wrote: > > > > +1 for moving this forward. > > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5=E6=9C=A8=E6=9B=9C=E6=97=A5=E3=80=81Joh= n Bradley=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D= =E3=81=BE=E3=81=97=E3=81=9F: > > Yes more is needed. It was theoretical at that point. Now we have > implementation experience. > > > > On Jan 20, 2016, at 3:38 PM, Brian Campbell > wrote: > > > > There is > https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#appendix-= A > > which has some mention of SFSafariViewController and Chrome Custom Tabs. > > Maybe more is needed? > > > > On Wed, Jan 20, 2016 at 10:45 AM, John Bradley wrote: > > Yes, in July we recommended using the system browser rather than WebViews= . > > > > > About that time Apple announced Safari view controller and Google Chrome > custom tabs. The code in the OS is now stable and we have done a fair > amount of testing. > > > > The OIDF will shortly be publishing reference libraries for iOS and > Android to how how to best use View Controllers, and PKCE in native apps = on > those platforms. > > > > We do need to update this doc to reflect what we have learned in the last > 6 months. > > > > One problem we do still have is not having someone with Win 10 mobile > experience to help document the best practices for that platform. > > I don=E2=80=99t understand that platform well enough yet to include anyth= ing. > > > > John B. > > > > On Jan 20, 2016, at 12:40 PM, Aaron Parecki wrote: > > > > The section on embedded web views doesn't mention the new iOS 9 > SFSafariViewController which allows apps to display a system browser with= in > the application. The new API doesn't give the calling application access = to > anything inside the browser, so it is acceptable for using with OAuth > flows. I think it's important to mention this new capability for apps to > leverage since it leads to a better user experience. > > > > I'm sure that can be addressed in the coming months if this document is > just the starting point. > > > > I definitely agree that a document about native apps is necessary since > the core leaves a lot of guessing room for an implementation. > > > > For reference, > https://developer.apple.com/library/prerelease/ios/releasenotes/General/W= hatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElem= entID_26 > > > > > And see the attached screenshot for an example of what it looks like. > > > > > > > ---- > > Aaron Parecki > > aaronparecki.com > > > @aaronpk > > > > > > > On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > > Hi all, > > this is the call for adoption of OAuth 2.0 for Native Apps, see > http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ > > > Please let us know by Feb 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Note: If you already stated your opinion at the IETF meeting in Yokohama > then you don't need to re-state your opinion, if you want. > > The feedback at the Yokohama IETF meeting was the following: 16 persons > for doing the work / 0 persons against / 2 persons need more info > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > -- > Nat Sakimura (=3Dnat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > > @_nat_en > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --001a11408cf8bffef40529d1f858 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe this is important work.

<= /div>
The original OAuth 2 spec left the topic of native apps largely u= ndefined which is fair enough, the mobile-first revolution had yet to reall= y take hold and people didn't have much implementation experience for O= Auth on mobile. But we've come a long way since then, we have the exper= ience now and I think there is a need for leadership in this space, and tha= t it makes sense for the OAUTH-WG to continue our work and provide that lea= dership.

The risk of not defining a best practice f= or native apps is dilution of the open standards =E2=80=93 if everyone impl= ements OAuth differently for native apps, and RPs have to write IDP-specifi= c code then what is the point of having OAuth as a standard in the first pl= ace? Security is a major concern as well, there are a lot of ways to mess t= his up and the security situation for OAuth in many native apps is not near= ly as good as it could be.

By providing leadership= in the form of a working group document, we can present community advice w= ith the hope that IDPs and RPs alike will follow our recommendations, resul= ting in more interoperability, better usability and higher security.
<= div>
The best part about this spec is that it's pure= OAuth! Just wrapped with some native app specific recommendations for both= RPs and IDPs, to achieve the desired levels of usability and security on m= obile.

I will point out that we have rough c= onsensus and running code. The rough consensus can be seen from the WG vote= s, and the sentiment on this thread (your dissenting opinion notwithstandin= g). Regarding running code, my team is in the process of open sourcing libr= aries that will implement this best practice to the letter (and the code= 9;s already running, I assure you). The proprietary Google Sign-in and Face= book Sign-in SDKs are also using in-app browser tabs for OAuth flows in pro= duction today, which I think is further evidence that this is a viable patt= ern.

This document and proposal was never part of = the OpenID working group that you refer to below.

= I'm not saying the document is perfect, and it is definitely in need of= an update! But I'm committed to listening to the community and taking = it forward. Now that the dependencies have launched, and our library implem= entations are done, I plan to update the doc with the feedback from this co= mmunity, and the lessons we and others have learnt from our implementations= .

I hope the working group will consider adopting = this document.

Kind Regards,
William


On Thu= , Jan 21, 2016 at 12:33 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:

This work had many issues in the OpenID WG where it failed why sh= ould this be a WG item here ? The does meet the requirements for experiment= al, there is a fine line between informational and experimental, I would be OK with either but prefer exper= imental, I don=E2=80=99t think that this should become a standard.

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, January 20, 2016 12:11 PM
To: Nat Sakimura <sakimura@gmail.com>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps=

=C2=A0

PS as you probably suspected I am in favour of movin= g this forward.

=C2=A0

=C2=A0

On Jan 20, 2016, at 5:08 PM, Nat Sakimura <sakimura@gmail.com>= ; wrote:

=C2=A0

+1 for moving this forward.=C2=A0

2016=E5=B9=B41=E6=9C=8821=E6=97= =A5=E6=9C=A8=E6=9B=9C=E6=97=A5=E3=80=81John Bradley<ve7jtb@ve7jtb.com>=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3= =81=BE=E3=81=97=E3=81=9F:

Yes more is needed. =C2=A0 It was theoretical at tha= t point.=C2=A0 Now we have implementation experience.

=C2=A0

On Jan 20, 2016, at 3:38 PM, Brian Campbell <b= campbell@pingidentity.com> wrote:

=C2=A0

=C2=A0

On Wed, Jan 20, 2016 at 10:45 AM, John Bradley <<= a>ve7jtb@ve7jtb.com> wrote:

Yes, in July we recommended using the system browser= rather than WebViews. =C2=A0=C2=A0

=C2=A0

About that time Apple announced Safari view controll= er and Google Chrome custom tabs. =C2=A0 The code in the OS is now stable a= nd we have done a fair amount of testing.

=C2=A0

The OIDF will shortly be publishing reference librar= ies for iOS and Android to how how to best use View Controllers, and PKCE i= n native apps on those platforms.

=C2=A0

We do need to update this doc to reflect what we hav= e learned in the last 6 months.

=C2=A0

One problem we do still have is not having someone w= ith Win 10 mobile experience to help document the best practices for that p= latform.=C2=A0

I don=E2=80=99t understand that platform well enough= yet to include anything.

=C2=A0

John B.

=C2=A0

On Jan 20, 2016, at 12:40 PM, Aaron Parecki <a= aron@parecki.com> wrote:

=C2=A0

The section on embedded web views doesn't mentio= n the new iOS 9 SFSafariViewController which allows apps to display a syste= m browser within the application. The new API doesn't give the calling = application access to anything inside the browser, so it is acceptable for using with OAuth flows. I think it's = important to mention this new capability for apps to leverage since it lead= s to a better user experience.

=C2=A0

I'm sure that can be addressed in the coming mon= ths if this document is just the starting point.

=C2=A0

I definitely agree that a document about native apps= is necessary since the core leaves a lot of guessing room for an implement= ation.

=C2=A0

=C2=A0

And see the attached screenshot for an example of wh= at it looks like.

=C2=A0

<embedded-oauth-view.png>


----

Aaron Parecki

=C2=A0

=C2=A0

On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig &= lt;hannes.tschofenig@gmx.net> wrote:

Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see
http://datatracker.ietf.org/doc/dr= aft-wdenniss-oauth-native-apps/

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

Note: If you already stated your opinion at the IETF meeting in Yokohama then you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 16 persons
for doing the work / 0 persons against / 2 persons need more info

Ciao
Hannes & Derek


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

=C2=A0

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

=C2=A0


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

=C2=A0

=C2=A0



--
Nat Sakimura (=3Dnat)

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

=C2=A0

=C2=A0


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


--001a11408cf8bffef40529d1f858-- From nobody Wed Jan 20 22:13:05 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F46B1B3019 for ; Wed, 20 Jan 2016 22:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9ed41DxF3kn for ; Wed, 20 Jan 2016 22:13:02 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 88EA01B3018 for ; Wed, 20 Jan 2016 22:13:02 -0800 (PST) Received: by mail-ob0-x236.google.com with SMTP id ba1so27461961obb.3 for ; Wed, 20 Jan 2016 22:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Cv1PaJPtE/4fbtWS57Tngy5SWf7ekColrEyx9E3bkBs=; b=Oq9LN4fBmen86aAMu/e867wAcuzbNZZ02LDrGKSA2AHt4TG7D4lzjTxPaw0JdBKoKl e3E/igGyiVHo6ixPYx/5IrSFjiyoMrOInuGXcddNebjhhYIbB/ibVZ751vtepLgR2Bo2 jgF9nqeX5PRx/GguGZwiWW+zHXZuvM0C9c8CXuEDS/l5FTCzjvQ2ceCHG6T4Ye146wu0 54mQJiMf4eWqEZELlKBvxJvUMY6O/++ohmhIMIP+SygR9HIKaKXmKhM7PIvI4yim+5cC +9OJvaMAE7X35mJM7Lil21WESmCj06AFKkzoR9N86Gin9HSeneuevXUeghrqB8sJUpPn IpaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Cv1PaJPtE/4fbtWS57Tngy5SWf7ekColrEyx9E3bkBs=; b=bGRmehRZeI38LGzEFePIRusALGu6Ew2STgUaNWer7xAq+pY0Ga4QR63XYwj60gKtlZ PG1jgd0CLxIEQZVzv1jtm723IMq+V/2DS8qv95MEsxvdR3PB1iEp7NKy9Qb/1tTFJ1P6 wtgWUJydm5+uE2TxfMOPGmTB1sF+vwK7CtXfFy+e9m1GmChGfFMjiIBDGWQ7zx3Y7Fe9 aN0NVj+zKeNxpdbT7nzkHTUk9JTtciXnkcbe6eqFpyhfQ3LUcI85kLvWKuUQSbzDnXuh 1ShIUezDIm0Hi0rQgdwol6oKhILD7jDp5s3c29Hl3T/nz7sfAlD/cDZhRRoGG/kYVY/G QMWg== X-Gm-Message-State: ALoCoQlt11thSV1Fu3ArzuSuJ5oap3L/Ontla/Yw9nnb8aM60QzYqz1wGyENmIIbRv5Q0gqSd1YTcg/cWChw6urC8REcO8l/qK4FKRCk3MgbtRObxj38SO8= X-Received: by 10.182.214.40 with SMTP id nx8mr32607809obc.20.1453356781873; Wed, 20 Jan 2016 22:13:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Wed, 20 Jan 2016 22:12:42 -0800 (PST) In-Reply-To: References: <568D24DD.3050501@connect2id.com> <568D5610.6000506@lodderstedt.net> From: William Denniss Date: Thu, 21 Jan 2016 14:12:42 +0800 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=e89a8ff1c01eb78a7e0529d1fee5 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 06:13:04 -0000 --e89a8ff1c01eb78a7e0529d1fee5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "code_challenge_methods_supported" definitely works for me. Any objections to moving forward with that? I would like to update our discovery doc shortly. On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura wrote: > Ah, OK. That's actually reasonable. > > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matake : > >> I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since the r= egistered >> parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, not =E2=80=9C= pkce_method". >> >> On Jan 19, 2016, at 11:58, William Denniss wrote: >> >> Seems like we agree this should be added. How should it look? >> >> Two ideas: >> >> "code_challenge_methods_supported": ["plain", "S256"] >> >> or >> >> "pkce_methods_supported": ["plain", "S256"] >> >> >> >> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt < >> torsten@lodderstedt.net> wrote: >> >>> +1 >>> >>> >>> Am 06.01.2016 um 18:25 schrieb William Denniss: >>> >>> +1 >>> >>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley wrote: >>> >>>> Good point. Now that PKCE is a RFC we should add it to discovery. >>>> >>>> John B. >>>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov < >>>> vladimir@connect2id.com> wrote: >>>> > >>>> > I just noticed PKCE support is missing from the discovery metadata. >>>> > >>>> > Is it a good idea to add it? >>>> > >>>> > Cheers, >>>> > >>>> > Vladimir >>>> > >>>> > -- >>>> > 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 >>>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/o= auth >>> >>> >>> >> _______________________________________________ >> 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 >> > --e89a8ff1c01eb78a7e0529d1fee5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"code_challenge_meth= ods_supported" definitely works for me.

A= ny objections to moving forward with that? I would like to update our disco= very doc shortly.

On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura <sakimu= ra@gmail.com> wrote:
Ah, OK. That's actually reasonable.=C2=A0

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6= =9C=A8) 9:31 nov matake <matake@gmail.com>:
I prefer =E2=80=9C= code_challenge_methods_supported=E2=80=9D, since the registered parameter n= ame is =E2=80=9Ccode_challenge_method=E2=80=9D, not =E2=80=9Cpkce_method&qu= ot;.

On Jan 19, 2016, at 11:58, William Denniss <wdenniss@google.com> wr= ote:

Seems like we agree this should be adde= d. How should it look?

Two ideas:

"code_challenge_method= s_supported": ["plain", "S256"]

or

"pkce_methods_supported": ["plain&quo= t;, "S256"]



On Wed, Jan 6, 2016 at 9:59 AM, Torsten L= odderstedt <torsten@lodderstedt.net> wrote:
=20 =20 =20
+1


Am 06.01.2016 um 18:25 schrieb William Denniss:
+1

On Wed, Jan 6, 2016 at 6:40 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Good point.=C2=A0 Now that PKCE is a RFC we should add it to discovery.

John B.
> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
>
> I just noticed PKCE support is missing from the discovery metadata.
>
> Is it a good idea to add it?
>
> Cheers,
>
> Vladimir
>
> --
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@= ietf.org
> https://www.ietf.org/mailman/listinfo/oa= uth

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



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


_______________________________________________
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

--e89a8ff1c01eb78a7e0529d1fee5-- From nobody Wed Jan 20 22:14:16 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F511B3018 for ; Wed, 20 Jan 2016 22:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEPXxFxfwEcw for ; Wed, 20 Jan 2016 22:14:13 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0098.outbound.protection.outlook.com [65.55.169.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E531B3025 for ; Wed, 20 Jan 2016 22:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WDcUQKESAZQS9+UT1QA8gQQPrt4Jr3DU+iS4576Q5Vc=; b=gEdqqklhf8Xb4ngiajul71hz70EtR6/Pnm8LS+zMU1wBDFSLWiCLv44/SfniDJM2gUxjtFP8u04HqTx3LxVR99zy93st2AVcxBoS1sonvnKtnvSWuIEO/C1/GIQ4qO64ClQhRV3IjadEinjrbFj5ZgXE3NPZsujCCZQjQj3LzgM= Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1031.namprd02.prod.outlook.com (10.161.203.149) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 21 Jan 2016 06:14:05 +0000 Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) with mapi id 15.01.0365.024; Thu, 21 Jan 2016 06:14:05 +0000 From: Antonio Sanso To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation Thread-Index: AQHRUq+IUS4vjFsIHkCmfIZoh/dvmp8Fh/8A Date: Thu, 21 Jan 2016 06:14:05 +0000 Message-ID: <3663C301-FE1B-465C-B8FF-3BBF2F4C0A43@adobe.com> References: <569E22E1.5010402@gmx.net> In-Reply-To: <569E22E1.5010402@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [188.61.97.101] x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1031; 5:NnmRGuI7JzA5IypebNRJW907xbnrfLznUrokh00thMhzhxsgcs7apLkbkkF9fb689KbdA17JCAIvGbs8WLDH6wMgkB75fjcB8akWdjF52KnR0n3Wj4oVI9qXNlFk/sFhwYr8TuStSy3+0Pv3lvLyPg==; 24:WhCNqp9U4xkLzSpf6pE/wVAT4IfMRgyLjKlp+7REUvBMjn5VkMuNgJmjvalQQpF4djuFF3J51MKWn50iMxwyaREfW6HpY8f7Ha9gWnoYm0w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1031; x-ms-office365-filtering-correlation-id: c82f5c14-2814-4387-28d6-08d3222a10be x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY1PR0201MB1031; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1031; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(377454003)(24454002)(53754006)(36944003)(1096002)(50986999)(40100003)(33656002)(82746002)(10400500002)(4326007)(106356001)(189998001)(122556002)(106116001)(105586002)(1220700001)(101416001)(2906002)(36756003)(99286002)(76176999)(10090500001)(54356999)(11100500001)(5001960100002)(102836003)(110136002)(5002640100001)(3846002)(5008740100001)(15975445007)(66066001)(586003)(5004730100002)(81156007)(92566002)(87936001)(19580405001)(2950100001)(77096005)(19580395003)(2900100001)(86362001)(6116002)(83716003)(97736004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1031; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2016 06:14:05.0959 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1031 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 06:14:15 -0000 +1 for adoption On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig = wrote: > Hi all, >=20 > this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see > https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 >=20 > Please let us know by Feb 9th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. >=20 > Note: This call is related to the announcement made on the list earlier > this month, see > http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More > time for analysis is provided due to the complexity of the topic. >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Jan 20 22:15:09 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7643D1B2E5B for ; Wed, 20 Jan 2016 22:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMhANMCikDRG for ; Wed, 20 Jan 2016 22:15:06 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0070.outbound.protection.outlook.com [65.55.169.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230101B301F for ; Wed, 20 Jan 2016 22:15:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=K5ZGnwFvhgsOxOx0gMS3PuNVdLKxGyeEGaZrvCH8lrA=; b=OkF1VIuQEyiJXW1JwE1aBEgXk+/aFDas6Hff+/5D584OigbuP2phTf9Gswq2CTZGl0i8xRyMz5oFcQAUfenZ3QD2FzMZBJQ2uQb+SKoaQhyiqr9aAP3lhzhLpEPfxwHWFS9WwRQo3TzvIiz0DoYXQl/gUnBJ7SXBaoMT9aJGXpw= Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1031.namprd02.prod.outlook.com (10.161.203.149) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 21 Jan 2016 06:15:03 +0000 Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) with mapi id 15.01.0365.024; Thu, 21 Jan 2016 06:15:02 +0000 From: Antonio Sanso To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps Thread-Index: AQHRUq8hQD5+t8okHk6fLg15TaL8q58FiEUA Date: Thu, 21 Jan 2016 06:15:02 +0000 Message-ID: References: <569E2231.1010107@gmx.net> In-Reply-To: <569E2231.1010107@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [188.61.97.101] x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1031; 5:HLNRw+k75ypkMKM4nPVUqTsqMThzTBzKTx/hTxR29GUKpzfMIrZ60tKL7IPEfnkOs15GxsuGw9OuZ9Zq3IcP7Cyn0pwxySkVYHBGhZ1fFpCV8H5Qg7EeRFs62CFl69XYrSqF3WTxoGbsw2hDlOuoUw==; 24:YRgQ2CMdubAWS8BWCMV0I1bg0IlGcArJC9wZeZg2Ddi4sOjKlCp51ar5028MKuwnZuTdJHrUfQg1iEt0HsIJbc95hgO3v6733uQFVZHxWto= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1031; x-ms-office365-filtering-correlation-id: c35a6c91-36b8-4f64-03ba-08d3222a32f1 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY1PR0201MB1031; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1031; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(377454003)(24454002)(53754006)(1096002)(50986999)(40100003)(33656002)(82746002)(10400500002)(4326007)(106356001)(189998001)(122556002)(106116001)(105586002)(1220700001)(101416001)(2906002)(36756003)(99286002)(76176999)(10090500001)(54356999)(5001960100002)(102836003)(110136002)(5002640100001)(3846002)(5008740100001)(15975445007)(66066001)(586003)(5004730100002)(81156007)(92566002)(87936001)(19580405001)(2950100001)(77096005)(19580395003)(2900100001)(86362001)(6116002)(83716003)(97736004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1031; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <8FE806871241BC4184DA8018CB9BCB6D@namprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2016 06:15:02.5342 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1031 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 06:15:07 -0000 +1 for adoption. I do really think this fills a current gap. regards antonio On Jan 19, 2016, at 12:46 PM, Hannes Tschofenig = wrote: > Hi all, >=20 > this is the call for adoption of OAuth 2.0 for Native Apps, see > http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ >=20 > Please let us know by Feb 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. >=20 > Note: If you already stated your opinion at the IETF meeting in Yokohama > then you don't need to re-state your opinion, if you want. >=20 > The feedback at the Yokohama IETF meeting was the following: 16 persons > for doing the work / 0 persons against / 2 persons need more info >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Jan 20 22:16:20 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1806D1B301F for ; Wed, 20 Jan 2016 22:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaGd-qtag2m3 for ; Wed, 20 Jan 2016 22:16:16 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0098.outbound.protection.outlook.com [65.55.169.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2981B3017 for ; Wed, 20 Jan 2016 22:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adobe.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9kgxxMeIIUOSNVbeWp88fhZ5j0NFffPuCCkdORMwmss=; b=c63ml6GSnSfvGhegLLcRP0uVga1nXFlQIrjyaD1pbQeL33O9jVyqZucIyNzRlLY8BM4Fxvz/weN1rv9Ou7yGSAKSNETCpUZe8r7hZaUzOW5Es/vQ8bMiizbf7TyGJpIQUY/QfzZ3DaTGhekcRzhp0Yj6JZiZsdKJQvJNaTSGOd4= Received: from BY1PR0201MB1030.namprd02.prod.outlook.com (10.161.203.148) by BY1PR0201MB1031.namprd02.prod.outlook.com (10.161.203.149) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 21 Jan 2016 06:15:59 +0000 Received: from BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) by BY1PR0201MB1030.namprd02.prod.outlook.com ([10.161.203.148]) with mapi id 15.01.0365.024; Thu, 21 Jan 2016 06:15:59 +0000 From: Antonio Sanso To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector Thread-Index: AQHRUq88nYeyDhdTzE+AmxwH/y0zZJ8FiImA Date: Thu, 21 Jan 2016 06:15:59 +0000 Message-ID: References: <569E2260.4080904@gmx.net> In-Reply-To: <569E2260.4080904@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=asanso@adobe.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [188.61.97.101] x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1031; 5:5KptGKHJ2HtN/tqAbXgDjZhahGG3TUUMkGJ+OyuZvEiNglS/9HEJpRVDCz7E3PBeuytHjYVkWZPQAf11uMQS9YndQ/xOMptQ+2hOsTGm2gllb77ckIEbTUFSRDhit2MxsT0qjtHHkNc0XPVl9xsh1A==; 24:a1P9bWy94es/CoalxkRIR7C3jAtA2nvx+XuAkz5xuu+DWLWbFTG15K3VvYzucZaeErK0BzUwOj0+EI8GWibB4RmVXo+63fLtJAiou5KekrM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1031; x-ms-office365-filtering-correlation-id: 82a87d36-9070-4ae5-91ce-08d3222a54f6 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY1PR0201MB1031; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1031; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(377454003)(24454002)(53754006)(1096002)(50986999)(40100003)(33656002)(82746002)(10400500002)(4326007)(106356001)(189998001)(122556002)(106116001)(105586002)(1220700001)(101416001)(2906002)(36756003)(99286002)(76176999)(10090500001)(54356999)(11100500001)(5001960100002)(102836003)(110136002)(5002640100001)(3846002)(5008740100001)(15975445007)(66066001)(586003)(5004730100002)(81156007)(92566002)(87936001)(19580405001)(2950100001)(77096005)(19580395003)(2900100001)(86362001)(6116002)(83716003)(97736004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1031; H:BY1PR0201MB1030.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: adobe.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2016 06:15:59.6756 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1031 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 06:16:18 -0000 +1 for adoption On Jan 19, 2016, at 12:47 PM, Hannes Tschofenig = wrote: > Hi all, >=20 > this is the call for adoption of OAuth 2.0 Security: OAuth Open > Redirector, see > https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02 >=20 > Please let us know by Feb 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. >=20 > Note: At the IETF Yokohama we asked for generic feedback about doing > security work in the OAuth working group and there was very positive > feedback. However, for the adoption call we need to ask for individual > documents. Hence, you need to state your view again. >=20 > Ciao > Hannes & Derek >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Jan 20 22:18:27 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157B31B3035 for ; Wed, 20 Jan 2016 22:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MY8BCOTDWy1s for ; Wed, 20 Jan 2016 22:18:25 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::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 CB66F1B3036 for ; Wed, 20 Jan 2016 22:18:24 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id ba1so27541294obb.3 for ; Wed, 20 Jan 2016 22:18:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hqcfF4mI3FaIqIVUR/aMfz8WJ99s/jAyh6gza04wLKE=; b=VbPqtlwWZQpFgiiLnlKYNZ3I8QwarqyafwpycJhufhSW0bqWwvOTGXISbLEEyl/9LN KDO4+/Ubtsbapmme/T09Bcamr/NlKfMWtXSNOtMduw+RkjLjR+KFn/FReH48GJSTKcBd 0cvf7iF1ktFdjkyTU8WqOo9eI/XTVzNiaI02B0BTZvlxfRfj4F9nxZWSsDZ+IBF0EpfQ hIEo6/K99xooaoklVdiTZ1/QhbxjsPFj2yK0T9Ce3W6/bbD4pj38swiYIQTry+hEGc5R WytFWTvUaZi0HRVo+1m+wsyqx86ZGyN9o3xN626Kn4nv7ncO7ClMSYf4ara7rTx4PqOd uVGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hqcfF4mI3FaIqIVUR/aMfz8WJ99s/jAyh6gza04wLKE=; b=cRjUJS9PhMrmWAvVuMOuacavdeWSdFP2JmwItDxlbCWq2CQ88qyXhIlQvZjGxbJtou JSqrJ06We5lLVV5rp4OwcujDCfHtie8+8usGX8vYub5IYPVCEhMlcFJ0hek/5R6Ksk9D TgakgqlchFsDrR/mCe2xVKDb8opYJ6Ez8IKR3bJcCW9G/HVvEEIyazUOhivh3uJJMTYf qjMX/fV8A3CEiaic8YpE52BW4dp5OblxUga8jBi1Rsbx2M311Wflz2OVojZmsiCVxc9D r+2AhpuqNEoMLhbo2Fffoii4o0GEklzkwkjXktOFRerD4xfWNqjIGV8vFXQI89dBrf9w iUMg== X-Gm-Message-State: ALoCoQnZy5C6a/aDrntQ2MeJc/idGXfDUy6YoekXGyj2zre8h7OER2pVczx9vmFRrJ4RgtDC4+c4X+v+wxiW4FKCuIcmB0ndjYXPN8kVlGfAP5F3r3UTbtc= X-Received: by 10.182.130.162 with SMTP id of2mr30419539obb.57.1453357104186; Wed, 20 Jan 2016 22:18:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Wed, 20 Jan 2016 22:18:04 -0800 (PST) In-Reply-To: <569E2260.4080904@gmx.net> References: <569E2260.4080904@gmx.net> From: William Denniss Date: Thu, 21 Jan 2016 14:18:04 +0800 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=089e013cbb2ced8d2a0529d211ab Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 06:18:27 -0000 --089e013cbb2ced8d2a0529d211ab Content-Type: text/plain; charset=UTF-8 +1 for adoption. On Tue, Jan 19, 2016 at 7:47 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi all, > > this is the call for adoption of OAuth 2.0 Security: OAuth Open > Redirector, see > https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02 > > Please let us know by Feb 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Note: At the IETF Yokohama we asked for generic feedback about doing > security work in the OAuth working group and there was very positive > feedback. However, for the adoption call we need to ask for individual > documents. Hence, you need to state your view again. > > Ciao > Hannes & Derek > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e013cbb2ced8d2a0529d211ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for adoption.

On Tue, Jan 19, 2016 at 7:47 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

this is the call for adoption of OAuth 2.0 Security: OAuth Open
Redirector, see
https://tools.ietf.org/html/draft-= bradley-oauth-open-redirector-02

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

Note: At the IETF Yokohama we asked for generic feedback about doing
security work in the OAuth working group and there was very positive
feedback. However, for the adoption call we need to ask for individual
documents. Hence, you need to state your view again.

Ciao
Hannes & Derek





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


--089e013cbb2ced8d2a0529d211ab-- From nobody Wed Jan 20 22:28:14 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17111A0021 for ; Wed, 20 Jan 2016 22:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFySD8B8PX36 for ; Wed, 20 Jan 2016 22:28:11 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0115.outbound.protection.outlook.com [65.55.169.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278551A0020 for ; Wed, 20 Jan 2016 22:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xjdf6b90Z6/yZ5QACT6dz/vxtMrnqHIg9BRADHf090s=; b=UGnCRrszsauy1HPwX17ew8ABvLQR+lukKXg9KfSK0LZ/G9I9BQgMJ/Nsl7wQlaJ0iFwAKFAl90a/2UTQ/mC52f9xScR56QlYrXRotr9h8u4tKQHGAzzYlD0g/8cPr894czBHwKeX1L0ekMrtA/+ZJYTjev90caBkVtvGXs72ON4= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 21 Jan 2016 06:28:07 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Thu, 21 Jan 2016 06:28:06 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Second OAuth 2.0 Mix-Up Mitigation Draft Thread-Index: AdFUEBzZ6e4AaDkzTDCogBxKcuNPEw== Date: Thu, 21 Jan 2016 06:28:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: fa37ec44-7de7-4979-815a-08d3222c065a x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:EZhUZuuszutrplkCEArELnsy/QY8zx43iHCYSO4r5pfoD6i/ei7Hjwbhmg6/NP9+GaWCWFsx1nP4iqlu1ojzgBzXy3wfBl6k/u8MVDfMP8YnxYDuDvDlCVkRmKhFHQ8ufmncmkkNXbzzs59Y2P/sgA==; 24:qb1/SETz50O5QlJmPutol+oFKmd4aPXg8UAdmOI/7Cy6KnpeQD/l2Li+C2BIjgqCSAIBogXjtw/KkbUh1rWtgiTJByQ4bn3BJaaOhPWF1GM= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(520078)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(199003)(19625215002)(101416001)(97736004)(8990500004)(107886002)(110136002)(16236675004)(2501003)(54356999)(19580395003)(19300405004)(77096005)(10090500001)(5002640100001)(15975445007)(33656002)(10290500002)(189998001)(229853001)(66066001)(5003600100002)(40100003)(5004730100002)(106356001)(105586002)(5001960100002)(122556002)(76576001)(74316001)(5005710100001)(86612001)(6116002)(99286002)(50986999)(81156007)(2351001)(86362001)(10400500002)(102836003)(5008740100001)(450100001)(1220700001)(3846002)(586003)(19617315012)(1730700002)(87936001)(1096002)(92566002)(2906002)(2900100001)(790700001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442662C73E3904E73D9B9EFF5C30BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2016 06:28:06.0027 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Subject: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 06:28:13 -0000 --_000_BY2PR03MB442662C73E3904E73D9B9EFF5C30BY2PR03MB442namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up Mitig= ation draft. Changes were: * Simplified by no longer specifying the signed JWT method for return= ing the mitigation information. * Simplified by no longer depending upon publication of a discovery m= etadata document. * Added the "state" token request parameter. * Added examples. * Added John Bradley as an editor. The specification is available at: * http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01= .html -- Mike P.S. This note was also posted at http://self-issued.info/?p=3D1526 and as= @selfissued. --_000_BY2PR03MB442662C73E3904E73D9B9EFF5C30BY2PR03MB442namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

John Bradley and I collaborated to create the second= OAuth 2.0 Mix-Up Mitigation draft.  Changes were:

·       Simplified by no longer specifying the signe= d JWT method for returning the mitigation information.

·       Simplified by no longer depending upon publi= cation of a discovery metadata document.

·       Added the “state” token request parameter.<= /o:p>

·       Added examples.

·       Added John Bradley as an editor.<= /p>

 

The specification is available at:

·       http://tools.ietf.org/html/draft-jones-oa= uth-mix-up-mitigation-01

 

An HTML-formatted version is also available at:=

·       http://self-issued.info/docs/draft= -jones-oauth-mix-up-mitigation-01.html

 

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

 

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

 

--_000_BY2PR03MB442662C73E3904E73D9B9EFF5C30BY2PR03MB442namprd_-- From nobody Wed Jan 20 22:37:38 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A7F1A0083 for ; Wed, 20 Jan 2016 22:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WuV--7zuw5Iq for ; Wed, 20 Jan 2016 22:37:35 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 EFB691A007E for ; Wed, 20 Jan 2016 22:37:34 -0800 (PST) Received: by mail-ob0-x22c.google.com with SMTP id is5so27469053obc.0 for ; Wed, 20 Jan 2016 22:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yAAYAlF+/qQKSw/cihC5EAXuAZXPAvia+s5ahG9I7S0=; b=gYo7va3zmSpC/MhKWKeowdlfrAtMOCL8Cwwj7+btJZ/73reH3ycnX3JmtaOOb+iriZ 4KB/QvGPKElfCz53toX/WGsBJfdRh7+U8uVIwd09bh2mFqOf/IMofLN7FFApzvKhrhkb uFnBLp+A0M8CTe4yiX8Vh/hfGoCMPGokHFZCq9lkrhcZe6medvxfX3XQfyrl/klvexqh D26o5ZsO7n9iiXJtIC65mPvjgUPiO3wQJW5nzabjjakVssQXy51x/mi8tz6SgSZwccHd z9icUrwB6DFrVFryDxTlmTi1rhVWwaTJ+4Upi/CK87gJvg3pbuG070h88lFWk/dBGnvX fJXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yAAYAlF+/qQKSw/cihC5EAXuAZXPAvia+s5ahG9I7S0=; b=RiZe3H4fl2IMznh7yK0zhkamb+m9ABrOWMKJkwbbO+7f6KD+LAqulzdScWUwXfaq0i pWlQyMIVHi3XvJzF0eJ0131lx4iBfMDUVdFTOdeXcevoy7B4NS3zeJwABpr2MsHpJl0U mzjQVtKvbmH4fFwt5QYQe9mWEUXAIBCWLKbkelA/DSaW1e48SKtVpKO87XH12hZym/06 9zc1HzXIDdL7seuohkTP5nXcCBdPukXgGIbgv7nBpEtQSGDnvyYRm+3G5gSuI/p8APFY iaXZGiAfNzV2n5qghPn49r3Mih1BGJVGrjdgKERIEgZ0RSXKYBNqP8+2BEeKYLIPv5RS r0Lg== X-Gm-Message-State: ALoCoQnFXlXkedsFeUudpzuZOEHFY3hBcW7L/E3ECrXDDTrp+CFarYtGc881St+Ga3p4UTjPK0i6Qgf9M7YVfIN5kpFrjn18EJK4pRXXPBSsYxhVvK3RLtw= X-Received: by 10.182.214.40 with SMTP id nx8mr32664488obc.20.1453358254257; Wed, 20 Jan 2016 22:37:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.227.39 with HTTP; Wed, 20 Jan 2016 22:37:14 -0800 (PST) In-Reply-To: <569F915D.8020806@mit.edu> References: <569E2076.2090405@gmx.net> <569F915D.8020806@mit.edu> From: William Denniss Date: Thu, 21 Jan 2016 14:37:14 +0800 Message-ID: To: Justin Richer Content-Type: multipart/alternative; boundary=e89a8ff1c01e7a40bc0529d25671 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 06:37:37 -0000 --e89a8ff1c01e7a40bc0529d25671 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to adopt this, and I agree with Justin's comments. On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer wrote: > +1 > > Inline discovery and pre-configured discovery (ie, .well-known) should at > the very least be compatible and developed together. It's the > pre-configured discovery document that's at the root of the mix-up attack > in the first place. > > -- Justin > > > On 1/19/2016 10:30 PM, Nat Sakimura wrote: > > Just to give more context, at IETF 94, I have done a presentation on > discovery. > > According to the minutes, > > (f) Discovery (Nat) > > Nat explains his document as an example of the work that has= to be done > in the area of discovery, which is a topic that has been ide= ntified > as necessary for interoperability since many years but so fa= r there > was not time to work on it. Mike, John and Nat are working o= n a new > document that describes additional discovery-relevant compon= ents. > > Poll: 19 for / zero against / 4 persons need more informatio= n. > > The document discussed there was > https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a > simple (only 1-page!) but a very powerful document that nudges towards > HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-u= p > attack without introducing the concept of issuer which is not in RFC6749. > It is also good for selecting different endpoints depending on the user > authentication and authorization results and more privacy sensitive than > pre-announced Discovery document. It also allows you to find to which > protected resource endpoint you can use the access token against. > > In the last sentence of the minutes, it talks about "a new document that > describes additional discovery-relevant components". This is > https://tools.ietf.org/html/draft-jones-oauth-discovery-00. It went for > the call for adoption. However, it is only a half of the story. I believe > > https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was > discussed at IETF 94 and had support there should be adopted as well. > > Nat Sakimura > > > > > 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura < sakimura@gmail.com > >: > >> Thanks Hannes. >> >> I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05,= which >> was discussed in Yokohama, and was largely in agreement if my recollecti= on >> is correct. Why is it not in the call for adoption? >> >> >> >> 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig < = >> hannes.tschofenig@gmx.net>: >> >>> Hi all, >>> >>> we have submitted our new charter to the IESG (see >>> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and >>> since some IESG members like to see an updated list of milestones as >>> well. For this reason, based on a suggestion from Barry, we are also >>> starting a call for adoption concurrently with the review of the charte= r >>> text by the IESG. >>> >>> We will post separate mails on the individual documents. Your feedback >>> is important! Please take the time to look at the documents and provide >>> your feedback. >>> >>> Ciao >>> Hannes & Derek >>> >>> _______________________________________________ >>> 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 > > --e89a8ff1c01e7a40bc0529d25671 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to adopt this, and I agree with Justin's comments.<= div class=3D"gmail_extra">
On Wed, Jan 20, 20= 16 at 9:53 PM, Justin Richer <jricher@mit.edu> wrote:
=20 =20 =20
+1

Inline discovery and pre-configured discovery (ie, .well-known) should at the very least be compatible and developed together. It's the pre-configured discovery document that's at the root of the mix-up attack in the first place.

=C2=A0-- Justin


On 1/19/2016 10:30 PM, Nat Sakimura wrote:
=20
Just to give more context, at IETF 94, I have done a presentation on discovery.=C2=A0

According to the minutes,=C2=A0

    (f) Discovery (Nat)
         =20
             Nat explains his document as an example of the work that has t=
o be done
             in the area of discovery, which is a topic that has been ident=
ified
             as necessary for interoperability since many years but so far =
there
             was not time to work on it. Mike, John and Nat are working on =
a new
             document that describes additional discovery-relevant componen=
ts.
         =20
             Poll: 19 for / zero against / 4 persons need more information.=
The document discussed there was https://tools.ietf.o= rg/html/draft-sakimura-oauth-meta-05. This is a simple (only 1-page!) but a very powerful document that nudges towards HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-up attack without introducing the concept of issuer which is not in RFC6749. It is also good for selecting different endpoints depending on the user authentication and authorization results and more privacy sensitive than pre-announced Discovery document. It also allows you to find to which protected resource endpoint you can use the access token against.=C2=A0

In the last sentence of the minutes, it talks about "a new document that describes additional discovery-relevant components". This is=C2=A0https://tools.ietf.org/html/draft-jones-oauth-discovery-00.=C2=A0 It went for the call for adoption. However, it is only a half of the story. I believe=C2=A0https://tools.ietf.org/html/draft-sakimura-oaut= h-meta-05=C2=A0that was discussed at IETF 94 and had support there=C2=A0should be adopt= ed as well.=C2=A0

Nat Sakimura




2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:0= 5 Nat Sakimura <= sakimura@gmail.= com>:
Thanks Hannes.=C2=A0

I did not find=C2=A0https://tools.ietf.org/htm= l/draft-sakimura-oauth-meta-05,=C2=A0which was discussed in Yokohama, and was largely in agreement if my recollection is correct. Why is it not in the call for adoption?=C2=A0



2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) = 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:
Hi all,

we have submitted our new charter to the IESG (see
http://www.ietf.org/ma= il-archive/web/oauth/current/msg15379.html) and
since some IESG members like to see an updated list of milestones as
well. For this reason, based on a suggestion from Barry, we are also
starting a call for adoption concurrently with the review of the charter
text by the IESG.

We will post separate mails on the individual documents. Your feedback
is important! Please take the time to look at the documents and provide
your feedback.

Ciao
Hannes & Derek

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


_______________________________________________
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


--e89a8ff1c01e7a40bc0529d25671-- From nobody Wed Jan 20 23:02:50 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677CB1A00E3 for ; Wed, 20 Jan 2016 23:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpXif_XF23R3 for ; Wed, 20 Jan 2016 23:02:45 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0750.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:750]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928BC1A00E2 for ; Wed, 20 Jan 2016 23:02:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fB5JWxS5vWUtepkZ5SOSPx996SjtK8UkVRx5R7Pqam8=; b=Lnz7IyBwbTAOYKeQ3Qtljso5VEhBjCRL5An+bpHaU45o2t6Ymw1QrXa5OVRQ/8/lO6JzTrfkMYRLotQizpVSCVjz1DZdDQ4y9JFdVHvYzm03o7Dcy+2DCCmhR8W/IkMq4zgS1/VUth01ix9y+qKS3cIiq4EBnatxYPKUBq2aEjY= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 21 Jan 2016 07:02:21 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Thu, 21 Jan 2016 07:02:21 +0000 From: Mike Jones To: William Denniss , Justin Richer Thread-Topic: [OAUTH-WG] Call for Adoption Thread-Index: AQHRUq7PwpSsQC2NpkCHuu6CK/uboJ8DuV2AgAAG9YCAAK43gIABGG0AgAABNnA= Date: Thu, 21 Jan 2016 07:02:19 +0000 Message-ID: References: <569E2076.2090405@gmx.net> <569F915D.8020806@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 282e61f7-242d-49e7-8767-08d32230cede x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:q5BLHskBEre/h6COkOvLJlCTGRVHPn6NhTFga3qvl9Qs48vc/OOKQg987T3OVsMg+bFYNnLPfJnox9hvgnRPrHVF0Msf3HLByRVSKVIbs+SPIe2ZnQkCgkalGLn9QhkkUQXCsRSC8F/WXIHrw+g60Q==; 24:x1aWVFPYZ2CdzEmvXybaRb2bJ6PZ+I0PLeVGY5zmisl/iWGxi4K6wsiyXGhlpmqpdPSqm40Emgflcg7/M/IZrqt/OMseNfNvNbbpz4dodW8= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(479174004)(189002)(199003)(53754006)(24454002)(19625215002)(97736004)(8990500004)(16236675004)(19580405001)(101416001)(54356999)(19580395003)(19300405004)(77096005)(10090500001)(5002640100001)(93886004)(76176999)(33656002)(15975445007)(2950100001)(10290500002)(189998001)(106116001)(66066001)(5003600100002)(40100003)(19609705001)(5004730100002)(106356001)(105586002)(5001960100002)(122556002)(76576001)(74316001)(5005710100001)(86612001)(6116002)(99286002)(4326007)(50986999)(81156007)(86362001)(5001770100001)(10400500002)(102836003)(5008740100001)(1220700001)(3846002)(586003)(19617315012)(2171001)(87936001)(1096002)(92566002)(2906002)(11100500001)(2900100001)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442C2801F09B2B7A103E673F5C30BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2016 07:02:19.7273 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 07:02:48 -0000 --_000_BY2PR03MB442C2801F09B2B7A103E673F5C30BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IHRvIGJlIG5lZ2F0aXZlLCBidXQgSSBkaXNhZ3JlZSB3aXRoIGFkb3B0aW5nIGRyYWZ0LXNh a2ltdXJhLW9hdXRoLW1ldGEuICBXZSBzaG91bGQgZGVmaW5lIGFuZCBwcm9tb3RlIG9uZSBtaXRp Z2F0aW9uIGFwcHJvYWNoIHRvIHRoZSBtaXgtdXAgYXR0YWNrcy4gIEhhdmluZyB0d28gd291bGQg Y29uZnVzZSBpbXBsZW1lbnRlcnMgYW5kIGNhdXNlIGNvbXBhdGliaWxpdHkgcHJvYmxlbXMg4oCT IHJlZHVjaW5nIG92ZXJhbGwgc2VjdXJpdHkuDQoNClRoZSBhcHByb2FjaCBkZWZpbmVkIGluIGRy YWZ0LWpvbmVzLW9hdXRoLW1peC11cC1taXRpZ2F0aW9uIHdhcyBjcmVhdGVkIGluIGNvbGxhYm9y YXRpb24gd2l0aCB0aGUgc2VjdXJpdHkgcmVzZWFyY2hlcnMgd2hvIGlkZW50aWZpZWQgdGhlIHBy b2JsZW1zIGluIHRoZSBmaXJzdCBwbGFjZSwgd2FzIHZpZ29yb3VzbHkgZGlzY3Vzc2VkIGluIHRo ZSBzZWN1cml0eSBtZWV0aW5nIEhhbm5lcyBhbmQgVG9yc3RlbiBoZWxkIGluIERhcm1zdGFkdCwg YW5kIGhhcyBiZWVuIHNpbmNlIHJlZmluZWQgYmFzZWQgb24gc3Vic3RhbnRpYWwgaW5wdXQgZnJv bSB0aGUgd29ya2luZyBncm91cC4gIEFuZCBhdCBsZWFzdCB0aHJlZSBpbXBsZW1lbnRlcnMgaGF2 ZSBhbHJlYWR5IHN0YXRlZCB0aGF0IHRoZXnigJl2ZSBpbXBsZW1lbnRlZCBpdC4gIEnigJltIG5v dCBzYXlpbmcgdGhhdCBpdOKAmXMsIGJ1dCBpZiB0aGVyZSBhcmUgdGhpbmdzIG1pc3Npbmcgb3Ig dGhpbmdzIHRoYXQgbmVlZCB0byBiZSBpbXByb3ZlZCBpbiBvdXIgYXBwcm9hY2gsIHdlIHNob3Vs ZCBkbyBpdCB0aGVyZSwgcmF0aGVyIGludHJvZHVjaW5nIGEgY29tcGV0aW5nIGFwcHJvYWNoLg0K DQpBbHNvLCBzdGFuZGFyZCBPQXV0aCBkZXBsb3ltZW50cyByZWdpc3RlciB0aGUgY2xpZW50IGFu ZCB0aGVuIHVzZSB0aGUgaW5mb3JtYXRpb24gZ2F0aGVyZWQgYXQgcmVnaXN0cmF0aW9uIHRpbWUg Zm9yIHN1YnNlcXVlbnQgcHJvdG9jb2wgaW50ZXJhY3Rpb25zLiAgVGhleSBkbyBub3QgbmVlZCBh bGwgdGhlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gZm9yIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciB0byBiZSByZXRyYW5zbWl0dGVkIGF0IHJ1bnRpbWUuICBUaGUgb2F1dGgtbWV0YSBkcmFm dCBnb2VzIHRvbyBmYXIgaW4gdGhhdCBkaXJlY3Rpb24sIGF0IGxlYXN0IGFzIEkgc2VlIGl0LiAg UmV0dXJuaW5nIHRoaW5ncyB0d28gd2F5cyBjcmVhdGVzIGl0cyBvd24gcHJvYmxlbXMsIGFzIGRp c2N1c3NlZCBpbiB0aGUgRHVwbGljYXRlIEluZm9ybWF0aW9uIEF0dGFja3Mgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgc2VjdGlvbiAoNy4yKSBvZiB0aGUgbWl4LXVwLW1pdGlnYXRpb24gZHJhZnQu DQoNCknigJlsbCBub3RlIHRoYXQgdGhlIG1peC11cC1taXRpZ2F0aW9uIGFwcHJvYWNoIGlzIGNv bXBhdGlibGUgd2l0aCBleGlzdGluZyBwcmFjdGljZSBpbiBib3RoIHN0YXRpYyBhbmQgZHluYW1p YyBtZXRhZGF0YSBkaXNjb3ZlcnkuICBSZXBseWluZyB0byBKdXN0aW7igJlzIGNvbW1lbnQgdGhh dCDigJxJdCdzIHRoZSBwcmUtY29uZmlndXJlZCBkaXNjb3ZlcnkgZG9jdW1lbnQgdGhhdCdzIGF0 IHRoZSByb290IG9mIHRoZSBtaXgtdXAgYXR0YWNrIGluIHRoZSBmaXJzdCBwbGFjZeKAnSDigJMg dGhpcyBpcyBub3QgdGhlIGNhc2UuICBUaGUgYXR0YWNrcyBjYW4gYmUgcGVyZm9ybWVkIHdpdGhv dXQgZWl0aGVyIGRpc2NvdmVyeSBvciBkeW5hbWljIHJlZ2lzdHJhdGlvbi4NCg0KSSB3b3VsZCBi ZSBpbnRlcmVzdGVkIGluIGhlYXJpbmcgYSB0ZWNobmljYWwgZGlzY3Vzc2lvbiBvbiB3aGV0aGVy IHRoZXJlIGFyZSBhc3BlY3RzIG9mIHRoZSBvYXV0aC1tZXRhIGFwcHJvYWNoIHRoYXQgbWl0aWdh dGUgYXNwZWN0cyBvZiB0aGUgYXR0YWNrcyB0aGF0IHRoZSBtaXgtdXAtbWl0aWdhdGlvbiBhcHBy b2FjaCBkb2VzIG5vdC4gIFRoYXQgY291bGQgaGVscCBpbmZvcm0gd2hldGhlciB0aGVyZSBhcmUg YWRkaXRpb25hbCB0aGluZ3Mgd2Ugc2hvdWxkIGFkZCB0byBvciBjaGFuZ2UgaW4gdGhlIG1peC11 cCBkcmFmdC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2lsbGlhbSBEZW5uaXNzDQpTZW50OiBXZWRuZXNkYXks IEphbnVhcnkgMjAsIDIwMTYgMTA6MzcgUE0NClRvOiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1p dC5lZHU+DQpDYzogb2F1dGhAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENhbGwg Zm9yIEFkb3B0aW9uDQoNCisxIHRvIGFkb3B0IHRoaXMsIGFuZCBJIGFncmVlIHdpdGggSnVzdGlu J3MgY29tbWVudHMuDQoNCk9uIFdlZCwgSmFuIDIwLCAyMDE2IGF0IDk6NTMgUE0sIEp1c3RpbiBS aWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQor MQ0KDQpJbmxpbmUgZGlzY292ZXJ5IGFuZCBwcmUtY29uZmlndXJlZCBkaXNjb3ZlcnkgKGllLCAu d2VsbC1rbm93bikgc2hvdWxkIGF0IHRoZSB2ZXJ5IGxlYXN0IGJlIGNvbXBhdGlibGUgYW5kIGRl dmVsb3BlZCB0b2dldGhlci4gSXQncyB0aGUgcHJlLWNvbmZpZ3VyZWQgZGlzY292ZXJ5IGRvY3Vt ZW50IHRoYXQncyBhdCB0aGUgcm9vdCBvZiB0aGUgbWl4LXVwIGF0dGFjayBpbiB0aGUgZmlyc3Qg cGxhY2UuDQoNCiAtLSBKdXN0aW4NCg0KT24gMS8xOS8yMDE2IDEwOjMwIFBNLCBOYXQgU2FraW11 cmEgd3JvdGU6DQpKdXN0IHRvIGdpdmUgbW9yZSBjb250ZXh0LCBhdCBJRVRGIDk0LCBJIGhhdmUg ZG9uZSBhIHByZXNlbnRhdGlvbiBvbiBkaXNjb3ZlcnkuDQoNCkFjY29yZGluZyB0byB0aGUgbWlu dXRlcywNCg0KDQogICAgKGYpIERpc2NvdmVyeSAoTmF0KQ0KDQoNCg0KICAgICAgICAgICAgIE5h dCBleHBsYWlucyBoaXMgZG9jdW1lbnQgYXMgYW4gZXhhbXBsZSBvZiB0aGUgd29yayB0aGF0IGhh cyB0byBiZSBkb25lDQoNCiAgICAgICAgICAgICBpbiB0aGUgYXJlYSBvZiBkaXNjb3ZlcnksIHdo aWNoIGlzIGEgdG9waWMgdGhhdCBoYXMgYmVlbiBpZGVudGlmaWVkDQoNCiAgICAgICAgICAgICBh cyBuZWNlc3NhcnkgZm9yIGludGVyb3BlcmFiaWxpdHkgc2luY2UgbWFueSB5ZWFycyBidXQgc28g ZmFyIHRoZXJlDQoNCiAgICAgICAgICAgICB3YXMgbm90IHRpbWUgdG8gd29yayBvbiBpdC4gTWlr ZSwgSm9obiBhbmQgTmF0IGFyZSB3b3JraW5nIG9uIGEgbmV3DQoNCiAgICAgICAgICAgICBkb2N1 bWVudCB0aGF0IGRlc2NyaWJlcyBhZGRpdGlvbmFsIGRpc2NvdmVyeS1yZWxldmFudCBjb21wb25l bnRzLg0KDQoNCg0KICAgICAgICAgICAgIFBvbGw6IDE5IGZvciAvIHplcm8gYWdhaW5zdCAvIDQg cGVyc29ucyBuZWVkIG1vcmUgaW5mb3JtYXRpb24uDQoNCg0KVGhlIGRvY3VtZW50IGRpc2N1c3Nl ZCB0aGVyZSB3YXMgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9h dXRoLW1ldGEtMDUuIFRoaXMgaXMgYSBzaW1wbGUgKG9ubHkgMS1wYWdlISkgYnV0IGEgdmVyeSBw b3dlcmZ1bCBkb2N1bWVudCB0aGF0IG51ZGdlcyB0b3dhcmRzIEhBVEVPQVMgd2hpY2ggaXMgYXQg dGhlIGNvcmUgb2YgUkVTVGZ1bC1uZXNzLiBJdCBhbHNvIG1pdGlnYXRlcyB0aGUgTWl4LXVwIGF0 dGFjayB3aXRob3V0IGludHJvZHVjaW5nIHRoZSBjb25jZXB0IG9mIGlzc3VlciB3aGljaCBpcyBu b3QgaW4gUkZDNjc0OS4gSXQgaXMgYWxzbyBnb29kIGZvciBzZWxlY3RpbmcgZGlmZmVyZW50IGVu ZHBvaW50cyBkZXBlbmRpbmcgb24gdGhlIHVzZXIgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6 YXRpb24gcmVzdWx0cyBhbmQgbW9yZSBwcml2YWN5IHNlbnNpdGl2ZSB0aGFuIHByZS1hbm5vdW5j ZWQgRGlzY292ZXJ5IGRvY3VtZW50LiBJdCBhbHNvIGFsbG93cyB5b3UgdG8gZmluZCB0byB3aGlj aCBwcm90ZWN0ZWQgcmVzb3VyY2UgZW5kcG9pbnQgeW91IGNhbiB1c2UgdGhlIGFjY2VzcyB0b2tl biBhZ2FpbnN0Lg0KDQpJbiB0aGUgbGFzdCBzZW50ZW5jZSBvZiB0aGUgbWludXRlcywgaXQgdGFs a3MgYWJvdXQgImEgbmV3IGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIGFkZGl0aW9uYWwgZGlzY292 ZXJ5LXJlbGV2YW50IGNvbXBvbmVudHMiLiBUaGlzIGlzIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1qb25lcy1vYXV0aC1kaXNjb3ZlcnktMDAuICBJdCB3ZW50IGZvciB0aGUgY2Fs bCBmb3IgYWRvcHRpb24uIEhvd2V2ZXIsIGl0IGlzIG9ubHkgYSBoYWxmIG9mIHRoZSBzdG9yeS4g SSBiZWxpZXZlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0 aC1tZXRhLTA1IHRoYXQgd2FzIGRpc2N1c3NlZCBhdCBJRVRGIDk0IGFuZCBoYWQgc3VwcG9ydCB0 aGVyZSBzaG91bGQgYmUgYWRvcHRlZCBhcyB3ZWxsLg0KDQpOYXQgU2FraW11cmENCg0KDQoNCg0K MjAxNuW5tDHmnIgyMOaXpSjmsLQpIDEyOjA1IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwu Y29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PjoNClRoYW5rcyBIYW5uZXMuDQoNCkkgZGlk IG5vdCBmaW5kIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0 aC1tZXRhLTA1LCB3aGljaCB3YXMgZGlzY3Vzc2VkIGluIFlva29oYW1hLCBhbmQgd2FzIGxhcmdl bHkgaW4gYWdyZWVtZW50IGlmIG15IHJlY29sbGVjdGlvbiBpcyBjb3JyZWN0LiBXaHkgaXMgaXQg bm90IGluIHRoZSBjYWxsIGZvciBhZG9wdGlvbj8NCg0KDQoNCjIwMTblubQx5pyIMTnml6Uo54Gr KSAyMDozOSBIYW5uZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWls dG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4+Og0KSGkgYWxsLA0KDQp3ZSBoYXZlIHN1Ym1p dHRlZCBvdXIgbmV3IGNoYXJ0ZXIgdG8gdGhlIElFU0cgKHNlZQ0KaHR0cDovL3d3dy5pZXRmLm9y Zy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTUzNzkuaHRtbCkgYW5kDQpzaW5j ZSBzb21lIElFU0cgbWVtYmVycyBsaWtlIHRvIHNlZSBhbiB1cGRhdGVkIGxpc3Qgb2YgbWlsZXN0 b25lcyBhcw0Kd2VsbC4gRm9yIHRoaXMgcmVhc29uLCBiYXNlZCBvbiBhIHN1Z2dlc3Rpb24gZnJv bSBCYXJyeSwgd2UgYXJlIGFsc28NCnN0YXJ0aW5nIGEgY2FsbCBmb3IgYWRvcHRpb24gY29uY3Vy cmVudGx5IHdpdGggdGhlIHJldmlldyBvZiB0aGUgY2hhcnRlcg0KdGV4dCBieSB0aGUgSUVTRy4N Cg0KV2Ugd2lsbCBwb3N0IHNlcGFyYXRlIG1haWxzIG9uIHRoZSBpbmRpdmlkdWFsIGRvY3VtZW50 cy4gWW91ciBmZWVkYmFjaw0KaXMgaW1wb3J0YW50ISBQbGVhc2UgdGFrZSB0aGUgdGltZSB0byBs b29rIGF0IHRoZSBkb2N1bWVudHMgYW5kIHByb3ZpZGUNCnlvdXIgZmVlZGJhY2suDQoNCkNpYW8N Ckhhbm5lcyAmIERlcmVrDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0 aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpP QXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn Pg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_BY2PR03MB442C2801F09B2B7A103E673F5C30BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJNYWxndW4gR290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Tm90IHRvIGJlIG5lZ2F0aXZlLCBi dXQgSSBkaXNhZ3JlZSB3aXRoIGFkb3B0aW5nIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEuJm5i c3A7IFdlIHNob3VsZCBkZWZpbmUgYW5kIHByb21vdGUgb25lIG1pdGlnYXRpb24gYXBwcm9hY2gg dG8gdGhlIG1peC11cCBhdHRhY2tzLiZuYnNwOyBIYXZpbmcNCiB0d28gd291bGQgY29uZnVzZSBp bXBsZW1lbnRlcnMgYW5kIGNhdXNlIGNvbXBhdGliaWxpdHkgcHJvYmxlbXMg4oCTIHJlZHVjaW5n IG92ZXJhbGwgc2VjdXJpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj5UaGUgYXBwcm9hY2ggZGVmaW5lZCBpbiBkcmFmdC1qb25lcy1vYXV0aC1taXgtdXAtbWl0 aWdhdGlvbiB3YXMgY3JlYXRlZCBpbiBjb2xsYWJvcmF0aW9uIHdpdGggdGhlIHNlY3VyaXR5IHJl c2VhcmNoZXJzIHdobyBpZGVudGlmaWVkIHRoZSBwcm9ibGVtcyBpbiB0aGUgZmlyc3QNCiBwbGFj ZSwgd2FzIHZpZ29yb3VzbHkgZGlzY3Vzc2VkIGluIHRoZSBzZWN1cml0eSBtZWV0aW5nIEhhbm5l cyBhbmQgVG9yc3RlbiBoZWxkIGluIERhcm1zdGFkdCwgYW5kIGhhcyBiZWVuIHNpbmNlIHJlZmlu ZWQgYmFzZWQgb24gc3Vic3RhbnRpYWwgaW5wdXQgZnJvbSB0aGUgd29ya2luZyBncm91cC4mbmJz cDsgQW5kIGF0IGxlYXN0IHRocmVlIGltcGxlbWVudGVycyBoYXZlIGFscmVhZHkgc3RhdGVkIHRo YXQgdGhleeKAmXZlIGltcGxlbWVudGVkIGl0LiZuYnNwOyBJ4oCZbQ0KIG5vdCBzYXlpbmcgdGhh dCBpdOKAmXMsIGJ1dCBpZiB0aGVyZSBhcmUgdGhpbmdzIG1pc3Npbmcgb3IgdGhpbmdzIHRoYXQg bmVlZCB0byBiZSBpbXByb3ZlZCBpbiBvdXIgYXBwcm9hY2gsIHdlIHNob3VsZCBkbyBpdCB0aGVy ZSwgcmF0aGVyIGludHJvZHVjaW5nIGEgY29tcGV0aW5nIGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAy MDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+QWxzbywgc3RhbmRhcmQgT0F1dGggZGVwbG95 bWVudHMgcmVnaXN0ZXIgdGhlIGNsaWVudCBhbmQgdGhlbiB1c2UgdGhlIGluZm9ybWF0aW9uIGdh dGhlcmVkIGF0IHJlZ2lzdHJhdGlvbiB0aW1lIGZvciBzdWJzZXF1ZW50IHByb3RvY29sIGludGVy YWN0aW9ucy4mbmJzcDsgVGhleSBkbw0KIG5vdCBuZWVkIGFsbCB0aGUgY29uZmlndXJhdGlvbiBp bmZvcm1hdGlvbiBmb3IgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGJlIHJldHJhbnNtaXR0 ZWQgYXQgcnVudGltZS4mbmJzcDsgVGhlIG9hdXRoLW1ldGEgZHJhZnQgZ29lcyB0b28gZmFyIGlu IHRoYXQgZGlyZWN0aW9uLCBhdCBsZWFzdCBhcyBJIHNlZSBpdC4mbmJzcDsgUmV0dXJuaW5nIHRo aW5ncyB0d28gd2F5cyBjcmVhdGVzIGl0cyBvd24gcHJvYmxlbXMsIGFzIGRpc2N1c3NlZCBpbiB0 aGUgRHVwbGljYXRlDQogSW5mb3JtYXRpb24gQXR0YWNrcyBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBzZWN0aW9uICg3LjIpIG9mIHRoZSBtaXgtdXAtbWl0aWdhdGlvbiBkcmFmdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPknigJlsbCBub3RlIHRoYXQgdGhlIG1p eC11cC1taXRpZ2F0aW9uIGFwcHJvYWNoIGlzIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBwcmFj dGljZSBpbiBib3RoIHN0YXRpYyBhbmQgZHluYW1pYyBtZXRhZGF0YSBkaXNjb3ZlcnkuJm5ic3A7 IFJlcGx5aW5nIHRvIEp1c3RpbuKAmXMgY29tbWVudA0KIHRoYXQg4oCcPC9zcGFuPkl0J3MgdGhl IHByZS1jb25maWd1cmVkIGRpc2NvdmVyeSBkb2N1bWVudCB0aGF0J3MgYXQgdGhlIHJvb3Qgb2Yg dGhlIG1peC11cCBhdHRhY2sgaW4gdGhlIGZpcnN0IHBsYWNlPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDIwNjAiPuKAnSDigJMgdGhpcyBpcyBub3QgdGhlIGNhc2UuJm5ic3A7IFRoZSBhdHRhY2tz IGNhbiBiZSBwZXJmb3JtZWQgd2l0aG91dA0KIGVpdGhlciBkaXNjb3Zlcnkgb3IgZHluYW1pYyBy ZWdpc3RyYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5J IHdvdWxkIGJlIGludGVyZXN0ZWQgaW4gaGVhcmluZyBhIHRlY2huaWNhbCBkaXNjdXNzaW9uIG9u IHdoZXRoZXIgdGhlcmUgYXJlIGFzcGVjdHMgb2YgdGhlIG9hdXRoLW1ldGEgYXBwcm9hY2ggdGhh dCBtaXRpZ2F0ZSBhc3BlY3RzIG9mIHRoZSBhdHRhY2tzIHRoYXQgdGhlDQogbWl4LXVwLW1pdGln YXRpb24gYXBwcm9hY2ggZG9lcyBub3QuJm5ic3A7IFRoYXQgY291bGQgaGVscCBpbmZvcm0gd2hl dGhlciB0aGVyZSBhcmUgYWRkaXRpb25hbCB0aGluZ3Mgd2Ugc2hvdWxkIGFkZCB0byBvciBjaGFu Z2UgaW4gdGhlIG1peC11cCBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw MjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28t Ym9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBPQXV0 aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPldp bGxpYW0gRGVubmlzczxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjAsIDIw MTYgMTA6MzcgUE08YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBSaWNoZXIgJmx0O2pyaWNoZXJAbWl0 LmVkdSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxIHRvIGFkb3B0IHRoaXMsIGFuZCBJIGFncmVlIHdpdGgg SnVzdGluJ3MgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gV2VkLCBKYW4gMjAsIDIwMTYgYXQgOTo1MyBQTSwgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVk dTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mIzQzOzE8YnI+DQo8YnI+DQpJbmxpbmUgZGlzY292ZXJ5IGFuZCBw cmUtY29uZmlndXJlZCBkaXNjb3ZlcnkgKGllLCAud2VsbC1rbm93bikgc2hvdWxkIGF0IHRoZSB2 ZXJ5IGxlYXN0IGJlIGNvbXBhdGlibGUgYW5kIGRldmVsb3BlZCB0b2dldGhlci4gSXQncyB0aGUg cHJlLWNvbmZpZ3VyZWQgZGlzY292ZXJ5IGRvY3VtZW50IHRoYXQncyBhdCB0aGUgcm9vdCBvZiB0 aGUgbWl4LXVwIGF0dGFjayBpbiB0aGUgZmlyc3QgcGxhY2UuPHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPiZuYnNwOy0tIEp1c3Rpbjwv c3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMS8xOS8yMDE2IDEwOjMwIFBNLCBOYXQg U2FraW11cmEgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkp1c3QgdG8gZ2l2ZSBtb3JlIGNvbnRleHQsIGF0IElFVEYgOTQsIEkgaGF2 ZSBkb25lIGEgcHJlc2VudGF0aW9uIG9uIGRpc2NvdmVyeS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWNjb3JkaW5nIHRvIHRoZSBtaW51dGVz LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyAoZikgRGlz Y292ZXJ5IChOYXQpPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7TmF0IGV4cGxhaW5zIGhpcyBkb2N1bWVudCBhcyBhbiBleGFtcGxlIG9mIHRoZSB3b3Jr IHRoYXQgaGFzIHRvIGJlIGRvbmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIHRo ZSBhcmVhIG9mIGRpc2NvdmVyeSwgd2hpY2ggaXMgYSB0b3BpYyB0aGF0IGhhcyBiZWVuIGlkZW50 aWZpZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzIG5lY2Vzc2FyeSBmb3IgaW50 ZXJvcGVyYWJpbGl0eSBzaW5jZSBtYW55IHllYXJzIGJ1dCBzbyBmYXIgdGhlcmU8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdhcyBub3QgdGltZSB0byB3b3JrIG9uIGl0LiBNaWtlLCBK b2huIGFuZCBOYXQgYXJlIHdvcmtpbmcgb24gYSBuZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIGFkZGl0aW9uYWwgZGlzY292ZXJ5LXJlbGV2 YW50IGNvbXBvbmVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7UG9sbDogMTkgZm9yIC8gemVybyBhZ2FpbnN0IC8gNCBwZXJzb25zIG5lZWQgbW9y ZSBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgZG9jdW1lbnQgZGlzY3Vzc2VkIHRoZXJlIHdhcyA8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wNSIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2lt dXJhLW9hdXRoLW1ldGEtMDU8L2E+LiBUaGlzIGlzIGEgc2ltcGxlIChvbmx5IDEtcGFnZSEpIGJ1 dCBhIHZlcnkgcG93ZXJmdWwgZG9jdW1lbnQgdGhhdCBudWRnZXMgdG93YXJkcyBIQVRFT0FTIHdo aWNoIGlzIGF0IHRoZSBjb3JlIG9mIFJFU1RmdWwtbmVzcy4gSXQgYWxzbyBtaXRpZ2F0ZXMgdGhl IE1peC11cCBhdHRhY2sgd2l0aG91dCBpbnRyb2R1Y2luZyB0aGUgY29uY2VwdA0KIG9mIGlzc3Vl ciB3aGljaCBpcyBub3QgaW4gUkZDNjc0OS4gSXQgaXMgYWxzbyBnb29kIGZvciBzZWxlY3Rpbmcg ZGlmZmVyZW50IGVuZHBvaW50cyBkZXBlbmRpbmcgb24gdGhlIHVzZXIgYXV0aGVudGljYXRpb24g YW5kIGF1dGhvcml6YXRpb24gcmVzdWx0cyBhbmQgbW9yZSBwcml2YWN5IHNlbnNpdGl2ZSB0aGFu IHByZS1hbm5vdW5jZWQgRGlzY292ZXJ5IGRvY3VtZW50LiBJdCBhbHNvIGFsbG93cyB5b3UgdG8g ZmluZCB0byB3aGljaCBwcm90ZWN0ZWQNCiByZXNvdXJjZSBlbmRwb2ludCB5b3UgY2FuIHVzZSB0 aGUgYWNjZXNzIHRva2VuIGFnYWluc3QuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhlIGxhc3Qgc2VudGVuY2Ugb2YgdGhlIG1pbnV0ZXMs IGl0IHRhbGtzIGFib3V0ICZxdW90O2EgbmV3IGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIGFkZGl0 aW9uYWwgZGlzY292ZXJ5LXJlbGV2YW50IGNvbXBvbmVudHMmcXVvdDsuIFRoaXMgaXMmbmJzcDs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtZGlz Y292ZXJ5LTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWpvbmVzLW9hdXRoLWRpc2NvdmVyeS0wMDwvYT4uJm5ic3A7DQogSXQgd2VudCBmb3IgdGhl IGNhbGwgZm9yIGFkb3B0aW9uLiBIb3dldmVyLCBpdCBpcyBvbmx5IGEgaGFsZiBvZiB0aGUgc3Rv cnkuIEkgYmVsaWV2ZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDU8L2E+Jm5ic3A7dGhh dCB3YXMgZGlzY3Vzc2VkIGF0IElFVEYNCiA5NCBhbmQgaGFkIHN1cHBvcnQgdGhlcmUmbmJzcDtz aG91bGQgYmUgYWRvcHRlZCBhcyB3ZWxsLiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5hdCBTYWtpbXVyYTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5bm0PC9zcGFu PjE8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5z LXNlcmlmIj7mnIg8L3NwYW4+MjA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3Vu IEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7ml6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuawtDwvc3Bhbj4pDQog MTI6MDUgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21haWwuY29tPC9hPiZndDs6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhh bmtzIEhhbm5lcy4mbmJzcDsgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGRpZCBub3QgZmluZCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA1IiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDU8L2E+ LCZuYnNwO3doaWNoIHdhcyBkaXNjdXNzZWQgaW4gWW9rb2hhbWEsIGFuZCB3YXMgbGFyZ2VseSBp biBhZ3JlZW1lbnQgaWYgbXkgcmVjb2xsZWN0aW9uDQogaXMgY29ycmVjdC4gV2h5IGlzIGl0IG5v dCBpbiB0aGUgY2FsbCBmb3IgYWRvcHRpb24/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5bm0PC9zcGFuPjE8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNl cmlmIj7mnIg8L3NwYW4+MTk8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdv dGhpYyZxdW90OyxzYW5zLXNlcmlmIj7ml6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPueBqzwvc3Bhbj4pDQogMjA6 MzkgSGFubmVzIFRzY2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5p Z0BnbXgubmV0IiB0YXJnZXQ9Il9ibGFuayI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4m Z3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgYWxsLDxicj4NCjxicj4NCndlIGhhdmUgc3VibWl0dGVk IG91ciBuZXcgY2hhcnRlciB0byB0aGUgSUVTRyAoc2VlPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTUzNzkuaHRtbCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0 aC9jdXJyZW50L21zZzE1Mzc5Lmh0bWw8L2E+KSBhbmQ8YnI+DQpzaW5jZSBzb21lIElFU0cgbWVt YmVycyBsaWtlIHRvIHNlZSBhbiB1cGRhdGVkIGxpc3Qgb2YgbWlsZXN0b25lcyBhczxicj4NCndl bGwuIEZvciB0aGlzIHJlYXNvbiwgYmFzZWQgb24gYSBzdWdnZXN0aW9uIGZyb20gQmFycnksIHdl IGFyZSBhbHNvPGJyPg0Kc3RhcnRpbmcgYSBjYWxsIGZvciBhZG9wdGlvbiBjb25jdXJyZW50bHkg d2l0aCB0aGUgcmV2aWV3IG9mIHRoZSBjaGFydGVyPGJyPg0KdGV4dCBieSB0aGUgSUVTRy48YnI+ DQo8YnI+DQpXZSB3aWxsIHBvc3Qgc2VwYXJhdGUgbWFpbHMgb24gdGhlIGluZGl2aWR1YWwgZG9j dW1lbnRzLiBZb3VyIGZlZWRiYWNrPGJyPg0KaXMgaW1wb3J0YW50ISBQbGVhc2UgdGFrZSB0aGUg dGltZSB0byBsb29rIGF0IHRoZSBkb2N1bWVudHMgYW5kIHByb3ZpZGU8YnI+DQp5b3VyIGZlZWRi YWNrLjxicj4NCjxicj4NCkNpYW88YnI+DQpIYW5uZXMgJmFtcDsgRGVyZWs8YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRo IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86 cD48L286cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4N CjxwcmU+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1 dGhAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_BY2PR03MB442C2801F09B2B7A103E673F5C30BY2PR03MB442namprd_-- From nobody Wed Jan 20 23:16:56 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726C11A010F for ; Wed, 20 Jan 2016 23:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzT25lgWwT99 for ; Wed, 20 Jan 2016 23:16:51 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097AA1A0107 for ; Wed, 20 Jan 2016 23:16:51 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id s68so12693607qkh.3 for ; Wed, 20 Jan 2016 23:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=E+LZjQ9zNtoCxbwO2X9Wa6wXx5/h9zFbcVSCJDAuYvs=; b=yVahPN4qU0K9gCq3ZD9NAgmY+tUq23y0aCT2TsSuN1CyJSmS98BnSNluhT2CgsFYUl 5zNhuItSY9S6e1Rw5esRWmqGc4xsVd1OKO0aZGFMUpKIVJXTCxYCbXi1GY81T+NC0k6r XD8P3/0Qj2OIlKx3IFj90tN8vYAWzlliKy3SB6U7ixJF7iHeR0qG5JgnEfNB6lUg2yw2 kQK28vMXjDdC/BP1CaSsU9uCHrbLOYXR2pt30n2vw65smKgxMwQRgvERWdfAYHjR0hNT NODaPn25EAGqhcrlbMefafP18LoJFexcPU9uB2XXjRU+tePDcbGsTWc5Ses1cFBQPILQ xmXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=E+LZjQ9zNtoCxbwO2X9Wa6wXx5/h9zFbcVSCJDAuYvs=; b=LnTFW1xWmtK6VZ1JLJbXJVnBFwz76Gkfk5pHUKA4pv52Vk/S8FYTG3qKyg4OQb7YYx 8blF6Z7rYrlxLzlMrdfmCMMqAxSD5Ou5VJMELKKkmUPWnu9Eux+4h1EUsDGzi1YSN5S5 YIaZzh5MKs4z585royK+H5XWmE6nShF6kHbBD+hMGV9JJ66GKwwwj2WWEgcwVolW81Z/ 1h7pQHLojofAUKGfozF7sv4xX5YjXhepcYvypVSFIb9Nq7MwaCeBV+Fs9Du5braU2iiz 9zxMywsdNwRw8k67Qg+2pS1RPJDLeBch4Ryizacvw62q9yADBkMA1AhxFRnfOCNBcTgc T6Yg== X-Gm-Message-State: ALoCoQmbXa9qlKeN2F79dOcdh1WJBz6q9gAV3dsAOg4Y0zmSoa/eScWo4H5cgSHk+92h8B7ka+LClq4c8rNc6w5qjyPI1d37Jw== X-Received: by 10.55.15.139 with SMTP id 11mr49812883qkp.50.1453360610079; Wed, 20 Jan 2016 23:16:50 -0800 (PST) MIME-Version: 1.0 References: <569E2076.2090405@gmx.net> <569F915D.8020806@mit.edu> In-Reply-To: From: Nat Sakimura Date: Thu, 21 Jan 2016 07:16:40 +0000 Message-ID: To: Mike Jones , William Denniss , Justin Richer Content-Type: multipart/alternative; boundary=001a1147446ee4f9140529d2e22c Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 07:16:54 -0000 --001a1147446ee4f9140529d2e22c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mike. Conversely, I would like to ask why this approach does not work for Mix-up attack. As Nov stated, we in fact have discussed the approach in quite a length back in Yokohama. I really would like to know why it does not work. Besides, for oauth-meta approach, mix-up attack is only one of the thing it solves. Nat Sakimura 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones : > Not to be negative, but I disagree with adopting > draft-sakimura-oauth-meta. We should define and promote one mitigation > approach to the mix-up attacks. Having two would confuse implementers an= d > cause compatibility problems =E2=80=93 reducing overall security. > > > > The approach defined in draft-jones-oauth-mix-up-mitigation was created i= n > collaboration with the security researchers who identified the problems i= n > the first place, was vigorously discussed in the security meeting Hannes > and Torsten held in Darmstadt, and has been since refined based on > substantial input from the working group. And at least three implementer= s > have already stated that they=E2=80=99ve implemented it. I=E2=80=99m not= saying that it=E2=80=99s, > but if there are things missing or things that need to be improved in our > approach, we should do it there, rather introducing a competing approach. > > > > Also, standard OAuth deployments register the client and then use the > information gathered at registration time for subsequent protocol > interactions. They do not need all the configuration information for the > authorization server to be retransmitted at runtime. The oauth-meta draf= t > goes too far in that direction, at least as I see it. Returning things t= wo > ways creates its own problems, as discussed in the Duplicate Information > Attacks security considerations section (7.2) of the mix-up-mitigation > draft. > > > > I=E2=80=99ll note that the mix-up-mitigation approach is compatible with = existing > practice in both static and dynamic metadata discovery. Replying to > Justin=E2=80=99s comment that =E2=80=9CIt's the pre-configured discovery = document that's > at the root of the mix-up attack in the first place=E2=80=9D =E2=80=93 th= is is not the > case. The attacks can be performed without either discovery or dynamic > registration. > > > > I would be interested in hearing a technical discussion on whether there > are aspects of the oauth-meta approach that mitigate aspects of the attac= ks > that the mix-up-mitigation approach does not. That could help inform > whether there are additional things we should add to or change in the > mix-up draft. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William > Denniss > *Sent:* Wednesday, January 20, 2016 10:37 PM > *To:* Justin Richer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Call for Adoption > > > > +1 to adopt this, and I agree with Justin's comments. > > > > On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer wrote: > > +1 > > Inline discovery and pre-configured discovery (ie, .well-known) should at > the very least be compatible and developed together. It's the > pre-configured discovery document that's at the root of the mix-up attack > in the first place. > > -- Justin > > > > On 1/19/2016 10:30 PM, Nat Sakimura wrote: > > Just to give more context, at IETF 94, I have done a presentation on > discovery. > > > > According to the minutes, > > > > (f) Discovery (Nat) > > > > Nat explains his document as an example of the work that has= to be done > > in the area of discovery, which is a topic that has been ide= ntified > > as necessary for interoperability since many years but so fa= r there > > was not time to work on it. Mike, John and Nat are working o= n a new > > document that describes additional discovery-relevant compon= ents. > > > > Poll: 19 for / zero against / 4 persons need more informatio= n. > > > > The document discussed there was > https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a > simple (only 1-page!) but a very powerful document that nudges towards > HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-u= p > attack without introducing the concept of issuer which is not in RFC6749. > It is also good for selecting different endpoints depending on the user > authentication and authorization results and more privacy sensitive than > pre-announced Discovery document. It also allows you to find to which > protected resource endpoint you can use the access token against. > > > > In the last sentence of the minutes, it talks about "a new document that > describes additional discovery-relevant components". This is > https://tools.ietf.org/html/draft-jones-oauth-discovery-00. It went for > the call for adoption. However, it is only a half of the story. I believe > https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was > discussed at IETF 94 and had support there should be adopted as well. > > > > Nat Sakimura > > > > > > > > > > 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura : > > Thanks Hannes. > > > > I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, = which > was discussed in Yokohama, and was largely in agreement if my recollectio= n > is correct. Why is it not in the call for adoption? > > > > > > > > 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig : > > Hi all, > > we have submitted our new charter to the IESG (see > http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and > since some IESG members like to see an updated list of milestones as > well. For this reason, based on a suggestion from Barry, we are also > starting a call for adoption concurrently with the review of the charter > text by the IESG. > > We will post separate mails on the individual documents. Your feedback > is important! Please take the time to look at the documents and provide > your feedback. > > Ciao > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1147446ee4f9140529d2e22c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mike.=C2=A0

Conversely, I would like= to ask why this approach does not work for Mix-up attack.=C2=A0As Nov stated, we in fact have discussed the approach = in quite a length back in Yokohama. I really would like to know why it does= not work.=C2=A0

Besides, for oauth-meta approach, mix-up attack is only one of= the thing it solves.=C2=A0

Nat Sakimura

2016=E5=B9=B41=E6=9C=8821= =E6=97=A5(=E6=9C=A8) 16:02 Mike Jones <Michael.Jones@microsoft.com>:

Not to be negative, but I disagree wi= th adopting draft-sakimura-oauth-meta.=C2=A0 We should define and promote o= ne mitigation approach to the mix-up attacks.=C2=A0 Having two would confuse implementers and cause compatibility problems =E2=80=93 = reducing overall security.

=C2=A0

The approach defined in draft-jones-o= auth-mix-up-mitigation was created in collaboration with the security resea= rchers who identified the problems in the first place, was vigorously discussed in the security meeting Hannes and Torsten= held in Darmstadt, and has been since refined based on substantial input f= rom the working group.=C2=A0 And at least three implementers have already s= tated that they=E2=80=99ve implemented it.=C2=A0 I=E2=80=99m not saying that it=E2=80=99s, but if there are things missing or things th= at need to be improved in our approach, we should do it there, rather intro= ducing a competing approach.

=C2=A0

Also, standard OAuth deployments regi= ster the client and then use the information gathered at registration time = for subsequent protocol interactions.=C2=A0 They do not need all the configuration information for the authorization server to= be retransmitted at runtime.=C2=A0 The oauth-meta draft goes too far in th= at direction, at least as I see it.=C2=A0 Returning things two ways creates= its own problems, as discussed in the Duplicate Information Attacks security considerations section (7.2) of the mix-up-mi= tigation draft.

=C2=A0

I=E2=80=99ll note that the mix-up-mit= igation approach is compatible with existing practice in both static and dy= namic metadata discovery.=C2=A0 Replying to Justin=E2=80=99s comment that =E2=80=9CIt's the pre-configured discovery document that&#= 39;s at the root of the mix-up attack in the first place=E2= =80=9D =E2=80=93 this is not the case.=C2=A0 The attacks can be performed w= ithout either discovery or dynamic registration.

=C2=A0

I would be interested in hearing a te= chnical discussion on whether there are aspects of the oauth-meta approach = that mitigate aspects of the attacks that the mix-up-mitigation approach does not.=C2=A0 That could help inform whether = there are additional things we should add to or change in the mix-up draft.=

=C2=A0

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

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of William Denniss
Sent: Wednesday, January 20, 2016 10:37 PM
To: Justin Richer <jricher@mit.edu>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Call for Adoption

=C2=A0

+1 to adopt this, and I agree with Justin's comm= ents.

=C2=A0

On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer <<= a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>= wrote:

+1

Inline discovery and pre-configured discovery (ie, .well-known) should at t= he very least be compatible and developed together. It's the pre-config= ured discovery document that's at the root of the mix-up attack in the = first place.

=C2=A0-- Justin

=C2=A0<= /p>

On 1/19/2016 10:30 PM, Nat Sakimura wrote:=

Just to give more context, at IETF 94, I have done a= presentation on discovery.=C2=A0

=C2=A0

According to the minutes,=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0 (f) Dis=
covery (Nat)
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Nat explains his docu=
ment as an example of the work that has to be done

=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the area of discovery, =
which is a topic that has been identified


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as necessary for interoper=
ability since many years but so far there


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was not time to work on it=
. Mike, John and Nat are working on a new


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document that describes ad=
ditional discovery-relevant components.


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Poll: 19 for / zero a=
gainst / 4 persons need more information.


=C2=A0


The document discussed there was 
https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a sim=
ple (only 1-page!) but a very powerful document that nudges towards HATEOAS=
 which is at the core of RESTful-ness. It also mitigates the Mix-up attack =
without introducing the concept
 of issuer which is not in RFC6749. It is also good for selecting different=
 endpoints depending on the user authentication and authorization results a=
nd more privacy sensitive than pre-announced Discovery document. It also al=
lows you to find to which protected
 resource endpoint you can use the access token against.=C2=A0

=C2=A0

In the last sentence of the minutes, it talks about = "a new document that describes additional discovery-relevant component= s". This is=C2=A0https://tools.ietf.org/html/draft-jones= -oauth-discovery-00.=C2=A0 It went for the call for adoption. However, it is only a half of the story= . I believe=C2=A0https://tools.ietf.org/html/draft-sakimura-oau= th-meta-05=C2=A0that was discussed at IETF 94 and had support there=C2=A0should be adopted as well.=C2=A0 <= /u>

=C2=A0

Nat Sakimura

=C2=A0

=C2=A0

=C2=A0

=C2=A0

2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura <sakimura@gmail.com>:

Thanks Hannes.=C2=A0

=C2=A0

I did not find=C2=A0https://tools.ietf.o= rg/html/draft-sakimura-oauth-meta-05,=C2=A0which was discussed in Yokoh= ama, and was largely in agreement if my recollection is correct. Why is it not in the call for adoption?=C2=A0

=C2=A0

=C2=A0

=C2=A0

2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:

Hi all,

we have submitted our new charter to the IESG (see
http://www.ietf.org/mail-archive/web/oauth/current/msg1= 5379.html) and
since some IESG members like to see an updated list of milestones as
well. For this reason, based on a suggestion from Barry, we are also
starting a call for adoption concurrently with the review of the charter text by the IESG.

We will post separate mails on the individual documents. Your feedback
is important! Please take the time to look at the documents and provide
your feedback.

Ciao
Hannes & Derek

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

=C2=A0<= /p> 

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


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

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a1147446ee4f9140529d2e22c-- From nobody Wed Jan 20 23:53:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB03A1A026C for ; Wed, 20 Jan 2016 23:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoqYzKQTGigM for ; Wed, 20 Jan 2016 23:53:28 -0800 (PST) Received: from smtp5.umu.se (smtp5.umu.se [130.239.8.142]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9E01A026A for ; Wed, 20 Jan 2016 23:53:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,324,1449529200"; d="asc'?scan'208";a="84736343" X-IPAS-Result: A2CmBACyjaBW/8wN74JeGQEBAQEPAQEBAYJffW0GiFGzfQUFGAqFbQKBewEBAQEBAYELhDQBAQEBAgEBAQEaUQsFCwIBCBguJwslAgQOBQkFh3gDCggBDbw1AQEBAQEBAQMBAQEBAQEBARAIhjqCBoJugk6BZAEBg0mBDwWXBIJ4gWZqiXWERIhejkNig2dqAYVhNAF7AQEB Received: from umu-ex04.ad.umu.se (HELO mail.ad.umu.se) ([130.239.13.204]) by smtp5.umu.se with ESMTP; 21 Jan 2016 08:53:26 +0100 Received: from UMU-EX03.ad.umu.se (2002:82ef:dcb::82ef:dcb) by UMU-EX04.ad.umu.se (2002:82ef:dcc::82ef:dcc) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 21 Jan 2016 08:53:26 +0100 Received: from UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133]) by UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133%24]) with mapi id 15.00.1130.005; Thu, 21 Jan 2016 08:53:14 +0100 From: Roland Hedberg To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation Thread-Index: AQHRVCDIrvTTltSx2EuRmMMV4xE3oA== Date: Thu, 21 Jan 2016 07:53:14 +0000 Message-ID: <303991D4-7ED8-46A6-982A-B41C9DD573FB@adm.umu.se> References: <569E22E1.5010402@gmx.net> <3663C301-FE1B-465C-B8FF-3BBF2F4C0A43@adobe.com> In-Reply-To: <3663C301-FE1B-465C-B8FF-3BBF2F4C0A43@adobe.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.5.2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.239.200.165] Content-Type: multipart/signed; boundary="Apple-Mail=_625A30DD-03EE-43C5-9E15-4C07A6BCC7F7"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 07:53:30 -0000 --Apple-Mail=_625A30DD-03EE-43C5-9E15-4C07A6BCC7F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 for adoption > 21 jan 2016 kl. 07:14 skrev Antonio Sanso : >=20 > +1 for adoption > On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig = wrote: >=20 >> Hi all, >>=20 >> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 >>=20 >> Please let us know by Feb 9th whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >>=20 >> Note: This call is related to the announcement made on the list = earlier >> this month, see >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. = More >> time for analysis is provided due to the complexity of the topic. >>=20 >> Ciao >> Hannes & Derek >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_625A30DD-03EE-43C5-9E15-4C07A6BCC7F7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWoI5hAAoJEMHjX+0KUIOoxl0QAME6TN+5XaYdHeP1AesBXeNE Fq93HKZVU5Ydrtb8Db+wqDkC/IVxyO35loTF7rHKgxYUA5ZTECBZwRUQzP4qCH+m V5osI1Mgx53akIl1brvWUZz4/96sxzsy/h0NJgtueTuc1vLKmGkGzJVdjD8wscGG I19ZGRXihc+/+ovJDZPcopRzVaoSe7v+4kJFSS85rrgDTCpsB7hxiSNml52RWF4b bVoGJUjzQB8FH2NtNvnVyNvmuIm197TEFPrx40CP+0ynFzGG5Z3xMtKR5aa44vZF C2R+irbm6qUy95glbb8xLowcTTi4iN27QIfca+AVUR/707tkakYd1awjHXd2eeuC cPxbd3Y+AApwKsOpUkPF6UsDdc3olW84vKSMs/+JflvhtYIwLcelHYOw9PSZJf2u naqbBp2YCURjjVn/ySjF7QFfQEIwGXr+WbODvMUxIvv1rX4cHn1j8fbjgEyHTA22 rhx7ukBdQ4p41cAryH4TXgvHznLoC3vbytzfIWwDnqtmpwfjIVAgHxJ5tAKU0ni/ yDQkDJU+AES1F/H/IErAGXBkJj8j3snagMGroVHoPEKJxgPoOkBIzXWej6R5zM6q ZJzdYSnidnvRTtPSPbd3oaVmwkj8vL1VdbO0DHaCc4OJClfLCtXCHgVBw59hYnW/ nKayrBrIF14tbXNVn+YF =qUgl -----END PGP SIGNATURE----- --Apple-Mail=_625A30DD-03EE-43C5-9E15-4C07A6BCC7F7-- From nobody Wed Jan 20 23:55:30 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BE71A01E7 for ; Wed, 20 Jan 2016 23:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZqfJ1hkI_hH for ; Wed, 20 Jan 2016 23:55:23 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39B81A0267 for ; Wed, 20 Jan 2016 23:55:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2Ta/NKsrmVxY9G0wGnROqLpePuM9hetZKYUDHpfZTVc=; b=T/8gF1x9aEBX5WbHefApIIFKL3WvU3dBCt+MVx46aZZC9T76P5INWeUJXbffP0fHzzTFBgeWd021Rf028/1TOyglLKGuHyMrukWVkr/Gw7O4NOyUzv6ox3/ajWWTciZD/lV/qeiuG8aBYycII0njN8qxbkF8YJbUd4ncQzdRq/A= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 21 Jan 2016 07:55:03 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Thu, 21 Jan 2016 07:55:03 +0000 From: Mike Jones To: Nat Sakimura , William Denniss , Justin Richer Thread-Topic: [OAUTH-WG] Call for Adoption Thread-Index: AQHRUq7PwpSsQC2NpkCHuu6CK/uboJ8DuV2AgAAG9YCAAK43gIABGG0AgAABNnCAAAnOAIAABVcw Date: Thu, 21 Jan 2016 07:55:03 +0000 Message-ID: References: <569E2076.2090405@gmx.net> <569F915D.8020806@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 6579f31b-9bf4-4045-474b-08d322382bb3 x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:V765I9Tl7VAdVYD5IEBlssEYcQStP6FXgMPoWVm6VXUCgOccCWxGUGUvLNs2TslU2HewJBmgWvBgNIRZQ+zAFVrpSuItC1KtMXUjQNNeEx4PSj/Hn3kVwuFkj9antXvA368mG+g9edphh5sdyxROvQ==; 24:04hed5Y/9jmcspqqzWHQ/hehJrcWIhUcd95w/ZnRhnPJ+PNCrnZQYGM1iDHkKsBZtF+62hYwTS/rMjmlzgDQTWpk44gEOVnXXo+gY04r7mU= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(479174004)(53754006)(377454003)(199003)(24454002)(102836003)(790700001)(2900100001)(40100003)(5003600100002)(8990500004)(19580405001)(86362001)(77096005)(19617315012)(33656002)(93886004)(561944003)(19625215002)(5001960100002)(50986999)(19580395003)(76176999)(19300405004)(16236675004)(99286002)(74316001)(5002640100001)(15975445007)(81156007)(97736004)(122556002)(86612001)(54356999)(11100500001)(66066001)(106116001)(101416001)(92566002)(586003)(2171001)(19609705001)(3846002)(2950100001)(5008740100001)(105586002)(10290500002)(189998001)(1096002)(10090500001)(5001770100001)(6116002)(76576001)(4326007)(10400500002)(5005710100001)(5004730100002)(1220700001)(106356001)(2906002)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442EA7CE4F9728C2E39BBEAF5C30BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2016 07:55:03.3710 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 07:55:29 -0000 --_000_BY2PR03MB442EA7CE4F9728C2E39BBEAF5C30BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgbWVtb3J5IG9mIHRoZSBkaXNjdXNzaW9ucyBvZiB0aGUgb2F1dGgtbWV0YSBkcmFmdCBpbiBZ b2tvaGFtYSB3ZXJlIHRoYXQgbWFueSBwZW9wbGUgZmVsdCB0aGF0IGl0IHdhcyB1bm5lY2Vzc2Fy aWx5IGR5bmFtaWNhbGx5IGR1cGxpY2F0aW5nIGEgbG90IG9mIGluZm9ybWF0aW9uIHRoYXQgdGhl IGNsaWVudCBhbHJlYWR5IGhhZC4gIE1vc3Qgb2YgdXMgdGhhdCB3ZXJlIGF3YXJlIG9mIHRoZSBh dHRhY2tzIHRoZW4gd2VyZSBpbiBmYXZvciBvZiBhIG1vcmUgdGFyZ2V0ZWQsIG1pbmltYWwgYXBw cm9hY2guICBZb3Ugd2VyZSBsaXN0ZW5lZCB0byBpbiBZb2tvaGFtYSwgYnV0IHRoYXQgZGlkbuKA mXQgbmVjZXNzYXJpbHkgbWVhbiB0aGF0IHBlb3BsZSBhZ3JlZWQgd2l0aCB0aGUgYXBwcm9hY2gu ICBQYXJ0aWNpcGFudHMgd2VyZSBhbHJlYWR5IGF3YXJlIG9mIHRoZSBvYXV0aC1tZXRhIHByb3Bv c2FsIGluIERhcm1zdGFkdCBidXQgbm8gb25lIHNwb2tlIHVwIGluIGZhdm9yIG9mIGl0IHRoYXQg SSBjYW4gcmVjYWxsLiAgUmF0aGVyLCBJIHRoaW5rIHBlb3BsZSB3ZXJlIHRoaW5raW5nIHRoYXQg 4oCcbGVzcyBpcyBtb3Jl4oCdLg0KDQpUaGVyZSBoYXZlIGFsc28gYmVlbiBkaXNjdXNzaW9ucyBp biB0aGUgbGFzdCBkYXkgYWJvdXQgaG93IGR5bmFtaWNhbGx5IHJldHVybmluZyBhIHJlc291cmNl IFVSTCwgd2hpY2ggb2F1dGgtbWV0YSBkb2VzLCBpcyBib3RoIHVubmVjZXNzYXJ5IChzaW5jZSB0 aGUgY2xpZW50IGluaXRpYXRlZCB0aGUgcmVzb3VyY2UgYXV0aG9yaXphdGlvbiBhbHJlYWR5IGtu b3dpbmcgd2hhdCByZXNvdXJjZSBpdCB3YW50cyB0byBhY2Nlc3MpIGFuZCBvZnRlbiBwcm9ibGVt YXRpYywgc2luY2UgbWFueSBhdXRob3JpemF0aW9uIHNlcnZlcnMgY2FuIGF1dGhvcml6ZSBhY2Nl c3MgdG8gbXVsdGlwbGUgcmVzb3VyY2VzLiAgSWYgYW55dGhpbmcsIHRoZSBjbGllbnQgc2hvdWxk IGJlIHRlbGxpbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHdoYXQgcmVzb3VyY2UgaXQgd2Fu dHMgdG8gYWNjZXNzIOKAkyBub3QgdGhlIG90aGVyIHdheSBhcm91bmQuDQoNCknigJltIG5vdCBz YXlpbmcgdGhhdCB0aGVyZSBhcmVu4oCZdCBzb21lIGdvb2QgaWRlYXMgaW4gdGhlIG9hdXRoLW1l dGEgZHJhZnQg4oCTIEnigJltIHN1cmUgdGhlcmUgYXJlLCBqdXN0IGFzIHRoZXJlIGFyZSBpbiB0 aGUgYXBwcm9hY2ggZGVzaWduZWQgYnkgdGhlIHBhcnRpY2lwYW50cyBpbiBEYXJtc3RhZHQuICBX aGlsZSBJIHZvbHVudGVlcmVkIHRvIHdyaXRlIHRoZSBmaXJzdCBkcmFmdCBvZiB0aGUgbWl4LXVw LW1pdGlnYXRpb24gYXBwcm9hY2gsIGl0IHJlYWxseSByZWZsZWN0cyBzb21ldGhpbmcgYSBsb3Qg b2YgcGVvcGxlIGhhdmUgYWxyZWFkeSBib3VnaHQgaW50byDigJMgYXMgZXZpZGVuY2VkIGluIHRo ZSBwYXNzaW9uIGluIHRoZSBoaWdoLXZvbHVtZSDigJxNaXgtVXAgQWJvdXQgVGhlIE1peC1VcCBN aXRpZ2F0aW9u4oCdIHRocmVhZCwgYW5kIG5vdCBqdXN0IG15IHBlcnNvbmFsIHByb2plY3QuDQoN CklmIHlvdSB0aGluayB0aGVyZSBhcmUgdGhpbmdzIG1pc3Npbmcgb3Igd3JvbmcgaW4gdGhlIG1p eC11cC1taXRpZ2F0aW9uIGRyYWZ0LCBwbGVhc2Ugc2F5IHdoYXQgdGhleSBhcmUuICBUaGF0IHdp bGwgaGVscCB1cyBxdWlja2x5IGNvbnZlcmdlIG9uIGEgc29sdXRpb24gdGhhdCB3aWxsIHdvcmsg Zm9yIGV2ZXJ5b25lLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgU2luY2VyZWx5LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTmF0IFNha2lt dXJhIFttYWlsdG86c2FraW11cmFAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5 IDIwLCAyMDE2IDExOjE3IFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tPjsgV2lsbGlhbSBEZW5uaXNzIDx3ZGVubmlzc0Bnb29nbGUuY29tPjsgSnVzdGluIFJp Y2hlciA8anJpY2hlckBtaXQuZWR1Pg0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W09BVVRILVdHXSBDYWxsIGZvciBBZG9wdGlvbg0KDQpIaSBNaWtlLg0KDQpDb252ZXJzZWx5LCBJ IHdvdWxkIGxpa2UgdG8gYXNrIHdoeSB0aGlzIGFwcHJvYWNoIGRvZXMgbm90IHdvcmsgZm9yIE1p eC11cCBhdHRhY2suIEFzIE5vdiBzdGF0ZWQsIHdlIGluIGZhY3QgaGF2ZSBkaXNjdXNzZWQgdGhl IGFwcHJvYWNoIGluIHF1aXRlIGEgbGVuZ3RoIGJhY2sgaW4gWW9rb2hhbWEuIEkgcmVhbGx5IHdv dWxkIGxpa2UgdG8ga25vdyB3aHkgaXQgZG9lcyBub3Qgd29yay4NCg0KQmVzaWRlcywgZm9yIG9h dXRoLW1ldGEgYXBwcm9hY2gsIG1peC11cCBhdHRhY2sgaXMgb25seSBvbmUgb2YgdGhlIHRoaW5n IGl0IHNvbHZlcy4NCg0KTmF0IFNha2ltdXJhDQoNCjIwMTblubQx5pyIMjHml6Uo5pyoKSAxNjow MiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbT4+Og0KTm90IHRvIGJlIG5lZ2F0aXZlLCBidXQgSSBkaXNhZ3Jl ZSB3aXRoIGFkb3B0aW5nIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEuICBXZSBzaG91bGQgZGVm aW5lIGFuZCBwcm9tb3RlIG9uZSBtaXRpZ2F0aW9uIGFwcHJvYWNoIHRvIHRoZSBtaXgtdXAgYXR0 YWNrcy4gIEhhdmluZyB0d28gd291bGQgY29uZnVzZSBpbXBsZW1lbnRlcnMgYW5kIGNhdXNlIGNv bXBhdGliaWxpdHkgcHJvYmxlbXMg4oCTIHJlZHVjaW5nIG92ZXJhbGwgc2VjdXJpdHkuDQoNClRo ZSBhcHByb2FjaCBkZWZpbmVkIGluIGRyYWZ0LWpvbmVzLW9hdXRoLW1peC11cC1taXRpZ2F0aW9u IHdhcyBjcmVhdGVkIGluIGNvbGxhYm9yYXRpb24gd2l0aCB0aGUgc2VjdXJpdHkgcmVzZWFyY2hl cnMgd2hvIGlkZW50aWZpZWQgdGhlIHByb2JsZW1zIGluIHRoZSBmaXJzdCBwbGFjZSwgd2FzIHZp Z29yb3VzbHkgZGlzY3Vzc2VkIGluIHRoZSBzZWN1cml0eSBtZWV0aW5nIEhhbm5lcyBhbmQgVG9y c3RlbiBoZWxkIGluIERhcm1zdGFkdCwgYW5kIGhhcyBiZWVuIHNpbmNlIHJlZmluZWQgYmFzZWQg b24gc3Vic3RhbnRpYWwgaW5wdXQgZnJvbSB0aGUgd29ya2luZyBncm91cC4gIEFuZCBhdCBsZWFz dCB0aHJlZSBpbXBsZW1lbnRlcnMgaGF2ZSBhbHJlYWR5IHN0YXRlZCB0aGF0IHRoZXnigJl2ZSBp bXBsZW1lbnRlZCBpdC4gIEnigJltIG5vdCBzYXlpbmcgdGhhdCBpdOKAmXMsIGJ1dCBpZiB0aGVy ZSBhcmUgdGhpbmdzIG1pc3Npbmcgb3IgdGhpbmdzIHRoYXQgbmVlZCB0byBiZSBpbXByb3ZlZCBp biBvdXIgYXBwcm9hY2gsIHdlIHNob3VsZCBkbyBpdCB0aGVyZSwgcmF0aGVyIGludHJvZHVjaW5n IGEgY29tcGV0aW5nIGFwcHJvYWNoLg0KDQpBbHNvLCBzdGFuZGFyZCBPQXV0aCBkZXBsb3ltZW50 cyByZWdpc3RlciB0aGUgY2xpZW50IGFuZCB0aGVuIHVzZSB0aGUgaW5mb3JtYXRpb24gZ2F0aGVy ZWQgYXQgcmVnaXN0cmF0aW9uIHRpbWUgZm9yIHN1YnNlcXVlbnQgcHJvdG9jb2wgaW50ZXJhY3Rp b25zLiAgVGhleSBkbyBub3QgbmVlZCBhbGwgdGhlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24g Zm9yIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBiZSByZXRyYW5zbWl0dGVkIGF0IHJ1bnRp bWUuICBUaGUgb2F1dGgtbWV0YSBkcmFmdCBnb2VzIHRvbyBmYXIgaW4gdGhhdCBkaXJlY3Rpb24s IGF0IGxlYXN0IGFzIEkgc2VlIGl0LiAgUmV0dXJuaW5nIHRoaW5ncyB0d28gd2F5cyBjcmVhdGVz IGl0cyBvd24gcHJvYmxlbXMsIGFzIGRpc2N1c3NlZCBpbiB0aGUgRHVwbGljYXRlIEluZm9ybWF0 aW9uIEF0dGFja3Mgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiAoNy4yKSBvZiB0aGUg bWl4LXVwLW1pdGlnYXRpb24gZHJhZnQuDQoNCknigJlsbCBub3RlIHRoYXQgdGhlIG1peC11cC1t aXRpZ2F0aW9uIGFwcHJvYWNoIGlzIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBwcmFjdGljZSBp biBib3RoIHN0YXRpYyBhbmQgZHluYW1pYyBtZXRhZGF0YSBkaXNjb3ZlcnkuICBSZXBseWluZyB0 byBKdXN0aW7igJlzIGNvbW1lbnQgdGhhdCDigJxJdCdzIHRoZSBwcmUtY29uZmlndXJlZCBkaXNj b3ZlcnkgZG9jdW1lbnQgdGhhdCdzIGF0IHRoZSByb290IG9mIHRoZSBtaXgtdXAgYXR0YWNrIGlu IHRoZSBmaXJzdCBwbGFjZeKAnSDigJMgdGhpcyBpcyBub3QgdGhlIGNhc2UuICBUaGUgYXR0YWNr cyBjYW4gYmUgcGVyZm9ybWVkIHdpdGhvdXQgZWl0aGVyIGRpc2NvdmVyeSBvciBkeW5hbWljIHJl Z2lzdHJhdGlvbi4NCg0KSSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIGhlYXJpbmcgYSB0ZWNobmlj YWwgZGlzY3Vzc2lvbiBvbiB3aGV0aGVyIHRoZXJlIGFyZSBhc3BlY3RzIG9mIHRoZSBvYXV0aC1t ZXRhIGFwcHJvYWNoIHRoYXQgbWl0aWdhdGUgYXNwZWN0cyBvZiB0aGUgYXR0YWNrcyB0aGF0IHRo ZSBtaXgtdXAtbWl0aWdhdGlvbiBhcHByb2FjaCBkb2VzIG5vdC4gIFRoYXQgY291bGQgaGVscCBp bmZvcm0gd2hldGhlciB0aGVyZSBhcmUgYWRkaXRpb25hbCB0aGluZ3Mgd2Ugc2hvdWxkIGFkZCB0 byBvciBjaGFuZ2UgaW4gdGhlIG1peC11cCBkcmFmdC4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1 dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIFdpbGxpYW0gRGVubmlzcw0KU2VudDogV2VkbmVzZGF5LCBK YW51YXJ5IDIwLCAyMDE2IDEwOjM3IFBNDQpUbzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQu ZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+Pg0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpv YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9u DQoNCisxIHRvIGFkb3B0IHRoaXMsIGFuZCBJIGFncmVlIHdpdGggSnVzdGluJ3MgY29tbWVudHMu DQoNCk9uIFdlZCwgSmFuIDIwLCAyMDE2IGF0IDk6NTMgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNo ZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQorMQ0KDQpJbmxpbmUg ZGlzY292ZXJ5IGFuZCBwcmUtY29uZmlndXJlZCBkaXNjb3ZlcnkgKGllLCAud2VsbC1rbm93bikg c2hvdWxkIGF0IHRoZSB2ZXJ5IGxlYXN0IGJlIGNvbXBhdGlibGUgYW5kIGRldmVsb3BlZCB0b2dl dGhlci4gSXQncyB0aGUgcHJlLWNvbmZpZ3VyZWQgZGlzY292ZXJ5IGRvY3VtZW50IHRoYXQncyBh dCB0aGUgcm9vdCBvZiB0aGUgbWl4LXVwIGF0dGFjayBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNCiAt LSBKdXN0aW4NCg0KT24gMS8xOS8yMDE2IDEwOjMwIFBNLCBOYXQgU2FraW11cmEgd3JvdGU6DQpK dXN0IHRvIGdpdmUgbW9yZSBjb250ZXh0LCBhdCBJRVRGIDk0LCBJIGhhdmUgZG9uZSBhIHByZXNl bnRhdGlvbiBvbiBkaXNjb3ZlcnkuDQoNCkFjY29yZGluZyB0byB0aGUgbWludXRlcywNCg0KDQog ICAgKGYpIERpc2NvdmVyeSAoTmF0KQ0KDQoNCg0KICAgICAgICAgICAgIE5hdCBleHBsYWlucyBo aXMgZG9jdW1lbnQgYXMgYW4gZXhhbXBsZSBvZiB0aGUgd29yayB0aGF0IGhhcyB0byBiZSBkb25l DQoNCiAgICAgICAgICAgICBpbiB0aGUgYXJlYSBvZiBkaXNjb3ZlcnksIHdoaWNoIGlzIGEgdG9w aWMgdGhhdCBoYXMgYmVlbiBpZGVudGlmaWVkDQoNCiAgICAgICAgICAgICBhcyBuZWNlc3Nhcnkg Zm9yIGludGVyb3BlcmFiaWxpdHkgc2luY2UgbWFueSB5ZWFycyBidXQgc28gZmFyIHRoZXJlDQoN CiAgICAgICAgICAgICB3YXMgbm90IHRpbWUgdG8gd29yayBvbiBpdC4gTWlrZSwgSm9obiBhbmQg TmF0IGFyZSB3b3JraW5nIG9uIGEgbmV3DQoNCiAgICAgICAgICAgICBkb2N1bWVudCB0aGF0IGRl c2NyaWJlcyBhZGRpdGlvbmFsIGRpc2NvdmVyeS1yZWxldmFudCBjb21wb25lbnRzLg0KDQoNCg0K ICAgICAgICAgICAgIFBvbGw6IDE5IGZvciAvIHplcm8gYWdhaW5zdCAvIDQgcGVyc29ucyBuZWVk IG1vcmUgaW5mb3JtYXRpb24uDQoNCg0KVGhlIGRvY3VtZW50IGRpc2N1c3NlZCB0aGVyZSB3YXMg aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDUu IFRoaXMgaXMgYSBzaW1wbGUgKG9ubHkgMS1wYWdlISkgYnV0IGEgdmVyeSBwb3dlcmZ1bCBkb2N1 bWVudCB0aGF0IG51ZGdlcyB0b3dhcmRzIEhBVEVPQVMgd2hpY2ggaXMgYXQgdGhlIGNvcmUgb2Yg UkVTVGZ1bC1uZXNzLiBJdCBhbHNvIG1pdGlnYXRlcyB0aGUgTWl4LXVwIGF0dGFjayB3aXRob3V0 IGludHJvZHVjaW5nIHRoZSBjb25jZXB0IG9mIGlzc3VlciB3aGljaCBpcyBub3QgaW4gUkZDNjc0 OS4gSXQgaXMgYWxzbyBnb29kIGZvciBzZWxlY3RpbmcgZGlmZmVyZW50IGVuZHBvaW50cyBkZXBl bmRpbmcgb24gdGhlIHVzZXIgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcmVzdWx0 cyBhbmQgbW9yZSBwcml2YWN5IHNlbnNpdGl2ZSB0aGFuIHByZS1hbm5vdW5jZWQgRGlzY292ZXJ5 IGRvY3VtZW50LiBJdCBhbHNvIGFsbG93cyB5b3UgdG8gZmluZCB0byB3aGljaCBwcm90ZWN0ZWQg cmVzb3VyY2UgZW5kcG9pbnQgeW91IGNhbiB1c2UgdGhlIGFjY2VzcyB0b2tlbiBhZ2FpbnN0Lg0K DQpJbiB0aGUgbGFzdCBzZW50ZW5jZSBvZiB0aGUgbWludXRlcywgaXQgdGFsa3MgYWJvdXQgImEg bmV3IGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIGFkZGl0aW9uYWwgZGlzY292ZXJ5LXJlbGV2YW50 IGNvbXBvbmVudHMiLiBUaGlzIGlzIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1q b25lcy1vYXV0aC1kaXNjb3ZlcnktMDAuICBJdCB3ZW50IGZvciB0aGUgY2FsbCBmb3IgYWRvcHRp b24uIEhvd2V2ZXIsIGl0IGlzIG9ubHkgYSBoYWxmIG9mIHRoZSBzdG9yeS4gSSBiZWxpZXZlIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA1IHRo YXQgd2FzIGRpc2N1c3NlZCBhdCBJRVRGIDk0IGFuZCBoYWQgc3VwcG9ydCB0aGVyZSBzaG91bGQg YmUgYWRvcHRlZCBhcyB3ZWxsLg0KDQpOYXQgU2FraW11cmENCg0KDQoNCg0KMjAxNuW5tDHmnIgy MOaXpSjmsLQpIDEyOjA1IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpz YWtpbXVyYUBnbWFpbC5jb20+PjoNClRoYW5rcyBIYW5uZXMuDQoNCkkgZGlkIG5vdCBmaW5kIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA1LCB3 aGljaCB3YXMgZGlzY3Vzc2VkIGluIFlva29oYW1hLCBhbmQgd2FzIGxhcmdlbHkgaW4gYWdyZWVt ZW50IGlmIG15IHJlY29sbGVjdGlvbiBpcyBjb3JyZWN0LiBXaHkgaXMgaXQgbm90IGluIHRoZSBj YWxsIGZvciBhZG9wdGlvbj8NCg0KDQoNCjIwMTblubQx5pyIMTnml6Uo54GrKSAyMDozOSBIYW5u ZXMgVHNjaG9mZW5pZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRz Y2hvZmVuaWdAZ214Lm5ldD4+Og0KSGkgYWxsLA0KDQp3ZSBoYXZlIHN1Ym1pdHRlZCBvdXIgbmV3 IGNoYXJ0ZXIgdG8gdGhlIElFU0cgKHNlZQ0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTUzNzkuaHRtbCkgYW5kDQpzaW5jZSBzb21lIElFU0cg bWVtYmVycyBsaWtlIHRvIHNlZSBhbiB1cGRhdGVkIGxpc3Qgb2YgbWlsZXN0b25lcyBhcw0Kd2Vs bC4gRm9yIHRoaXMgcmVhc29uLCBiYXNlZCBvbiBhIHN1Z2dlc3Rpb24gZnJvbSBCYXJyeSwgd2Ug YXJlIGFsc28NCnN0YXJ0aW5nIGEgY2FsbCBmb3IgYWRvcHRpb24gY29uY3VycmVudGx5IHdpdGgg dGhlIHJldmlldyBvZiB0aGUgY2hhcnRlcg0KdGV4dCBieSB0aGUgSUVTRy4NCg0KV2Ugd2lsbCBw b3N0IHNlcGFyYXRlIG1haWxzIG9uIHRoZSBpbmRpdmlkdWFsIGRvY3VtZW50cy4gWW91ciBmZWVk YmFjaw0KaXMgaW1wb3J0YW50ISBQbGVhc2UgdGFrZSB0aGUgdGltZSB0byBsb29rIGF0IHRoZSBk b2N1bWVudHMgYW5kIHByb3ZpZGUNCnlvdXIgZmVlZGJhY2suDQoNCkNpYW8NCkhhbm5lcyAmIERl cmVrDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5n IGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1 dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWls dG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoDQo= --_000_BY2PR03MB442EA7CE4F9728C2E39BBEAF5C30BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJNYWxndW4gR290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5NeSBt ZW1vcnkgb2YgdGhlIGRpc2N1c3Npb25zIG9mIHRoZSBvYXV0aC1tZXRhIGRyYWZ0IGluIFlva29o YW1hIHdlcmUgdGhhdCBtYW55IHBlb3BsZSBmZWx0IHRoYXQgaXQgd2FzIHVubmVjZXNzYXJpbHkg ZHluYW1pY2FsbHkgZHVwbGljYXRpbmcgYSBsb3Qgb2YgaW5mb3JtYXRpb24NCiB0aGF0IHRoZSBj bGllbnQgYWxyZWFkeSBoYWQuJm5ic3A7IE1vc3Qgb2YgdXMgdGhhdCB3ZXJlIGF3YXJlIG9mIHRo ZSBhdHRhY2tzIHRoZW4gd2VyZSBpbiBmYXZvciBvZiBhIG1vcmUgdGFyZ2V0ZWQsIG1pbmltYWwg YXBwcm9hY2guJm5ic3A7IFlvdSB3ZXJlIGxpc3RlbmVkIHRvIGluIFlva29oYW1hLCBidXQgdGhh dCBkaWRu4oCZdCBuZWNlc3NhcmlseSBtZWFuIHRoYXQgcGVvcGxlIGFncmVlZCB3aXRoIHRoZSBh cHByb2FjaC4mbmJzcDsgUGFydGljaXBhbnRzIHdlcmUgYWxyZWFkeQ0KIGF3YXJlIG9mIHRoZSBv YXV0aC1tZXRhIHByb3Bvc2FsIGluIERhcm1zdGFkdCBidXQgbm8gb25lIHNwb2tlIHVwIGluIGZh dm9yIG9mIGl0IHRoYXQgSSBjYW4gcmVjYWxsLiZuYnNwOyBSYXRoZXIsIEkgdGhpbmsgcGVvcGxl IHdlcmUgdGhpbmtpbmcgdGhhdCDigJxsZXNzIGlzIG1vcmXigJ0uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5UaGVyZSBoYXZlIGFsc28gYmVlbiBkaXNjdXNzaW9u cyBpbiB0aGUgbGFzdCBkYXkgYWJvdXQgaG93IGR5bmFtaWNhbGx5IHJldHVybmluZyBhIHJlc291 cmNlIFVSTCwgd2hpY2ggb2F1dGgtbWV0YSBkb2VzLCBpcyBib3RoIHVubmVjZXNzYXJ5IChzaW5j ZSB0aGUgY2xpZW50DQogaW5pdGlhdGVkIHRoZSByZXNvdXJjZSBhdXRob3JpemF0aW9uIGFscmVh ZHkga25vd2luZyB3aGF0IHJlc291cmNlIGl0IHdhbnRzIHRvIGFjY2VzcykgYW5kIG9mdGVuIHBy b2JsZW1hdGljLCBzaW5jZSBtYW55IGF1dGhvcml6YXRpb24gc2VydmVycyBjYW4gYXV0aG9yaXpl IGFjY2VzcyB0byBtdWx0aXBsZSByZXNvdXJjZXMuJm5ic3A7IElmIGFueXRoaW5nLCB0aGUgY2xp ZW50IHNob3VsZCBiZSB0ZWxsaW5nIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aGF0DQogcmVz b3VyY2UgaXQgd2FudHMgdG8gYWNjZXNzIOKAkyBub3QgdGhlIG90aGVyIHdheSBhcm91bmQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5J4oCZbSBub3Qgc2F5aW5n IHRoYXQgdGhlcmUgYXJlbuKAmXQgc29tZSBnb29kIGlkZWFzIGluIHRoZSBvYXV0aC1tZXRhIGRy YWZ0IOKAkyBJ4oCZbSBzdXJlIHRoZXJlIGFyZSwganVzdCBhcyB0aGVyZSBhcmUgaW4gdGhlIGFw cHJvYWNoIGRlc2lnbmVkIGJ5IHRoZSBwYXJ0aWNpcGFudHMNCiBpbiBEYXJtc3RhZHQuJm5ic3A7 IFdoaWxlIEkgdm9sdW50ZWVyZWQgdG8gd3JpdGUgdGhlIGZpcnN0IGRyYWZ0IG9mIHRoZSBtaXgt dXAtbWl0aWdhdGlvbiBhcHByb2FjaCwgaXQgcmVhbGx5IHJlZmxlY3RzIHNvbWV0aGluZyBhIGxv dCBvZiBwZW9wbGUgaGF2ZSBhbHJlYWR5IGJvdWdodCBpbnRvIOKAkyBhcyBldmlkZW5jZWQgaW4g dGhlIHBhc3Npb24gaW4gdGhlIGhpZ2gtdm9sdW1lIOKAnE1peC1VcCBBYm91dCBUaGUgTWl4LVVw IE1pdGlnYXRpb27igJ0gdGhyZWFkLA0KIGFuZCBub3QganVzdCBteSBwZXJzb25hbCBwcm9qZWN0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SWYgeW91IHRoaW5r IHRoZXJlIGFyZSB0aGluZ3MgbWlzc2luZyBvciB3cm9uZyBpbiB0aGUgbWl4LXVwLW1pdGlnYXRp b24gZHJhZnQsIHBsZWFzZSBzYXkgd2hhdCB0aGV5IGFyZS4mbmJzcDsgVGhhdCB3aWxsIGhlbHAg dXMgcXVpY2tseSBjb252ZXJnZSBvbiBhIHNvbHV0aW9uIHRoYXQNCiB3aWxsIHdvcmsgZm9yIGV2 ZXJ5b25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNpbmNl cmVseSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IE5hdCBTYWtpbXVyYSBbbWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjAsIDIwMTYgMTE6MTcgUE08YnI+DQo8 Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSZndDs7 IFdpbGxpYW0gRGVubmlzcyAmbHQ7d2Rlbm5pc3NAZ29vZ2xlLmNvbSZndDs7IEp1c3RpbiBSaWNo ZXIgJmx0O2pyaWNoZXJAbWl0LmVkdSZndDs8YnI+DQo8Yj5DYzo8L2I+IG9hdXRoQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTWlrZS4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbnZlcnNlbHksIEkgd291 bGQgbGlrZSB0byBhc2sgd2h5IHRoaXMgYXBwcm9hY2ggZG9lcyBub3Qgd29yayBmb3IgTWl4LXVw IGF0dGFjay4mbmJzcDtBcyBOb3Ygc3RhdGVkLCB3ZSBpbiBmYWN0IGhhdmUgZGlzY3Vzc2VkIHRo ZSBhcHByb2FjaCBpbiBxdWl0ZSBhIGxlbmd0aCBiYWNrIGluIFlva29oYW1hLiBJIHJlYWxseSB3 b3VsZCBsaWtlIHRvIGtub3cgd2h5IGl0IGRvZXMgbm90IHdvcmsuJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc2lkZXMsIGZvciBv YXV0aC1tZXRhIGFwcHJvYWNoLCBtaXgtdXAgYXR0YWNrIGlzIG9ubHkgb25lIG9mIHRoZSB0aGlu ZyBpdCBzb2x2ZXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk5hdCBTYWtpbXVyYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5bm0PC9zcGFuPjE8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7mnIg8 L3NwYW4+MjE8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90 OyxzYW5zLXNlcmlmIj7ml6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtN YWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuacqDwvc3Bhbj4pDQogMTY6MDIgTWlrZSBK b25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPk5vdCB0byBiZSBuZWdhdGl2ZSwgYnV0IEkgZGlzYWdy ZWUgd2l0aCBhZG9wdGluZyBkcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLiZuYnNwOyBXZSBzaG91 bGQgZGVmaW5lIGFuZCBwcm9tb3RlDQogb25lIG1pdGlnYXRpb24gYXBwcm9hY2ggdG8gdGhlIG1p eC11cCBhdHRhY2tzLiZuYnNwOyBIYXZpbmcgdHdvIHdvdWxkIGNvbmZ1c2UgaW1wbGVtZW50ZXJz IGFuZCBjYXVzZSBjb21wYXRpYmlsaXR5IHByb2JsZW1zIOKAkyByZWR1Y2luZyBvdmVyYWxsIHNl Y3VyaXR5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRo ZSBhcHByb2FjaCBkZWZpbmVkIGluIGRyYWZ0LWpvbmVzLW9hdXRoLW1peC11cC1taXRpZ2F0aW9u IHdhcyBjcmVhdGVkIGluIGNvbGxhYm9yYXRpb24gd2l0aCB0aGUgc2VjdXJpdHkNCiByZXNlYXJj aGVycyB3aG8gaWRlbnRpZmllZCB0aGUgcHJvYmxlbXMgaW4gdGhlIGZpcnN0IHBsYWNlLCB3YXMg dmlnb3JvdXNseSBkaXNjdXNzZWQgaW4gdGhlIHNlY3VyaXR5IG1lZXRpbmcgSGFubmVzIGFuZCBU b3JzdGVuIGhlbGQgaW4gRGFybXN0YWR0LCBhbmQgaGFzIGJlZW4gc2luY2UgcmVmaW5lZCBiYXNl ZCBvbiBzdWJzdGFudGlhbCBpbnB1dCBmcm9tIHRoZSB3b3JraW5nIGdyb3VwLiZuYnNwOyBBbmQg YXQgbGVhc3QgdGhyZWUgaW1wbGVtZW50ZXJzDQogaGF2ZSBhbHJlYWR5IHN0YXRlZCB0aGF0IHRo ZXnigJl2ZSBpbXBsZW1lbnRlZCBpdC4mbmJzcDsgSeKAmW0gbm90IHNheWluZyB0aGF0IGl04oCZ cywgYnV0IGlmIHRoZXJlIGFyZSB0aGluZ3MgbWlzc2luZyBvciB0aGluZ3MgdGhhdCBuZWVkIHRv IGJlIGltcHJvdmVkIGluIG91ciBhcHByb2FjaCwgd2Ugc2hvdWxkIGRvIGl0IHRoZXJlLCByYXRo ZXIgaW50cm9kdWNpbmcgYSBjb21wZXRpbmcgYXBwcm9hY2guPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+QWxzbywgc3RhbmRhcmQgT0F1dGggZGVwbG95bWVu dHMgcmVnaXN0ZXIgdGhlIGNsaWVudCBhbmQgdGhlbiB1c2UgdGhlIGluZm9ybWF0aW9uIGdhdGhl cmVkIGF0IHJlZ2lzdHJhdGlvbg0KIHRpbWUgZm9yIHN1YnNlcXVlbnQgcHJvdG9jb2wgaW50ZXJh Y3Rpb25zLiZuYnNwOyBUaGV5IGRvIG5vdCBuZWVkIGFsbCB0aGUgY29uZmlndXJhdGlvbiBpbmZv cm1hdGlvbiBmb3IgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHRvIGJlIHJldHJhbnNtaXR0ZWQg YXQgcnVudGltZS4mbmJzcDsgVGhlIG9hdXRoLW1ldGEgZHJhZnQgZ29lcyB0b28gZmFyIGluIHRo YXQgZGlyZWN0aW9uLCBhdCBsZWFzdCBhcyBJIHNlZSBpdC4mbmJzcDsgUmV0dXJuaW5nIHRoaW5n cyB0d28gd2F5cw0KIGNyZWF0ZXMgaXRzIG93biBwcm9ibGVtcywgYXMgZGlzY3Vzc2VkIGluIHRo ZSBEdXBsaWNhdGUgSW5mb3JtYXRpb24gQXR0YWNrcyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBz ZWN0aW9uICg3LjIpIG9mIHRoZSBtaXgtdXAtbWl0aWdhdGlvbiBkcmFmdC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5J4oCZbGwgbm90ZSB0aGF0IHRoZSBt aXgtdXAtbWl0aWdhdGlvbiBhcHByb2FjaCBpcyBjb21wYXRpYmxlIHdpdGggZXhpc3RpbmcgcHJh Y3RpY2UgaW4gYm90aCBzdGF0aWMgYW5kDQogZHluYW1pYyBtZXRhZGF0YSBkaXNjb3ZlcnkuJm5i c3A7IFJlcGx5aW5nIHRvIEp1c3RpbuKAmXMgY29tbWVudCB0aGF0IOKAnDwvc3Bhbj5JdCdzIHRo ZSBwcmUtY29uZmlndXJlZCBkaXNjb3ZlcnkgZG9jdW1lbnQgdGhhdCdzIGF0IHRoZSByb290IG9m IHRoZSBtaXgtdXAgYXR0YWNrIGluIHRoZSBmaXJzdCBwbGFjZTxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDAyMDYwIj7igJ0g4oCTIHRoaXMNCiBpcyBub3QgdGhlIGNhc2UuJm5ic3A7IFRoZSBhdHRh Y2tzIGNhbiBiZSBwZXJmb3JtZWQgd2l0aG91dCBlaXRoZXIgZGlzY292ZXJ5IG9yIGR5bmFtaWMg cmVnaXN0cmF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPkkgd291bGQgYmUgaW50ZXJlc3RlZCBpbiBoZWFyaW5nIGEgdGVjaG5pY2FsIGRpc2N1c3Np b24gb24gd2hldGhlciB0aGVyZSBhcmUgYXNwZWN0cyBvZiB0aGUgb2F1dGgtbWV0YQ0KIGFwcHJv YWNoIHRoYXQgbWl0aWdhdGUgYXNwZWN0cyBvZiB0aGUgYXR0YWNrcyB0aGF0IHRoZSBtaXgtdXAt bWl0aWdhdGlvbiBhcHByb2FjaCBkb2VzIG5vdC4mbmJzcDsgVGhhdCBjb3VsZCBoZWxwIGluZm9y bSB3aGV0aGVyIHRoZXJlIGFyZSBhZGRpdGlvbmFsIHRoaW5ncyB3ZSBzaG91bGQgYWRkIHRvIG9y IGNoYW5nZSBpbiB0aGUgbWl4LXVwIGRyYWZ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJtc2ctZjoxNTIzOTU4MTgwNDgzNDA2NjMxX19NYWls RW5kQ29tcG9zIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjwv YT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzo8YSBo cmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5XaWxsaWFtIERlbm5p c3M8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDIwLCAyMDE2IDEwOjM3IFBN PGJyPg0KPGI+VG86PC9iPiBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hl ckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm9hdXRoQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBD YWxsIGZvciBBZG9wdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mIzQzOzEgdG8gYWRvcHQgdGhpcywgYW5k IEkgYWdyZWUgd2l0aCBKdXN0aW4ncyBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBKYW4gMjAsIDIwMTYgYXQgOTo1MyBQTSwgSnVzdGlu IFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxh bmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mIzQzOzE8YnI+DQo8YnI+DQpJbmxpbmUgZGlzY292ZXJ5IGFuZCBw cmUtY29uZmlndXJlZCBkaXNjb3ZlcnkgKGllLCAud2VsbC1rbm93bikgc2hvdWxkIGF0IHRoZSB2 ZXJ5IGxlYXN0IGJlIGNvbXBhdGlibGUgYW5kIGRldmVsb3BlZCB0b2dldGhlci4gSXQncyB0aGUg cHJlLWNvbmZpZ3VyZWQgZGlzY292ZXJ5IGRvY3VtZW50IHRoYXQncyBhdCB0aGUgcm9vdCBvZiB0 aGUgbWl4LXVwIGF0dGFjayBpbiB0aGUgZmlyc3QgcGxhY2UuPHNwYW4gc3R5bGU9ImNvbG9yOiM4 ODg4ODgiPjxicj4NCjxicj4NCiZuYnNwOy0tIEp1c3Rpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDEvMTkvMjAxNiAxMDozMCBQTSwgTmF0IFNh a2ltdXJhIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkp1c3QgdG8gZ2l2ZSBtb3JlIGNvbnRleHQsIGF0IElFVEYgOTQsIEkgaGF2 ZSBkb25lIGEgcHJlc2VudGF0aW9uIG9uIGRpc2NvdmVyeS4mbmJzcDsNCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFjY29yZGluZyB0byB0aGUgbWlu dXRlcywmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyAo ZikgRGlzY292ZXJ5IChOYXQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7TmF0IGV4cGxhaW5zIGhpcyBkb2N1bWVudCBhcyBhbiBleGFtcGxlIG9mIHRo ZSB3b3JrIHRoYXQgaGFzIHRvIGJlIGRvbmU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGluIHRoZSBhcmVhIG9mIGRpc2NvdmVyeSwgd2hpY2ggaXMgYSB0b3BpYyB0aGF0IGhhcyBiZWVu IGlkZW50aWZpZWQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzIG5lY2Vzc2FyeSBm b3IgaW50ZXJvcGVyYWJpbGl0eSBzaW5jZSBtYW55IHllYXJzIGJ1dCBzbyBmYXIgdGhlcmU8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdhcyBub3QgdGltZSB0byB3b3JrIG9uIGl0LiBN aWtlLCBKb2huIGFuZCBOYXQgYXJlIHdvcmtpbmcgb24gYSBuZXc8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIGFkZGl0aW9uYWwgZGlzY292ZXJ5 LXJlbGV2YW50IGNvbXBvbmVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7UG9sbDogMTkgZm9yIC8gemVybyBhZ2FpbnN0IC8gNCBwZXJzb25zIG5l ZWQgbW9yZSBpbmZvcm1hdGlvbi48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBkb2N1bWVudCBkaXNjdXNzZWQgdGhlcmUgd2FzDQo8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgt bWV0YS0wNSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDU8L2E+LiBUaGlzIGlzIGEgc2ltcGxlIChvbmx5IDEt cGFnZSEpIGJ1dCBhIHZlcnkgcG93ZXJmdWwgZG9jdW1lbnQgdGhhdCBudWRnZXMgdG93YXJkcyBI QVRFT0FTIHdoaWNoIGlzIGF0IHRoZSBjb3JlIG9mIFJFU1RmdWwtbmVzcy4gSXQgYWxzbyBtaXRp Z2F0ZXMgdGhlIE1peC11cCBhdHRhY2sgd2l0aG91dCBpbnRyb2R1Y2luZyB0aGUgY29uY2VwdA0K IG9mIGlzc3VlciB3aGljaCBpcyBub3QgaW4gUkZDNjc0OS4gSXQgaXMgYWxzbyBnb29kIGZvciBz ZWxlY3RpbmcgZGlmZmVyZW50IGVuZHBvaW50cyBkZXBlbmRpbmcgb24gdGhlIHVzZXIgYXV0aGVu dGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcmVzdWx0cyBhbmQgbW9yZSBwcml2YWN5IHNlbnNp dGl2ZSB0aGFuIHByZS1hbm5vdW5jZWQgRGlzY292ZXJ5IGRvY3VtZW50LiBJdCBhbHNvIGFsbG93 cyB5b3UgdG8gZmluZCB0byB3aGljaCBwcm90ZWN0ZWQNCiByZXNvdXJjZSBlbmRwb2ludCB5b3Ug Y2FuIHVzZSB0aGUgYWNjZXNzIHRva2VuIGFnYWluc3QuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIHRoZSBsYXN0IHNlbnRlbmNlIG9m IHRoZSBtaW51dGVzLCBpdCB0YWxrcyBhYm91dCAmcXVvdDthIG5ldyBkb2N1bWVudCB0aGF0IGRl c2NyaWJlcyBhZGRpdGlvbmFsIGRpc2NvdmVyeS1yZWxldmFudCBjb21wb25lbnRzJnF1b3Q7LiBU aGlzIGlzJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpv bmVzLW9hdXRoLWRpc2NvdmVyeS0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1kaXNjb3ZlcnktMDA8L2E+LiZuYnNwOw0KIEl0 IHdlbnQgZm9yIHRoZSBjYWxsIGZvciBhZG9wdGlvbi4gSG93ZXZlciwgaXQgaXMgb25seSBhIGhh bGYgb2YgdGhlIHN0b3J5LiBJIGJlbGlldmUmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wNSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA1 PC9hPiZuYnNwO3RoYXQgd2FzIGRpc2N1c3NlZCBhdCBJRVRGDQogOTQgYW5kIGhhZCBzdXBwb3J0 IHRoZXJlJm5ic3A7c2hvdWxkIGJlIGFkb3B0ZWQgYXMgd2VsbC4mbmJzcDsgPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TmF0IFNha2ltdXJhPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4yMDE2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMm cXVvdDssc2Fucy1zZXJpZiI+5bm0PC9zcGFuPjE8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+MjA8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7ml6U8 L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7 LHNhbnMtc2VyaWYiPuawtDwvc3Bhbj4pDQogMTI6MDUgTmF0IFNha2ltdXJhICZsdDs8YSBocmVm PSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2FraW11cmFAZ21h aWwuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhhbmtzIEhhbm5lcy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgZGlkIG5vdCBmaW5kJm5ic3A7PGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDUiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1 dGgtbWV0YS0wNTwvYT4sJm5ic3A7d2hpY2ggd2FzIGRpc2N1c3NlZA0KIGluIFlva29oYW1hLCBh bmQgd2FzIGxhcmdlbHkgaW4gYWdyZWVtZW50IGlmIG15IHJlY29sbGVjdGlvbiBpcyBjb3JyZWN0 LiBXaHkgaXMgaXQgbm90IGluIHRoZSBjYWxsIGZvciBhZG9wdGlvbj8mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ MjAxNjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNh bnMtc2VyaWYiPuW5tDwvc3Bhbj4xPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1 biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5pyIPC9zcGFuPjE5PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5pelPC9zcGFuPig8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNl cmlmIj7ngas8L3NwYW4+KQ0KIDIwOjM5IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDs8YSBocmVmPSJt YWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmhhbm5lcy50 c2Nob2ZlbmlnQGdteC5uZXQ8L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIGFsbCw8YnI+DQo8YnI+DQp3ZSBoYXZlIHN1Ym1p dHRlZCBvdXIgbmV3IGNoYXJ0ZXIgdG8gdGhlIElFU0cgKHNlZTxicj4NCjxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1Mzc5Lmh0 bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv b2F1dGgvY3VycmVudC9tc2cxNTM3OS5odG1sPC9hPikgYW5kPGJyPg0Kc2luY2Ugc29tZSBJRVNH IG1lbWJlcnMgbGlrZSB0byBzZWUgYW4gdXBkYXRlZCBsaXN0IG9mIG1pbGVzdG9uZXMgYXM8YnI+ DQp3ZWxsLiBGb3IgdGhpcyByZWFzb24sIGJhc2VkIG9uIGEgc3VnZ2VzdGlvbiBmcm9tIEJhcnJ5 LCB3ZSBhcmUgYWxzbzxicj4NCnN0YXJ0aW5nIGEgY2FsbCBmb3IgYWRvcHRpb24gY29uY3VycmVu dGx5IHdpdGggdGhlIHJldmlldyBvZiB0aGUgY2hhcnRlcjxicj4NCnRleHQgYnkgdGhlIElFU0cu PGJyPg0KPGJyPg0KV2Ugd2lsbCBwb3N0IHNlcGFyYXRlIG1haWxzIG9uIHRoZSBpbmRpdmlkdWFs IGRvY3VtZW50cy4gWW91ciBmZWVkYmFjazxicj4NCmlzIGltcG9ydGFudCEgUGxlYXNlIHRha2Ug dGhlIHRpbWUgdG8gbG9vayBhdCB0aGUgZG9jdW1lbnRzIGFuZCBwcm92aWRlPGJyPg0KeW91ciBm ZWVkYmFjay48YnI+DQo8YnI+DQpDaWFvPGJyPg0KSGFubmVzICZhbXA7IERlcmVrPGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpP QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk9BdXRoIG1h aWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v b2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB442EA7CE4F9728C2E39BBEAF5C30BY2PR03MB442namprd_-- From nobody Wed Jan 20 23:56:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24A21A01E7 for ; Wed, 20 Jan 2016 23:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.851 X-Spam-Level: X-Spam-Status: No, score=-5.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wCVc7ccT-r3 for ; Wed, 20 Jan 2016 23:56:29 -0800 (PST) Received: from smtp5.umu.se (smtp5.umu.se [130.239.8.142]) by ietfa.amsl.com (Postfix) with ESMTP id D49881A01D6 for ; Wed, 20 Jan 2016 23:56:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,324,1449529200"; d="asc'?scan'208";a="84736647" X-IPAS-Result: A2CqBACyjaBW/8kN74JeGQEBAQEPAQEBAYJffW0GiFGkVY8rAgUYBYUoSgKBewEBAQEBAYELhDQBAQEBAgEBAQEaBksLBQsCAQYCDgMEAQEBJwMCAiEGCxQJCAIEDgUOBgqHaAMKCAENj1+dFYtTDYNhAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQiGOoIGCIFigQSCTieCGoILOBMYgQ8FhhSBP4cRh19BgniBZgVlgi6DcYNWSoN6iF6Fb4EQg2+DVWKBfxiBUGoBhhUBewEBAQ Received: from umu-ex01.ad.umu.se (HELO mail.ad.umu.se) ([130.239.13.201]) by smtp5.umu.se with ESMTP; 21 Jan 2016 08:56:26 +0100 Received: from UMU-EX03.ad.umu.se (2002:82ef:dcb::82ef:dcb) by UMU-EX01.ad.umu.se (2002:82ef:dc9::82ef:dc9) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 21 Jan 2016 08:56:26 +0100 Received: from UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133]) by UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133%24]) with mapi id 15.00.1130.005; Thu, 21 Jan 2016 08:56:26 +0100 From: Roland Hedberg To: William Denniss Thread-Topic: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps Thread-Index: AQHRVCE6W2/cD1NWZ0Gy875UDhAFWQ== Date: Thu, 21 Jan 2016 07:56:26 +0000 Message-ID: References: <569E2231.1010107@gmx.net> <6ADAA1B5-7EF9-49EA-A3D9-6EFC57275EB9@ve7jtb.com> <9062E913-39FB-4610-80FE-70796CBDEAC1@ve7jtb.com> In-Reply-To: Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail 2.5.2 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.239.200.165] Content-Type: multipart/signed; boundary="Apple-Mail=_10E89C20-BAFA-413D-B9AA-67D8B75984F5"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 07:56:32 -0000 --Apple-Mail=_10E89C20-BAFA-413D-B9AA-67D8B75984F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 for adoption > 21 jan 2016 kl. 07:11 skrev William Denniss : >=20 > I believe this is important work. >=20 > The original OAuth 2 spec left the topic of native apps largely = undefined which is fair enough, the mobile-first revolution had yet to = really take hold and people didn't have much implementation experience = for OAuth on mobile. But we've come a long way since then, we have the = experience now and I think there is a need for leadership in this space, = and that it makes sense for the OAUTH-WG to continue our work and = provide that leadership. >=20 > The risk of not defining a best practice for native apps is dilution = of the open standards =E2=80=93 if everyone implements OAuth differently = for native apps, and RPs have to write IDP-specific code then what is = the point of having OAuth as a standard in the first place? Security is = a major concern as well, there are a lot of ways to mess this up and the = security situation for OAuth in many native apps is not nearly as good = as it could be. >=20 > By providing leadership in the form of a working group document, we = can present community advice with the hope that IDPs and RPs alike will = follow our recommendations, resulting in more interoperability, better = usability and higher security. >=20 > The best part about this spec is that it's pure OAuth! Just wrapped = with some native app specific recommendations for both RPs and IDPs, to = achieve the desired levels of usability and security on mobile. >=20 > I will point out that we have rough consensus and running code. The = rough consensus can be seen from the WG votes, and the sentiment on this = thread (your dissenting opinion notwithstanding). Regarding running = code, my team is in the process of open sourcing libraries that will = implement this best practice to the letter (and the code's already = running, I assure you). The proprietary Google Sign-in and Facebook = Sign-in SDKs are also using in-app browser tabs for OAuth flows in = production today, which I think is further evidence that this is a = viable pattern. >=20 > This document and proposal was never part of the OpenID working group = that you refer to below. >=20 > I'm not saying the document is perfect, and it is definitely in need = of an update! But I'm committed to listening to the community and taking = it forward. Now that the dependencies have launched, and our library = implementations are done, I plan to update the doc with the feedback = from this community, and the lessons we and others have learnt from our = implementations. >=20 > I hope the working group will consider adopting this document. >=20 > Kind Regards, > William >=20 >=20 > On Thu, Jan 21, 2016 at 12:33 PM, Anthony Nadalin = wrote: > This work had many issues in the OpenID WG where it failed why should = this be a WG item here ? The does meet the requirements for = experimental, there is a fine line between informational and = experimental, I would be OK with either but prefer experimental, I = don=E2=80=99t think that this should become a standard. >=20 >=20 >=20 > From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley > Sent: Wednesday, January 20, 2016 12:11 PM > To: Nat Sakimura > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps >=20 >=20 >=20 > PS as you probably suspected I am in favour of moving this forward. >=20 >=20 >=20 >=20 >=20 > On Jan 20, 2016, at 5:08 PM, Nat Sakimura wrote: >=20 >=20 >=20 > +1 for moving this forward. >=20 > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5=E6=9C=A8=E6=9B=9C=E6=97=A5=E3=80=81Jo= hn Bradley=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D= =E3=81=BE=E3=81=97=E3=81=9F: >=20 > Yes more is needed. It was theoretical at that point. Now we have = implementation experience. >=20 >=20 >=20 > On Jan 20, 2016, at 3:38 PM, Brian Campbell = wrote: >=20 >=20 >=20 > There is = https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#appendix-A= which has some mention of SFSafariViewController and Chrome Custom = Tabs. >=20 > Maybe more is needed? >=20 >=20 >=20 > On Wed, Jan 20, 2016 at 10:45 AM, John Bradley = wrote: >=20 > Yes, in July we recommended using the system browser rather than = WebViews. >=20 >=20 >=20 > About that time Apple announced Safari view controller and Google = Chrome custom tabs. The code in the OS is now stable and we have done = a fair amount of testing. >=20 >=20 >=20 > The OIDF will shortly be publishing reference libraries for iOS and = Android to how how to best use View Controllers, and PKCE in native apps = on those platforms. >=20 >=20 >=20 > We do need to update this doc to reflect what we have learned in the = last 6 months. >=20 >=20 >=20 > One problem we do still have is not having someone with Win 10 mobile = experience to help document the best practices for that platform. >=20 > I don=E2=80=99t understand that platform well enough yet to include = anything. >=20 >=20 >=20 > John B. >=20 >=20 >=20 > On Jan 20, 2016, at 12:40 PM, Aaron Parecki wrote: >=20 >=20 >=20 > The section on embedded web views doesn't mention the new iOS 9 = SFSafariViewController which allows apps to display a system browser = within the application. The new API doesn't give the calling application = access to anything inside the browser, so it is acceptable for using = with OAuth flows. I think it's important to mention this new capability = for apps to leverage since it leads to a better user experience. >=20 >=20 >=20 > I'm sure that can be addressed in the coming months if this document = is just the starting point. >=20 >=20 >=20 > I definitely agree that a document about native apps is necessary = since the core leaves a lot of guessing room for an implementation. >=20 >=20 >=20 > For reference, = https://developer.apple.com/library/prerelease/ios/releasenotes/General/Wh= atsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElem= entID_26 >=20 >=20 >=20 > And see the attached screenshot for an example of what it looks like. >=20 >=20 >=20 > >=20 >=20 >=20 > ---- >=20 > Aaron Parecki >=20 > aaronparecki.com >=20 > @aaronpk >=20 >=20 >=20 >=20 >=20 > On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig = wrote: >=20 > Hi all, >=20 > this is the call for adoption of OAuth 2.0 for Native Apps, see > http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ >=20 > Please let us know by Feb 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. >=20 > Note: If you already stated your opinion at the IETF meeting in = Yokohama > then you don't need to re-state your opinion, if you want. >=20 > The feedback at the Yokohama IETF meeting was the following: 16 = persons > for doing the work / 0 persons against / 2 persons need more info >=20 > Ciao > Hannes & Derek >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -- > Nat Sakimura (=3Dnat) >=20 > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_10E89C20-BAFA-413D-B9AA-67D8B75984F5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJWoI8qAAoJEMHjX+0KUIOo5MIQAKB/72y9yq5m3dNpiN/yzppH /TTkYVeHezUSwWMpR40oi53s1/tUSJV70xMOTjnZh2+g8h3XBJ8LPqel6ZHxIqH9 toyWZpiqxqyZbWpEllyxtgbfnHGb0ipqWgFB6J45auJr972v6lW3Adx0t2eFcwkm V5Dn8dNnQKvDlUUgc0B7mvEA9cC3tZFHyMYc8Ey581pB6c71Mn4vVwBQ5Zi4WJj7 VyizjGGiel3kJLyskczKZZWpAxXLGmjEeZJ+nOsgAzJb/zBwGdItyt2NFtyO3b/l s3wCGsS8McZ2hRnDZ4v/nYr5IxtwUV4ILyZVh9GGPi2N11+HX1XYnoXg2x4NYe6A 3OAT0dUXvIgokr1FiVih8tctYrA8AF5ndMJNLJj7Eqc+nXXgNt+5B5QaGwILZM+h xmMWFKMvKFkKGsukC7XpP8whk3vagERz4Y4g3OjB4KpOltba3c3fpp9rbqJoWZgM ltcOjs4JQdH3pZlj8rGHq9mg+pW3KjW3u8iGtrY0NN525EoI6HbP14K6xAYmAcA0 /Sxg/OJZ3jeaOYrbJ1BYMUHskCPgXZLAaO2vkyUSe6a3oOwAiYZmvb744Xmg/j0F bbBHaZcijE8+1RALLdiBUW2Nc6Ck5BPbs1KKOUa8Qx67Edcm6sU2sEKmeCpTXIUd EGHh37asyr2sUTAzMr60 =3ejv -----END PGP SIGNATURE----- --Apple-Mail=_10E89C20-BAFA-413D-B9AA-67D8B75984F5-- From nobody Thu Jan 21 00:04:27 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B361A036C for ; Thu, 21 Jan 2016 00:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQ73JpD_Gc9E for ; Thu, 21 Jan 2016 00:04:19 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::792]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4AAB1A036F for ; Thu, 21 Jan 2016 00:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=g5M8bbQrIBMmBrpm6PC9Cqzk71EbJ8tzxHdcJHgtpVg=; b=O39KkY0V8EKJXOCy3w6sIFDtLovX4WZGoMC71etzAcZjxpA1fCcUv3EePOJ/Z1H57ih3UPVsOJdzhTeiTy9N6X3lMlPf0wWRR0BELn3fvrMLQG+ezrrx1D1BMqO2ltqRcV6LHRNOtYko1q08N2NtGL5uoA4QYa7y7E78c4Ud0Xg= Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 21 Jan 2016 08:04:00 +0000 Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Thu, 21 Jan 2016 08:04:00 +0000 From: Mike Jones To: nov matake Thread-Topic: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation Thread-Index: AdFMSEdeh3slUb5fSSeAYII0TkfznQAVH34AAALUM/AAARo6AAAACUsAAACxt4AAABX4UAAVPkQAAccnsfA= Date: Thu, 21 Jan 2016 08:03:59 +0000 Message-ID: References: <5693F276.8020501@aol.com> <56940CD8.8000701@aol.com> <569411BF.5090500@pingidentity.com> <716CAB07-0512-4A58-9002-18BB05C7129B@gmail.com> In-Reply-To: <716CAB07-0512-4A58-9002-18BB05C7129B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.85.157] x-ms-office365-filtering-correlation-id: 9634aa49-7d42-4abf-3da1-08d322396b92 x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:foK5KKYOWGEFBzyr+FGHHR2UOGrVBUgMFMblLZ3aHBx/anm12EMgyQncpajJgCffhXY5nkEkl7xChZqPA+r3tt0CZNGXo8AVT0rx8iAUqLLi+kaRSS5oLbz+IowhcDGG0Px3/ch6mAf5Hp6jeuOVCQ==; 24:YszxoEUk8y56xZ36F3KU20brCcm5kMd5mkBkdRdg7MbJKevhBYP4+knr3LbAIv/LSVP5NFxX2FjrYE6EL/2lt4iNBDOtNA0pa5Hv5ThM0+o= x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; UriScan:(149059832740258); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; x-forefront-prvs: 08286A0BE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(13464003)(189002)(479174004)(377454003)(199003)(164054003)(24454002)(102836003)(790700001)(2900100001)(40100003)(5003600100002)(8990500004)(19580405001)(1600100001)(86362001)(77096005)(19617315012)(33656002)(93886004)(19625215002)(5001960100002)(50986999)(19580395003)(76176999)(19300405004)(16236675004)(1411001)(99286002)(74316001)(5002640100001)(15975445007)(81156007)(97736004)(15395725005)(122556002)(86612001)(54356999)(5002510100001)(11100500001)(66066001)(101416001)(92566002)(586003)(19609705001)(3846002)(2950100001)(5008740100001)(105586002)(10290500002)(189998001)(1096002)(110136002)(10090500001)(6116002)(76576001)(4326007)(10400500002)(5005710100001)(5004730100002)(1220700001)(106356001)(2906002)(87936001)(15940465004)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4420A5F143FBCCEA01265D8F5C30BY2PR03MB442namprd_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2016 08:04:00.0254 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 08:04:24 -0000 --_000_BY2PR03MB4420A5F143FBCCEA01265D8F5C30BY2PR03MB442namprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29ycnkgdG8gYmUgc2xvdyByZXNwb25kaW5nLCBOb3YuICBJIHdhbnRlZCB0byB3YWl0IHRvIHJl c3BvbmQgdW50aWwgYSBkcmFmdCB3aXRoIHRoZSDigJxzdGF0ZeKAnSB0b2tlbiByZXF1ZXN0IHBh cmFtZXRlciB3YXMgcHVibGlzaGVkLCB3aGljaCBqdXN0IGhhcHBlbmVkLg0KDQpJIHRoaW5rIHRo ZSBvYXV0aC1tZXRhIHNwZWMgc29sdmVzIHNvbWUgb2YgdGhlbSBidXQgbm90IG90aGVycy4gIFRo ZXJlIHdlcmUgYSBidW5jaCBvZiBkaWZmZXJlbnQgYXR0YWNrcyBkaXNjdXNzZWQgYnkgdGhlIHNl Y3VyaXR5IHJlc2VhcmNoZXJzIGluIERhcm1zdGFkdCAoc2VlIHRoZSBub3RlcyBhdCBodHRwczov L2RvY3MuZ29vZ2xlLmNvbS9kb2N1bWVudC9kLzEzNkN6Mml3VUZNZG9LV1pQQ3FaUmhrbWZtSEFs SjZrTTVPeWVYekdwdFU0L2VkaXQjaGVhZGluZz1oLm9kOTJ1bW1kMjJ6cyksIHNvbWUgd2l0aCBp bnRlcmRlcGVuZGVuY2llcyBiZXR3ZWVuIHRoZW0uICBUaGVyZSBhcmUgcmVhc29ucywgZm9yIGlu c3RhbmNlLCBmb3Igc2VuZGluZyB0aGUg4oCcc3RhdGXigJ0gdmFsdWUgdG8gdGhlIHRva2VuIGVu ZHBvaW50IHNvIHRoYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGNhbiBjaGVjayBpdC4gIFRo ZSBtaXRpZ2F0aW9ucyBpbnZvbHZlIHZhbGlkYXRpb25zIGJ5IGJvdGggdGhlIGNsaWVudCBhbmQg dGhlIHNlcnZlciDigJMgbm90IGFsbCBvZiB3aGljaCB0aGUgb2F1dGgtbWV0YSBkcmFmdCBpbmNs dWRlcy4NCg0KQWxzbywgc2VlIHRoZSBjdXJyZW50IGRpc2N1c3Npb24gaW4gdGhlIHRocmVhZCDi gJxbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9u4oCdLiAgSW4gc2hvcnQsIEkgdGhpbmsgdGhl cmUgc2hvdWxkIGJlIG9uZSBzb2x1dGlvbiBhcHByb2FjaCB0aGF0IHdlIHdvcmsgb24gZm9yIHRo aXMsIG5vdCB0d28uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEJlc3Qgd2lzaGVzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBub3YgbWF0YWtlIFttYWlsdG86bWF0YWtlQGdt YWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxMSwgMjAxNiAxMDo0NSBQTQ0KVG86IE1p a2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBIYW5zIFphbmRiZWx0 IDxoemFuZGJlbHRAcGluZ2lkZW50aXR5LmNvbT47IEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hA YW9sLmNvbT47IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAy LjAgTWl4LVVwIE1pdGlnYXRpb24NCg0KSGkgTWlrZSwNCg0KSXNu4oCZdCBOYXTigJlzICJPQXV0 aCBSZXNwb25zZSBNZXRhZGF0YeKAnSBzcGVjIGVub3VnaCB0byBzb2x2ZSB0aG9zZSBpc3N1ZXM/ DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDUu dHh0DQoNCk9uIEphbiAxMiwgMjAxNiwgYXQgMDU6NDAsIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9u ZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4gd3Jv dGU6DQoNClRoZSBzcGVjaWZpY2F0aW9uIGRlc2NyaWJlcyB0aGlzIHZhbGlkYXRpb24gbWV0aG9k IChjb21wYXJpc29uIG9mIHRoZSBpc3N1ZXIgcmVjZWl2ZWQgdG8gdGhlIGlzc3VlciByZWNvcmRl ZCBhdCByZWdpc3RyYXRpb24gdGltZSkgaW4gc3RlcCAyIG9mIFNlY3Rpb24gNCAoVmFsaWRhdGlu ZyB0aGUgUmVzcG9uc2UpLiAgSW4gZmFjdCwgSSBhZGRlZCB0aGlzIGluIHJlc3BvbnNlIHRvIHlv dXIgZmVlZGJhY2sgb24gYW4gZWFybGllciBkcmFmdCwgSGFucy4NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEhhbnMgWmFuZGJlbHQgW21haWx0bzpoemFuZGJlbHRAcGluZ2lk ZW50aXR5LmNvbV0NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxMSwgMjAxNiAxMjozNCBQTQ0KVG86 IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tPj47IEdlb3JnZSBGbGV0Y2hlciA8Z2ZmbGV0Y2hAYW9sLmNvbTxt YWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbT4+OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgTWl4LVVwIE1pdGlnYXRp b24NCg0KSSBkaXNhZ3JlZSB0aGF0IHZhbGlkYXRpbmcgZW5kcG9pbnRzICJhdCB0aGlzIHN0ZXAi ICh3aGljaCByZWZlcnMgdG8gcmlnaHQgYmVmb3JlIG1ha2luZyB0aGUgdG9rZW4gcmVxdWVzdCkg c2hvdWxkIGJlIHRoZSBkZWZhdWx0IHdheSBvZiBoYW5kbGluZyB0aGlzLiBUaGUgdmFzdCBtYWpv cml0eSBvZiBPQXV0aCBjbGllbnQgZGVwbG95bWVudHMgY29ubmVjdGluZyB0byBtb3JlIHRoYW4g b25lIEFTIHdpbGwgaGF2ZSBhIHN0YXRpYyBjb25maWd1cmF0aW9uIG9mIHRoZSBBU2VzIGlzc3Vl ci9lbmRwb2ludCBpbmZvcm1hdGlvbiBhbnlob3cgYW5kIHRoZXkganVzdCBuZWVkIHRvIGNvbmZp cm0gdGhhdCB0aGUgaXNzdWVyIHZhbHVlIHJlY2VpdmVkIGluIHRoZSBhdXRob3JpemF0aW9uIHJl c3BvbnNlIGlzIHRoZSBzYW1lIGlzc3VlciBhcyB0aGF0IHRoZSByZXF1ZXN0IHdhcyBzZW50IHRv Lg0KDQpIYW5zLg0KDQpPbiAxLzExLzE2IDE6MTQgUE0sIE1pa2UgSm9uZXMgd3JvdGU6DQoNCkNv cnJlY3QNCg0KKkZyb206Kkdlb3JnZSBGbGV0Y2hlciBbbWFpbHRvOmdmZmxldGNoQGFvbC5jb21d DQoqU2VudDoqIE1vbmRheSwgSmFudWFyeSAxMSwgMjAxNiAxMjoxMyBQTQ0KKlRvOiogTWlrZSBK b25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20+Pjsgb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KKlN1 YmplY3Q6KiBSZTogW09BVVRILVdHXSBPQXV0aCAyLjAgTWl4LVVwIE1pdGlnYXRpb24NCg0KU28g anVzdCB0byBtYWtlIHN1cmUgSSB1bmRlcnN0YW5kLi4uDQoNClRoaXMgc3BlY2lmaWNhdGlvbiBy ZXF1aXJlcyB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXINCnRvIGFu IHN1Y2Nlc3NmdWwgL2F1dGhvcml6ZSBjYWxsIHRvIHBhc3MgYmFjayBjb2RlPSwgc3RhdGU9IGFu ZCBqd3Q9ICg/KQ0Kb3IgaW5kaXZpZHVhbGx5IGlzcz0gYW5kIGF1ZD0gYXMgVVJMIHBhcmFtZXRl cnMgb24gdGhlIDMwMiB0byB0aGUNCnJlZGlyZWN0X3VybC4gVGhpcyB3YXksIGJlZm9yZSB0aGUg Y2xpZW50IGlzc3VlcyBhIGNhbGwgdG8gdGhlIC90b2tlbg0KZW5kcG9pbnQgKHdpdGggdGhlIGNv ZGUpLCBpdCBjYW4gdmVyaWZ5IHRoYXQgdGhlIHRva2VuIGVuZHBvaW50IGlzIGNvcnJlY3QuDQoN CklmIHRoZSBjbGllbnQgZG9lc24ndCB2YWxpZGF0ZSB0aGUgZW5kcG9pbnRzIGF0IHRoaXMgc3Rl cCwgdGhlbiBpdCBjb3VsZA0KZGlzY2xvc2UgaXQncyBzZWNyZXQgdG8gYSBtYWxpY2lvdXMgZW5k cG9pbnQuIENvcnJlY3Q/DQoNClRoYW5rcywNCkdlb3JnZQ0KDQpPbiAxLzExLzE2IDI6NTkgUE0s IE1pa2UgSm9uZXMgd3JvdGU6DQoNCiAgIFRoZSBhbHRlcm5hdGl2ZXMgZm9yIHRoZSBjb2RlIGZs b3cgYXJlIHRvIHJldHVybiB0aGVtIGVpdGhlciBpbiBhDQogICBuZXcgSldUIGFkZGVkIHRvIHRo ZSByZXBseSBjb250YWluaW5nIHRoZW0gaW4gdGhlICJpc3MiIGFuZCAiYXVkIg0KICAgY2xhaW1z IG9yIHRvIHJldHVybiB0aGVtIGluIG5ldyBpbmRpdmlkdWFsICJjbGllbnRfaWQiIGFuZCAiaXNz Ig0KICAgYXV0aG9yaXphdGlvbiByZXNwb25zZSBwYXJhbWV0ZXJzLiAgQm90aCBhbHRlcm5hdGl2 ZXMgYXJlIGRlc2NyaWJlZA0KICAgaW4gdGhlIGRyYWZ0LiAgSSdtIHN1cmUgdGhhdCB3ZSdsbCBu b3cgYmUgaGF2aW5nIGEgZ29vZCBlbmdpbmVlcmluZw0KICAgZGlzY3Vzc2lvbiBvbiB0aGUgdHJh ZGVvZmZzIGJldHdlZW4gdGhlIGFsdGVybmF0aXZlcy4sDQoNCiAgIEluIGEgc2VwYXJhdGUgZHJh ZnQsIEpvaG4gQnJhZGxleSB3aWxsIHNob3J0bHkgYWxzbyBiZSBkZXNjcmliaW5nDQogICB0aGUg cG9zc2liaWxpdHkgb2Ygc2VjdXJpbmcgdGhlICJzdGF0ZSIgdmFsdWUgdXNpbmcgYSAic3RhdGVf aGFzaCINCiAgIHZhbHVlIHRoYXQgd29ya3MgaW4gYSB3YXkgdGhhdCdzIHNpbWlsYXIgdG8gaG93 ICJhdF9oYXNoIiBhbmQNCiAgICJjX2hhc2giIHNlY3VyZSB0aGUgImFjY2Vzc190b2tlbiIgYW5k ICJjb2RlIiB2YWx1ZXMgaW4gQ29ubmVjdC4NCiAgIFRoaXMgd291bGQgYmUgYW4gYWx0ZXJuYXRp dmUgbWVhbnMgb2YgYmluZGluZyB0aGUgYXV0aG9yaXphdGlvbg0KICAgcmVxdWVzdCBhbmQgcmVz cG9uc2UgdG8gdGhlIHNlc3Npb24gLSBhY2NvbXBsaXNoaW5nIHRoZSBzYW1lIHRoaW5nDQogICB0 aGF0IHRoZSBDb25uZWN0ICJub25jZSIgZG9lcy4NCg0KICAgV2hpbGUgSSBmdWxseSBnZXQgdGhh dCBzb21lIE9BdXRoIGltcGxlbWVudGF0aW9ucyB3YW50IHRvIGF2b2lkDQogICBoYXZpbmcgdG8g aGF2ZSBjcnlwdG8sIGl0IHNlZW1zIGxpa2UgYXQgbGVhc3Qgc3VwcG9ydCBmb3INCiAgIGNyeXB0 b2dyYXBoaWMgaGFzaGluZyAoU0hBLTI1NiwgZXRjLikgbWF5IGJlIG5lY2Vzc2FyeSB0byBtaXRp Z2F0ZQ0KICAgc29tZSBvZiB0aGVzZSBhdHRhY2tzIChhdCBsZWFzdCBmb3IgY2xpZW50cyB0aGF0 IHVzZSBtb3JlIHRoYW4gb25lDQogICBhdXRob3JpemF0aW9uIHNlcnZlcikuDQoNCiAgIFRoZSBv dGhlciBpbXBvcnRhbnQgZW5naW5lZXJpbmcgZGlzY3Vzc2lvbiBJIGtub3cgd2UncmUgZ29pbmcg dG8NCiAgIGhhdmUgaXMgd2hldGhlciwgd2hlbiBhbiBPQXV0aCBwcm9maWxlIGFscmVhZHkgcmV0 dXJucyB0aGUNCiAgIGluZm9ybWF0aW9uIG5lZWRlZCBmb3IgdGhlIG1pdGlnYXRpb24sIHdoZXRo ZXIgd2Ugd2FudCB0byBzcGVjaWZ5DQogICB0aGF0IHRoZSBjbGllbnQgb2J0YWluIGl0IGZyb20g dGhlIGV4aXN0aW5nIGxvY2F0aW9uLCBvciB3aGV0aGVyIHRvDQogICBhbHNvIHJldHVybiBpdCBp biBhIGR1cGxpY2F0ZSBsb2NhdGlvbi4gIEknbGwgbm90ZSB0aGF0IE9wZW5JRA0KICAgQ29ubmVj dCBhbHJlYWR5IHJldHVybnMgdGhlIGNsaWVudCBJRCBhbmQgaXNzdWVyIGZvciB0aGUgZmxvd3Mg dGhhdA0KICAgcmV0dXJuIGFuIElEIFRva2VuIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNl LCBzbyB0aGlzIGlzbid0IGENCiAgIGh5cG90aGV0aWNhbCBxdWVzdGlvbi4NCg0KICAgRmluYWxs eSwgSSBrbm93IHRoYXQgd2UnbGwgbmVlZCB0byBkaXNjdXNzIHRoZSBpbXBhY3Qgb2YNCiAgIGN1 dC1hbmQtcGFzdGUgYXR0YWNrcyB3aGVuIHRoZSBpc3N1ZXIgYW5kIGNsaWVudCBJRCBhcmUgcmV0 dXJuZWQgYXMNCiAgIGluZGl2aWR1YWwgYXV0aG9yaXphdGlvbiByZXNwb25zZSBwYXJhbWV0ZXJz IHRoYXQgYXJlIG5vdA0KICAgY3J5cHRvZ3JhcGhpY2FsbHkgYm91bmQgdG8gdGhlIHJlc3Qgb2Yg dGhlIHJlc3BvbnNlLiAgVGhlDQogICBjdXQtYW5kLXBhc3RlIGF0dGFjayB0aGF0IHJldHVybmlu ZyB0aGUgaXNzdWVyIGFuZCBjbGllbnRfaWQgdmFsdWVzDQogICBhcyBzZXBhcmF0ZSBwYXJhbWV0 ZXJzIGVuYWJsZXMsIGV2ZW4gd2hlbiBzdGF0ZV9oYXNoIG9yIG5vbmNlIGlzDQogICB1c2VkLCBp cyBmb3IgdGhlIGF0dGFja2VyIHRvIGNhcHR1cmUgdGhlIGxlZ2l0aW1hdGUgcmVzcG9uc2UNCiAg IGNvbnRhaW5pbmcgImlzcyIgYW5kICJjbGllbnRfaWQiIHJlc3VsdHMgYW5kIHN1YnN0aXR1dGUg ZGlmZmVyZW50DQogICB2YWx1ZXMgZm9yIHRoZXNlIGZpZWxkcywgdGhlbiBwb3N0IHRoYXQgYWx0 ZXJlZCByZXNwb25zZSB0byB0aGUNCiAgIGxlZ2l0aW1hdGUgY2xpZW50LiAgVGhlIHN0YXRlIGFu ZC9vciBub25jZSB2YWx1ZXMgYXJlIHByb3RlY3RlZA0KICAgYWdhaW5zdCBzdWJzdGl0dXRpb24g YnV0ICJpc3MiIGFuZCAiY2xpZW50X2lkIiBhcmUgbm90Lg0KDQogICBBbmQgeWVzLCBJIGFic29s dXRlbHkgYWdyZWUgdGhhdCBnb29kIGV4YW1wbGVzIGFyZSBlc3NlbnRpYWwuDQogICBUaGF0J3Mg aGlnaCBvbiBteSBsaXN0IGZvciB0aGUgLTAxIHZlcnNpb24uDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhhbmtzIGENCiAg IGJ1bmNoLA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KICAgKkZyb206Kkdlb3JnZSBGbGV0Y2hlciBbbWFp bHRvOmdmZmxldGNoQGFvbC5jb21dDQogICAqU2VudDoqIE1vbmRheSwgSmFudWFyeSAxMSwgMjAx NiAxMDoyMSBBTQ0KICAgKlRvOiogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+Pg0KICAgPG1haWx0bzpNaWNo YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0 Zi5vcmc+DQogICA8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KICAgKlN1YmplY3Q6KiBSZTogW09B VVRILVdHXSBPQXV0aCAyLjAgTWl4LVVwIE1pdGlnYXRpb24NCg0KICAgVGhhbmtzIE1pa2UuIE9u ZSBxdWVzdGlvbiBhZnRlciByZWFkaW5nIGFib3V0IHRoZSBkaWZmZXJlbnQgYXR0YWNrDQogICB2 ZWN0b3JzIGFuZCB0aGlzIHNwZWMuLi4NCg0KICAgSG93IGFyZSB0aGUgJ2lzcycgYW5kICdhdWQn IHZhbHVlcyByZXR1cm5lZCB3aXRoIHRoZSAnY29kZScgYW5kDQogICAnc3RhdGUnIHBhcmFtZXRl cnMuIEl0IHNlZW1zIHRoZSBjbGllbnQgbmVlZHMgdG8gdmVyaWZ5IHRoZQ0KICAgZW5kcG9pbnRz IGJlZm9yZSBtYWtpbmcgdGhlIHJlcXVlc3QgdG8gZXhjaGFuZ2UgdGhlIGNvZGUgZm9yIGENCiAg IHRva2VuLiBJZiB0aGUgY2xpZW50IGlzIHVzaW5nIHRoZSBkZWZhdWx0IE9BdXRoMiBjbGllbnRf aWQgYW5kDQogICBjbGllbnRfc2VjcmV0IHRoZXNlIHZhbHVlcyB3aWxsIGJlIHNlbnQgdG8gdGhl IG1hbGljaW91cyBlbmRwb2ludCBpZg0KICAgdGhlIGNsaWVudCBjYW4ndCB2ZXJpZnkgdGhlIGVu ZHBvaW50cyBiZWZvcmUgaGFuZC4NCg0KICAgQWxzbywgaXQgd291bGQgYmUgbmljZSB0byBhZGQg c29tZSBub24tbm9ybWF0aXZlIGV4YW1wbGVzIHRvIHRoZSBzcGVjLg0KDQogICBUaGFua3MsDQog ICBHZW9yZ2UNCg0KICAgT24gMS8xMS8xNiA0OjI3IEFNLCBNaWtlIEpvbmVzIHdyb3RlOg0KDQog ICAgICAgWWVzdGVyZGF5IEhhbm5lcyBUc2Nob2ZlbmlnIGFubm91bmNlZCBhbiBPQXV0aCBTZWN1 cml0eSBBZHZpc29yeQ0KICAgICAgIG9uIEF1dGhvcml6YXRpb24gU2VydmVyIE1peC1VcA0KICAg ICAgIDxodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL29hdXRoL0pJVnhGQkdz SkJWdG03bGp3SmhQVW0zRnItdz4uDQogICAgICAgVGhpcyBub3RlIGFubm91bmNlcyB0aGUgcHVi bGljYXRpb24gb2YgdGhlIHN0cmF3bWFuIE9BdXRoIDIuMA0KICAgICAgIE1peC1VcCBNaXRpZ2F0 aW9uIGRyYWZ0IGhlIG1lbnRpb25lZCB0aGF0IG1pdGlnYXRlcyB0aGUgYXR0YWNrcw0KICAgICAg IGNvdmVyZWQgaW4gdGhlIGFkdmlzb3J5LiAgVGhlIGFic3RyYWN0IG9mIHRoZSBzcGVjaWZpY2F0 aW9uIGlzOg0KDQogICAgICAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYW4gZXh0ZW5zaW9u IHRvIFRoZSBPQXV0aCAyLjANCiAgICAgICBBdXRob3JpemF0aW9uIEZyYW1ld29yayB0aGF0IGVu YWJsZXMgYW4gYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8NCiAgICAgICBwcm92aWRlIGEgY2xpZW50 IHVzaW5nIGl0IHdpdGggYSBjb25zaXN0ZW50IHNldCBvZiBtZXRhZGF0YQ0KICAgICAgIGFib3V0 IGl0c2VsZi4gVGhpcyBpbmZvcm1hdGlvbiBpcyByZXR1cm5lZCBpbiB0aGUgYXV0aG9yaXphdGlv bg0KICAgICAgIHJlc3BvbnNlLiBJdCBjYW4gYmUgdXNlZCBieSB0aGUgY2xpZW50IHRvIHByZXZl bnQgY2xhc3NlcyBvZg0KICAgICAgIGF0dGFja3MgaW4gd2hpY2ggdGhlIGNsaWVudCBtaWdodCBv dGhlcndpc2UgYmUgdHJpY2tlZCBpbnRvDQogICAgICAgdXNpbmcgaW5jb25zaXN0ZW50IHNldHMg b2YgbWV0YWRhdGEgZnJvbSBtdWx0aXBsZSBhdXRob3JpemF0aW9uDQogICAgICAgc2VydmVycywg aW5jbHVkaW5nIHBvdGVudGlhbGx5IHVzaW5nIGEgdG9rZW4gZW5kcG9pbnQgdGhhdCBkb2VzDQog ICAgICAgbm90IGJlbG9uZyB0byB0aGUgc2FtZSBhdXRob3JpemF0aW9uIHNlcnZlciBhcyB0aGUg YXV0aG9yaXphdGlvbg0KICAgICAgIGVuZHBvaW50IHVzZWQuIFJlY2VudCByZXNlYXJjaCBwdWJs aWNhdGlvbnMgcmVmZXIgdG8gdGhlc2UgYXMNCiAgICAgICAiSWRQIE1peC1VcCIgYW5kICJNYWxp Y2lvdXMgRW5kcG9pbnQiIGF0dGFja3MuDQoNCiAgICAgICBUaGUgZ2lzdCBvZiB0aGUgbWl0aWdh dGlvbiBpcyBoYXZpbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyDQogICAgICAgcmV0dXJuIHRo ZSBjbGllbnQgSUQgYW5kIGl0cyBpc3N1ZXIgaWRlbnRpZmllciAoYSB2YWx1ZSBkZWZpbmVkDQog ICAgICAgaW4gdGhlIE9BdXRoIERpc2NvdmVyeSBzcGVjaWZpY2F0aW9uDQogICAgICAgPGh0dHA6 Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE0OTY+KSBzbyB0aGF0IHRoZSBjbGllbnQgY2FuIHZlcmlm eQ0KICAgICAgIHRoYXQgaXQgaXMgdXNpbmcgYSBjb25zaXN0ZW50IHNldCBvZiBhdXRob3JpemF0 aW9uIHNlcnZlcg0KICAgICAgIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24sIHRoYXQgdGhlIGNs aWVudCBJRCBpcyBmb3IgdGhhdA0KICAgICAgIGF1dGhvcml6YXRpb24gc2VydmVyLCBhbmQgaW4g cGFydGljdWxhciwgdGhhdCB0aGUgY2xpZW50IGlzIG5vdA0KICAgICAgIGJlaW5nIGNvbmZ1c2Vk IGludG8gc2VuZGluZyBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3Igb25lDQogICAgICAgYXV0aG9y aXphdGlvbiBzZXJ2ZXIgdG8gYSBkaWZmZXJlbnQgb25lLiAgTm90ZSB0aGF0IHRoZXNlDQogICAg ICAgYXR0YWNrcyBjYW4gb25seSBiZSBtYWRlIGFnYWluc3QgY2xpZW50cyB0aGF0IGFyZSBjb25m aWd1cmVkIHRvDQogICAgICAgdXNlIG1vcmUgdGhhbiBvbmUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIu DQoNCiAgICAgICBQbGVhc2UgZ2l2ZSB0aGUgZHJhZnQgYSBxdWljayByZWFkIGFuZCBwcm92aWRl IGZlZWRiYWNrIHRvIHRoZQ0KICAgICAgIE9BdXRoIHdvcmtpbmcgZ3JvdXAuICBUaGlzIGRyYWZ0 IGlzIHZlcnkgbXVjaCBhIHN0YXJ0aW5nIHBvaW50DQogICAgICAgaW50ZW5kZWQgdG8gZGVzY3Jp YmUgYm90aCB0aGUgbWl0aWdhdGlvbnMgYW5kIHRoZSBkZWNpc2lvbnMgYW5kDQogICAgICAgYW5h bHlzaXMgcmVtYWluaW5nIGJlZm9yZSB3ZSBjYW4gYmUgY29uZmlkZW50IGluIHN0YW5kYXJkaXpp bmcgYQ0KICAgICAgIHNvbHV0aW9uLiAgUGxlYXNlIGRlZmluaXRlbHkgcmVhZCB0aGUgU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMNCiAgICAgICBhbmQgT3BlbiBJc3N1ZXMgc2VjdGlvbnMsIGFzIHRo ZXkgY29udGFpbiBpbXBvcnRhbnQgaW5mb3JtYXRpb24NCiAgICAgICBhYm91dCB0aGUgY2hvaWNl cyBtYWRlIGFuZCB0aGUgZGVjaXNpb25zIHJlbWFpbmluZy4NCg0KICAgICAgIFNwZWNpYWwgdGhh bmtzIGdvIHRvIERhbmllbCBGZXR0IChVbml2ZXJzaXR5IG9mIFRyaWVyKSwNCiAgICAgICBDaHJp c3RpYW4gTWFpbmthIChSdWhyLVVuaXZlcnNpdHkgQm9jaHVtKSwgVmxhZGlzbGF2IE1sYWRlbm92 DQogICAgICAgKFJ1aHItVW5pdmVyc2l0eSBCb2NodW0pLCBhbmQgR3VpZG8gU2NobWl0eiAoVW5p dmVyc2l0eSBvZg0KICAgICAgIFRyaWVyKSBmb3Igbm90aWZ5aW5nIHVzIG9mIHRoZSBhdHRhY2tz IGFuZCB3b3JraW5nIHdpdGggdXMgYm90aA0KICAgICAgIG9uIHVuZGVyc3RhbmRpbmcgdGhlIGF0 dGFja3MgYW5kIG9uIGRldmVsb3BpbmcgbWl0aWdhdGlvbnMuDQogICAgICAgVGhhbmtzIHRvbyB0 byBIYW5uZXMgVHNjaG9mZW5pZyBmb3Igb3JnYW5pemluZyBhIG1lZXRpbmcgb24gdGhpcw0KICAg ICAgIHRvcGljIGxhc3QgbW9udGggYW5kIHRvIFRvcnN0ZW4gTG9kZGVyc3RlZHQgYW5kIERldXRz Y2hlIFRlbGVrb20NCiAgICAgICBmb3IgaG9zdGluZyB0aGUgbWVldGluZy4NCg0KICAgICAgIFRo ZSBzcGVjaWZpY2F0aW9uIGlzIGF2YWlsYWJsZSBhdDoNCg0KICAgICAgICpodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1taXgtdXAtbWl0aWdhdGlvbi0wMA0KDQog ICAgICAgQW4gSFRNTC1mb3JtYXR0ZWQgdmVyc2lvbiBpcyBhbHNvIGF2YWlsYWJsZSBhdDoNCg0K ICAgICAgICpodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWpvbmVzLW9hdXRoLW1p eC11cC1taXRpZ2F0aW9uLTAwLmh0bWwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQogICAgICAgUC5T LiAgVGhpcyBub3RlIHdhcyBhbHNvIHBvc3RlZCBhdA0KICAgICAgIGh0dHA6Ly9zZWxmLWlzc3Vl ZC5pbmZvLz9wPTE1MjQgYW5kIGFzIEBzZWxmaXNzdWVkDQogICAgICAgPGh0dHBzOi8vdHdpdHRl ci5jb20vc2VsZmlzc3VlZD4uDQoNCg0KDQoNCg0KICAgICAgIF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCiAgICAgICBPQXV0aCBtYWlsaW5nIGxpc3QN Cg0KICAgICAgIE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4gPG1haWx0bzpP QXV0aEBpZXRmLm9yZz4NCg0KICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vb2F1dGgNCg0KDQoNCg0KICAgLS0NCg0KICAgQ2hpZWYgQXJjaGl0ZWN0DQoNCiAgIElk ZW50aXR5IFNlcnZpY2VzIEVuZ2luZWVyaW5nICAgICBXb3JrOmdlb3JnZS5mbGV0Y2hlckB0ZWFt YW9sLmNvbTxtYWlsdG86Z2VvcmdlLmZsZXRjaGVyQHRlYW1hb2wuY29tPiA8bWFpbHRvOmdlb3Jn ZS5mbGV0Y2hlckB0ZWFtYW9sLmNvbT4NCg0KICAgQU9MIEluYy4gICAgICAgICAgICAgICAgICAg ICAgICAgIEFJTTogIGdmZmxldGNoDQoNCiAgIE1vYmlsZTogKzEtNzAzLTQ2Mi0zNDk0ICAgICAg ICAgICBUd2l0dGVyOmh0dHA6Ly90d2l0dGVyLmNvbS9nZmZsZXRjaA0KDQogICBPZmZpY2U6ICsx LTcwMy0yNjUtMjU0NCAgICAgICAgICAgUGhvdG9zOmh0dHA6Ly9nZW9yZ2VmbGV0Y2hlci5waG90 b2dyYXBoeTxodHRwOi8vZ2VvcmdlZmxldGNoZXIucGhvdG9ncmFwaHkvPg0KDQoNCg0KLS0NCg0K Q2hpZWYgQXJjaGl0ZWN0DQoNCklkZW50aXR5IFNlcnZpY2VzIEVuZ2luZWVyaW5nICAgICBXb3Jr Omdlb3JnZS5mbGV0Y2hlckB0ZWFtYW9sLmNvbTxtYWlsdG86Z2VvcmdlLmZsZXRjaGVyQHRlYW1h b2wuY29tPiA8bWFpbHRvOmdlb3JnZS5mbGV0Y2hlckB0ZWFtYW9sLmNvbT4NCg0KQU9MIEluYy4g ICAgICAgICAgICAgICAgICAgICAgICAgIEFJTTogIGdmZmxldGNoDQoNCk1vYmlsZTogKzEtNzAz LTQ2Mi0zNDk0ICAgICAgICAgICBUd2l0dGVyOmh0dHA6Ly90d2l0dGVyLmNvbS9nZmZsZXRjaA0K DQpPZmZpY2U6ICsxLTcwMy0yNjUtMjU0NCAgICAgICAgICAgUGhvdG9zOmh0dHA6Ly9nZW9yZ2Vm bGV0Y2hlci5waG90b2dyYXBoeTxodHRwOi8vZ2VvcmdlZmxldGNoZXIucGhvdG9ncmFwaHkvPg0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQotLQ0KSGFucyBa YW5kYmVsdCAgICAgICAgICAgICAgfCBTci4gVGVjaG5pY2FsIEFyY2hpdGVjdA0KaHphbmRiZWx0 QHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmh6YW5kYmVsdEBwaW5naWRlbnRpdHkuY29tPiB8IFBp bmcgSWRlbnRpdHkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_BY2PR03MB4420A5F143FBCCEA01265D8F5C30BY2PR03MB442namprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUki Ow0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFt ZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzAwMjA2MDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw NjAiPlNvcnJ5IHRvIGJlIHNsb3cgcmVzcG9uZGluZywgTm92LiZuYnNwOyBJIHdhbnRlZCB0byB3 YWl0IHRvIHJlc3BvbmQgdW50aWwgYSBkcmFmdCB3aXRoIHRoZSDigJxzdGF0ZeKAnSB0b2tlbiBy ZXF1ZXN0IHBhcmFtZXRlciB3YXMgcHVibGlzaGVkLCB3aGljaCBqdXN0IGhhcHBlbmVkLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSB0aGluayB0aGUgb2F1dGgt bWV0YSBzcGVjIHNvbHZlcyBzb21lIG9mIHRoZW0gYnV0IG5vdCBvdGhlcnMuJm5ic3A7IFRoZXJl IHdlcmUgYSBidW5jaCBvZiBkaWZmZXJlbnQgYXR0YWNrcyBkaXNjdXNzZWQgYnkgdGhlIHNlY3Vy aXR5IHJlc2VhcmNoZXJzIGluIERhcm1zdGFkdCAoc2VlDQogdGhlIG5vdGVzIGF0IDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL2RvY3MuZ29vZ2xl LmNvbS9kb2N1bWVudC9kLzEzNkN6Mml3VUZNZG9LV1pQQ3FaUmhrbWZtSEFsSjZrTTVPeWVYekdw dFU0L2VkaXQjaGVhZGluZz1oLm9kOTJ1bW1kMjJ6cyI+aHR0cHM6Ly9kb2NzLmdvb2dsZS5jb20v ZG9jdW1lbnQvZC8xMzZDejJpd1VGTWRvS1daUENxWlJoa21mbUhBbEo2a001T3llWHpHcHRVNC9l ZGl0I2hlYWRpbmc9aC5vZDkydW1tZDIyenM8L2E+KSwNCiBzb21lIHdpdGggaW50ZXJkZXBlbmRl bmNpZXMgYmV0d2VlbiB0aGVtLiZuYnNwOyBUaGVyZSBhcmUgcmVhc29ucywgZm9yIGluc3RhbmNl LCBmb3Igc2VuZGluZyB0aGUg4oCcc3RhdGXigJ0gdmFsdWUgdG8gdGhlIHRva2VuIGVuZHBvaW50 IHNvIHRoYXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGNhbiBjaGVjayBpdC4mbmJzcDsgVGhl IG1pdGlnYXRpb25zIGludm9sdmUgdmFsaWRhdGlvbnMgYnkgYm90aCB0aGUgY2xpZW50IGFuZCB0 aGUgc2VydmVyIOKAkyBub3QgYWxsDQogb2Ygd2hpY2ggdGhlIG9hdXRoLW1ldGEgZHJhZnQgaW5j bHVkZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QWxzbywgc2Vl IHRoZSBjdXJyZW50IGRpc2N1c3Npb24gaW4gdGhlIHRocmVhZCDigJxbT0FVVEgtV0ddIENhbGwg Zm9yIEFkb3B0aW9u4oCdLiZuYnNwOyBJbiBzaG9ydCwgSSB0aGluayB0aGVyZSBzaG91bGQgYmUg b25lIHNvbHV0aW9uIGFwcHJvYWNoIHRoYXQgd2Ugd29yayBvbiBmb3IgdGhpcywNCiBub3QgdHdv LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCZXN0IHdpc2hlcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLS0gTWlrZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01h aWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRD b21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gbm92IG1hdGFrZSBbbWFpbHRvOm1hdGFrZUBnbWFpbC5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDExLCAyMDE2IDEwOjQ1IFBNPGJyPg0KPGI+VG86 PC9iPiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBIYW5zIFphbmRiZWx0ICZsdDtoemFuZGJlbHRAcGluZ2lkZW50aXR5LmNvbSZn dDs7IEdlb3JnZSBGbGV0Y2hlciAmbHQ7Z2ZmbGV0Y2hAYW9sLmNvbSZndDs7IG9hdXRoQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIuMCBNaXgtVXAg TWl0aWdhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBNaWtlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Jc27igJl0IE5hdOKAmXMgJnF1b3Q7T0F1dGggUmVzcG9uc2UgTWV0YWRh dGHigJ0gc3BlYyBlbm91Z2ggdG8gc29sdmUgdGhvc2UgaXNzdWVzPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDUudHh0Ij5odHRwczovL3Rvb2xzLmll dGYub3JnL2lkL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDUudHh0PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEphbiAxMiwgMjAxNiwgYXQg MDU6NDAsIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUg c3BlY2lmaWNhdGlvbiBkZXNjcmliZXMgdGhpcyB2YWxpZGF0aW9uIG1ldGhvZCAoY29tcGFyaXNv biBvZiB0aGUgaXNzdWVyIHJlY2VpdmVkIHRvIHRoZSBpc3N1ZXIgcmVjb3JkZWQgYXQgcmVnaXN0 cmF0aW9uIHRpbWUpIGluIHN0ZXAgMiBvZiBTZWN0aW9uIDQgKFZhbGlkYXRpbmcgdGhlIFJlc3Bv bnNlKS4NCiAmbmJzcDtJbiBmYWN0LCBJIGFkZGVkIHRoaXMgaW4gcmVzcG9uc2UgdG8geW91ciBm ZWVkYmFjayBvbiBhbiBlYXJsaWVyIGRyYWZ0LCBIYW5zLjxicj4NCjxicj4NCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogSGFucyBaYW5kYmVsdCBbPC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpoemFuZGJlbHRAcGluZ2lkZW50aXR5LmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWFp bHRvOmh6YW5kYmVsdEBwaW5naWRlbnRpdHkuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N ClNlbnQ6IE1vbmRheSwgSmFudWFyeSAxMSwgMjAxNiAxMjozNCBQTTxicj4NClRvOiBNaWtlIEpv bmVzICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7OyBHZW9yZ2UgRmxldGNoZXIgJmx0Ozwvc3Bhbj48YSBo cmVmPSJtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Z2ZmbGV0Y2hA YW9sLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpv YXV0aEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+b2F1dGhAaWV0Zi5vcmc8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIE9BdXRoIDIu MCBNaXgtVXAgTWl0aWdhdGlvbjxicj4NCjxicj4NCkkgZGlzYWdyZWUgdGhhdCB2YWxpZGF0aW5n IGVuZHBvaW50cyAmcXVvdDthdCB0aGlzIHN0ZXAmcXVvdDsgKHdoaWNoIHJlZmVycyB0byByaWdo dCBiZWZvcmUgbWFraW5nIHRoZSB0b2tlbiByZXF1ZXN0KSBzaG91bGQgYmUgdGhlIGRlZmF1bHQg d2F5IG9mIGhhbmRsaW5nIHRoaXMuIFRoZSB2YXN0IG1ham9yaXR5IG9mIE9BdXRoIGNsaWVudCBk ZXBsb3ltZW50cyBjb25uZWN0aW5nIHRvIG1vcmUgdGhhbiBvbmUgQVMgd2lsbCBoYXZlIGEgc3Rh dGljIGNvbmZpZ3VyYXRpb24NCiBvZiB0aGUgQVNlcyBpc3N1ZXIvZW5kcG9pbnQgaW5mb3JtYXRp b24gYW55aG93IGFuZCB0aGV5IGp1c3QgbmVlZCB0byBjb25maXJtIHRoYXQgdGhlIGlzc3VlciB2 YWx1ZSByZWNlaXZlZCBpbiB0aGUgYXV0aG9yaXphdGlvbiByZXNwb25zZSBpcyB0aGUgc2FtZSBp c3N1ZXIgYXMgdGhhdCB0aGUgcmVxdWVzdCB3YXMgc2VudCB0by48YnI+DQo8YnI+DQpIYW5zLjxi cj4NCjxicj4NCk9uIDEvMTEvMTYgMToxNCBQTSwgTWlrZSBKb25lcyB3cm90ZTo8YnIgc3R5bGU9 Im9ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkNvcnJlY3Q8YnI+DQo8YnI+DQoqRnJvbToqR2Vvcmdl IEZsZXRjaGVyIFs8YSBocmVmPSJtYWlsdG86Z2ZmbGV0Y2hAYW9sLmNvbSI+bWFpbHRvOmdmZmxl dGNoQGFvbC5jb208L2E+XTxicj4NCipTZW50OiogTW9uZGF5LCBKYW51YXJ5IDExLCAyMDE2IDEy OjEzIFBNPGJyPg0KKlRvOiogTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwu Sm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs7 DQo8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciPm9hdXRoQGlldGYub3JnPC9hPjxicj4N CipTdWJqZWN0OiogUmU6IFtPQVVUSC1XR10gT0F1dGggMi4wIE1peC1VcCBNaXRpZ2F0aW9uPGJy Pg0KPGJyPg0KU28ganVzdCB0byBtYWtlIHN1cmUgSSB1bmRlcnN0YW5kLi4uPGJyPg0KPGJyPg0K VGhpcyBzcGVjaWZpY2F0aW9uIHJlcXVpcmVzIHRoZSByZXNwb25zZSBmcm9tIHRoZSBBdXRob3Jp emF0aW9uIFNlcnZlcjxicj4NCnRvIGFuIHN1Y2Nlc3NmdWwgL2F1dGhvcml6ZSBjYWxsIHRvIHBh c3MgYmFjayBjb2RlPSwgc3RhdGU9IGFuZCBqd3Q9ICg/KTxicj4NCm9yIGluZGl2aWR1YWxseSBp c3M9IGFuZCBhdWQ9IGFzIFVSTCBwYXJhbWV0ZXJzIG9uIHRoZSAzMDIgdG8gdGhlPGJyPg0KcmVk aXJlY3RfdXJsLiBUaGlzIHdheSwgYmVmb3JlIHRoZSBjbGllbnQgaXNzdWVzIGEgY2FsbCB0byB0 aGUgL3Rva2VuPGJyPg0KZW5kcG9pbnQgKHdpdGggdGhlIGNvZGUpLCBpdCBjYW4gdmVyaWZ5IHRo YXQgdGhlIHRva2VuIGVuZHBvaW50IGlzIGNvcnJlY3QuPGJyPg0KPGJyPg0KSWYgdGhlIGNsaWVu dCBkb2Vzbid0IHZhbGlkYXRlIHRoZSBlbmRwb2ludHMgYXQgdGhpcyBzdGVwLCB0aGVuIGl0IGNv dWxkPGJyPg0KZGlzY2xvc2UgaXQncyBzZWNyZXQgdG8gYSBtYWxpY2lvdXMgZW5kcG9pbnQuIENv cnJlY3Q/PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkdlb3JnZTxicj4NCjxicj4NCk9uIDEvMTEv MTYgMjo1OSBQTSwgTWlrZSBKb25lcyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJz cDtUaGUgYWx0ZXJuYXRpdmVzIGZvciB0aGUgY29kZSBmbG93IGFyZSB0byByZXR1cm4gdGhlbSBl aXRoZXIgaW4gYTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO25ldyBKV1QgYWRkZWQgdG8gdGhlIHJl cGx5IGNvbnRhaW5pbmcgdGhlbSBpbiB0aGUgJnF1b3Q7aXNzJnF1b3Q7IGFuZCAmcXVvdDthdWQm cXVvdDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtjbGFpbXMgb3IgdG8gcmV0dXJuIHRoZW0gaW4g bmV3IGluZGl2aWR1YWwgJnF1b3Q7Y2xpZW50X2lkJnF1b3Q7IGFuZCAmcXVvdDtpc3MmcXVvdDs8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDthdXRob3JpemF0aW9uIHJlc3BvbnNlIHBhcmFtZXRlcnMu ICZuYnNwO0JvdGggYWx0ZXJuYXRpdmVzIGFyZSBkZXNjcmliZWQ8YnI+DQombmJzcDsmbmJzcDsm bmJzcDtpbiB0aGUgZHJhZnQuICZuYnNwO0knbSBzdXJlIHRoYXQgd2UnbGwgbm93IGJlIGhhdmlu ZyBhIGdvb2QgZW5naW5lZXJpbmc8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtkaXNjdXNzaW9uIG9u IHRoZSB0cmFkZW9mZnMgYmV0d2VlbiB0aGUgYWx0ZXJuYXRpdmVzLiw8YnI+DQo8YnI+DQombmJz cDsmbmJzcDsmbmJzcDtJbiBhIHNlcGFyYXRlIGRyYWZ0LCBKb2huIEJyYWRsZXkgd2lsbCBzaG9y dGx5IGFsc28gYmUgZGVzY3JpYmluZzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO3RoZSBwb3NzaWJp bGl0eSBvZiBzZWN1cmluZyB0aGUgJnF1b3Q7c3RhdGUmcXVvdDsgdmFsdWUgdXNpbmcgYSAmcXVv dDtzdGF0ZV9oYXNoJnF1b3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7dmFsdWUgdGhhdCB3b3Jr cyBpbiBhIHdheSB0aGF0J3Mgc2ltaWxhciB0byBob3cgJnF1b3Q7YXRfaGFzaCZxdW90OyBhbmQ8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtjX2hhc2gmcXVvdDsgc2VjdXJlIHRoZSAmcXVv dDthY2Nlc3NfdG9rZW4mcXVvdDsgYW5kICZxdW90O2NvZGUmcXVvdDsgdmFsdWVzIGluIENvbm5l Y3QuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyB3b3VsZCBiZSBhbiBhbHRlcm5hdGl2ZSBt ZWFucyBvZiBiaW5kaW5nIHRoZSBhdXRob3JpemF0aW9uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 cmVxdWVzdCBhbmQgcmVzcG9uc2UgdG8gdGhlIHNlc3Npb24gLSBhY2NvbXBsaXNoaW5nIHRoZSBz YW1lIHRoaW5nPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7dGhhdCB0aGUgQ29ubmVjdCAmcXVvdDtu b25jZSZxdW90OyBkb2VzLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO1doaWxlIEkgZnVs bHkgZ2V0IHRoYXQgc29tZSBPQXV0aCBpbXBsZW1lbnRhdGlvbnMgd2FudCB0byBhdm9pZDxicj4N CiZuYnNwOyZuYnNwOyZuYnNwO2hhdmluZyB0byBoYXZlIGNyeXB0bywgaXQgc2VlbXMgbGlrZSBh dCBsZWFzdCBzdXBwb3J0IGZvcjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO2NyeXB0b2dyYXBoaWMg aGFzaGluZyAoU0hBLTI1NiwgZXRjLikgbWF5IGJlIG5lY2Vzc2FyeSB0byBtaXRpZ2F0ZTxicj4N CiZuYnNwOyZuYnNwOyZuYnNwO3NvbWUgb2YgdGhlc2UgYXR0YWNrcyAoYXQgbGVhc3QgZm9yIGNs aWVudHMgdGhhdCB1c2UgbW9yZSB0aGFuIG9uZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO2F1dGhv cml6YXRpb24gc2VydmVyKS48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtUaGUgb3RoZXIg aW1wb3J0YW50IGVuZ2luZWVyaW5nIGRpc2N1c3Npb24gSSBrbm93IHdlJ3JlIGdvaW5nIHRvPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7aGF2ZSBpcyB3aGV0aGVyLCB3aGVuIGFuIE9BdXRoIHByb2Zp bGUgYWxyZWFkeSByZXR1cm5zIHRoZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO2luZm9ybWF0aW9u IG5lZWRlZCBmb3IgdGhlIG1pdGlnYXRpb24sIHdoZXRoZXIgd2Ugd2FudCB0byBzcGVjaWZ5PGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7dGhhdCB0aGUgY2xpZW50IG9idGFpbiBpdCBmcm9tIHRoZSBl eGlzdGluZyBsb2NhdGlvbiwgb3Igd2hldGhlciB0bzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO2Fs c28gcmV0dXJuIGl0IGluIGEgZHVwbGljYXRlIGxvY2F0aW9uLiAmbmJzcDtJJ2xsIG5vdGUgdGhh dCBPcGVuSUQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtDb25uZWN0IGFscmVhZHkgcmV0dXJucyB0 aGUgY2xpZW50IElEIGFuZCBpc3N1ZXIgZm9yIHRoZSBmbG93cyB0aGF0PGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7cmV0dXJuIGFuIElEIFRva2VuIGluIHRoZSBhdXRob3JpemF0aW9uIHJlc3BvbnNl LCBzbyB0aGlzIGlzbid0IGE8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtoeXBvdGhldGljYWwgcXVl c3Rpb24uPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7RmluYWxseSwgSSBrbm93IHRoYXQg d2UnbGwgbmVlZCB0byBkaXNjdXNzIHRoZSBpbXBhY3Qgb2Y8YnI+DQombmJzcDsmbmJzcDsmbmJz cDtjdXQtYW5kLXBhc3RlIGF0dGFja3Mgd2hlbiB0aGUgaXNzdWVyIGFuZCBjbGllbnQgSUQgYXJl IHJldHVybmVkIGFzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7aW5kaXZpZHVhbCBhdXRob3JpemF0 aW9uIHJlc3BvbnNlIHBhcmFtZXRlcnMgdGhhdCBhcmUgbm90PGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Y3J5cHRvZ3JhcGhpY2FsbHkgYm91bmQgdG8gdGhlIHJlc3Qgb2YgdGhlIHJlc3BvbnNlLiAm bmJzcDtUaGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtjdXQtYW5kLXBhc3RlIGF0dGFjayB0aGF0 IHJldHVybmluZyB0aGUgaXNzdWVyIGFuZCBjbGllbnRfaWQgdmFsdWVzPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7YXMgc2VwYXJhdGUgcGFyYW1ldGVycyBlbmFibGVzLCBldmVuIHdoZW4gc3RhdGVf aGFzaCBvciBub25jZSBpczxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO3VzZWQsIGlzIGZvciB0aGUg YXR0YWNrZXIgdG8gY2FwdHVyZSB0aGUgbGVnaXRpbWF0ZSByZXNwb25zZTxicj4NCiZuYnNwOyZu YnNwOyZuYnNwO2NvbnRhaW5pbmcgJnF1b3Q7aXNzJnF1b3Q7IGFuZCAmcXVvdDtjbGllbnRfaWQm cXVvdDsgcmVzdWx0cyBhbmQgc3Vic3RpdHV0ZSBkaWZmZXJlbnQ8YnI+DQombmJzcDsmbmJzcDsm bmJzcDt2YWx1ZXMgZm9yIHRoZXNlIGZpZWxkcywgdGhlbiBwb3N0IHRoYXQgYWx0ZXJlZCByZXNw b25zZSB0byB0aGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtsZWdpdGltYXRlIGNsaWVudC4gJm5i c3A7VGhlIHN0YXRlIGFuZC9vciBub25jZSB2YWx1ZXMgYXJlIHByb3RlY3RlZDxicj4NCiZuYnNw OyZuYnNwOyZuYnNwO2FnYWluc3Qgc3Vic3RpdHV0aW9uIGJ1dCAmcXVvdDtpc3MmcXVvdDsgYW5k ICZxdW90O2NsaWVudF9pZCZxdW90OyBhcmUgbm90Ljxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZu YnNwO0FuZCB5ZXMsIEkgYWJzb2x1dGVseSBhZ3JlZSB0aGF0IGdvb2QgZXhhbXBsZXMgYXJlIGVz c2VudGlhbC48YnI+DQombmJzcDsmbmJzcDsmbmJzcDtUaGF0J3MgaGlnaCBvbiBteSBsaXN0IGZv ciB0aGUgLTAxIHZlcnNpb24uPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7VGhhbmtzIGE8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtidW5jaCw8YnI+DQo8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLSBNaWtlPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7KkZyb206Kkdlb3JnZSBGbGV0Y2hlciBbPGEgaHJlZj0ibWFpbHRvOmdmZmxldGNoQGFv bC5jb20iPm1haWx0bzpnZmZsZXRjaEBhb2wuY29tPC9hPl08YnI+DQombmJzcDsmbmJzcDsmbmJz cDsqU2VudDoqIE1vbmRheSwgSmFudWFyeSAxMSwgMjAxNiAxMDoyMSBBTTxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOypUbzoqIE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpv bmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1p Y3Jvc29mdC5jb20iPm1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozs8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIj5tYWlsdG86b2F1dGhA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOypTdWJqZWN0OiogUmU6IFtP QVVUSC1XR10gT0F1dGggMi4wIE1peC1VcCBNaXRpZ2F0aW9uPGJyPg0KPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7VGhhbmtzIE1pa2UuIE9uZSBxdWVzdGlvbiBhZnRlciByZWFkaW5nIGFib3V0IHRo ZSBkaWZmZXJlbnQgYXR0YWNrPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7dmVjdG9ycyBhbmQgdGhp cyBzcGVjLi4uPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7SG93IGFyZSB0aGUgJ2lzcycg YW5kICdhdWQnIHZhbHVlcyByZXR1cm5lZCB3aXRoIHRoZSAnY29kZScgYW5kPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7J3N0YXRlJyBwYXJhbWV0ZXJzLiBJdCBzZWVtcyB0aGUgY2xpZW50IG5lZWRz IHRvIHZlcmlmeSB0aGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtlbmRwb2ludHMgYmVmb3JlIG1h a2luZyB0aGUgcmVxdWVzdCB0byBleGNoYW5nZSB0aGUgY29kZSBmb3IgYTxicj4NCiZuYnNwOyZu YnNwOyZuYnNwO3Rva2VuLiBJZiB0aGUgY2xpZW50IGlzIHVzaW5nIHRoZSBkZWZhdWx0IE9BdXRo MiBjbGllbnRfaWQgYW5kPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Y2xpZW50X3NlY3JldCB0aGVz ZSB2YWx1ZXMgd2lsbCBiZSBzZW50IHRvIHRoZSBtYWxpY2lvdXMgZW5kcG9pbnQgaWY8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDt0aGUgY2xpZW50IGNhbid0IHZlcmlmeSB0aGUgZW5kcG9pbnRzIGJl Zm9yZSBoYW5kLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0Fsc28sIGl0IHdvdWxkIGJl IG5pY2UgdG8gYWRkIHNvbWUgbm9uLW5vcm1hdGl2ZSBleGFtcGxlcyB0byB0aGUgc3BlYy48YnI+ DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtUaGFua3MsPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 R2VvcmdlPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7T24gMS8xMS8xNiA0OjI3IEFNLCBN aWtlIEpvbmVzIHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO1llc3RlcmRheSBIYW5uZXMgVHNjaG9mZW5pZyBhbm5vdW5jZWQgYW4gT0F1 dGggU2VjdXJpdHkgQWR2aXNvcnk8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtvbiBBdXRob3JpemF0aW9uIFNlcnZlciBNaXgtVXA8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9vYXV0aC9KSVZ4RkJHc0pCVnRtN2xqd0poUFVtM0Zy LXciPmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb2F1dGgvSklWeEZCR3NK QlZ0bTdsandKaFBVbTNGci13PC9hPiZndDsuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyBub3RlIGFubm91bmNlcyB0aGUgcHVibGljYXRpb24gb2Yg dGhlIHN0cmF3bWFuIE9BdXRoIDIuMDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO01peC1VcCBNaXRpZ2F0aW9uIGRyYWZ0IGhlIG1lbnRpb25lZCB0aGF0IG1p dGlnYXRlcyB0aGUgYXR0YWNrczxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO2NvdmVyZWQgaW4gdGhlIGFkdmlzb3J5LiAmbmJzcDtUaGUgYWJzdHJhY3Qgb2Yg dGhlIHNwZWNpZmljYXRpb24gaXM6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYW4gZXh0ZW5zaW9u IHRvIFRoZSBPQXV0aCAyLjA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtBdXRob3JpemF0aW9uIEZyYW1ld29yayB0aGF0IGVuYWJsZXMgYW4gYXV0aG9yaXph dGlvbiBzZXJ2ZXIgdG88YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtwcm92aWRlIGEgY2xpZW50IHVzaW5nIGl0IHdpdGggYSBjb25zaXN0ZW50IHNldCBvZiBt ZXRhZGF0YTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Fi b3V0IGl0c2VsZi4gVGhpcyBpbmZvcm1hdGlvbiBpcyByZXR1cm5lZCBpbiB0aGUgYXV0aG9yaXph dGlvbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Jlc3Bv bnNlLiBJdCBjYW4gYmUgdXNlZCBieSB0aGUgY2xpZW50IHRvIHByZXZlbnQgY2xhc3NlcyBvZjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2F0dGFja3MgaW4g d2hpY2ggdGhlIGNsaWVudCBtaWdodCBvdGhlcndpc2UgYmUgdHJpY2tlZCBpbnRvPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dXNpbmcgaW5jb25zaXN0ZW50 IHNldHMgb2YgbWV0YWRhdGEgZnJvbSBtdWx0aXBsZSBhdXRob3JpemF0aW9uPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c2VydmVycywgaW5jbHVkaW5nIHBv dGVudGlhbGx5IHVzaW5nIGEgdG9rZW4gZW5kcG9pbnQgdGhhdCBkb2VzPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bm90IGJlbG9uZyB0byB0aGUgc2FtZSBh dXRob3JpemF0aW9uIHNlcnZlciBhcyB0aGUgYXV0aG9yaXphdGlvbjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2VuZHBvaW50IHVzZWQuIFJlY2VudCByZXNl YXJjaCBwdWJsaWNhdGlvbnMgcmVmZXIgdG8gdGhlc2UgYXM8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtJZFAgTWl4LVVwJnF1b3Q7IGFuZCAmcXVv dDtNYWxpY2lvdXMgRW5kcG9pbnQmcXVvdDsgYXR0YWNrcy48YnI+DQo8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgZ2lzdCBvZiB0aGUgbWl0aWdhdGlv biBpcyBoYXZpbmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cmV0dXJuIHRoZSBjbGllbnQgSUQgYW5kIGl0cyBp c3N1ZXIgaWRlbnRpZmllciAoYSB2YWx1ZSBkZWZpbmVkPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aW4gdGhlIE9BdXRoIERpc2NvdmVyeSBzcGVjaWZpY2F0 aW9uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Ozxh IGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvLz9wPTE0OTYiPmh0dHA6Ly9zZWxmLWlzc3Vl ZC5pbmZvLz9wPTE0OTY8L2E+Jmd0Oykgc28gdGhhdCB0aGUgY2xpZW50IGNhbiB2ZXJpZnk8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGF0IGl0IGlzIHVz aW5nIGEgY29uc2lzdGVudCBzZXQgb2YgYXV0aG9yaXphdGlvbiBzZXJ2ZXI8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjb25maWd1cmF0aW9uIGluZm9ybWF0 aW9uLCB0aGF0IHRoZSBjbGllbnQgSUQgaXMgZm9yIHRoYXQ8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthdXRob3JpemF0aW9uIHNlcnZlciwgYW5kIGluIHBh cnRpY3VsYXIsIHRoYXQgdGhlIGNsaWVudCBpcyBub3Q8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtiZWluZyBjb25mdXNlZCBpbnRvIHNlbmRpbmcgaW5mb3Jt YXRpb24gaW50ZW5kZWQgZm9yIG9uZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO2F1dGhvcml6YXRpb24gc2VydmVyIHRvIGEgZGlmZmVyZW50IG9uZS4gJm5i c3A7Tm90ZSB0aGF0IHRoZXNlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7YXR0YWNrcyBjYW4gb25seSBiZSBtYWRlIGFnYWluc3QgY2xpZW50cyB0aGF0IGFy ZSBjb25maWd1cmVkIHRvPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7dXNlIG1vcmUgdGhhbiBvbmUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuPGJyPg0KPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UGxlYXNlIGdpdmUgdGhl IGRyYWZ0IGEgcXVpY2sgcmVhZCBhbmQgcHJvdmlkZSBmZWVkYmFjayB0byB0aGU8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtPQXV0aCB3b3JraW5nIGdyb3Vw LiAmbmJzcDtUaGlzIGRyYWZ0IGlzIHZlcnkgbXVjaCBhIHN0YXJ0aW5nIHBvaW50PGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aW50ZW5kZWQgdG8gZGVzY3Jp YmUgYm90aCB0aGUgbWl0aWdhdGlvbnMgYW5kIHRoZSBkZWNpc2lvbnMgYW5kPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5hbHlzaXMgcmVtYWluaW5nIGJl Zm9yZSB3ZSBjYW4gYmUgY29uZmlkZW50IGluIHN0YW5kYXJkaXppbmcgYTxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3NvbHV0aW9uLiAmbmJzcDtQbGVhc2Ug ZGVmaW5pdGVseSByZWFkIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9uczxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FuZCBPcGVuIElzc3VlcyBzZWN0aW9u cywgYXMgdGhleSBjb250YWluIGltcG9ydGFudCBpbmZvcm1hdGlvbjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2Fib3V0IHRoZSBjaG9pY2VzIG1hZGUgYW5k IHRoZSBkZWNpc2lvbnMgcmVtYWluaW5nLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NwZWNpYWwgdGhhbmtzIGdvIHRvIERhbmllbCBGZXR0IChV bml2ZXJzaXR5IG9mIFRyaWVyKSw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtDaHJpc3RpYW4gTWFpbmthIChSdWhyLVVuaXZlcnNpdHkgQm9jaHVtKSwgVmxh ZGlzbGF2IE1sYWRlbm92PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7KFJ1aHItVW5pdmVyc2l0eSBCb2NodW0pLCBhbmQgR3VpZG8gU2NobWl0eiAoVW5pdmVy c2l0eSBvZjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1Ry aWVyKSBmb3Igbm90aWZ5aW5nIHVzIG9mIHRoZSBhdHRhY2tzIGFuZCB3b3JraW5nIHdpdGggdXMg Ym90aDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO29uIHVu ZGVyc3RhbmRpbmcgdGhlIGF0dGFja3MgYW5kIG9uIGRldmVsb3BpbmcgbWl0aWdhdGlvbnMuPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhhbmtzIHRvbyB0 byBIYW5uZXMgVHNjaG9mZW5pZyBmb3Igb3JnYW5pemluZyBhIG1lZXRpbmcgb24gdGhpczxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RvcGljIGxhc3QgbW9u dGggYW5kIHRvIFRvcnN0ZW4gTG9kZGVyc3RlZHQgYW5kIERldXRzY2hlIFRlbGVrb208YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtmb3IgaG9zdGluZyB0aGUg bWVldGluZy48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtUaGUgc3BlY2lmaWNhdGlvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7KjxhIGhyZWY9Imh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLW1peC11cC1taXRpZ2F0aW9uLTAwIj5o dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1taXgtdXAtbWl0aWdh dGlvbi0wMDwvYT48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtBbiBIVE1MLWZvcm1hdHRlZCB2ZXJzaW9uIGlzIGFsc28gYXZhaWxhYmxlIGF0Ojxi cj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyo8YSBo cmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWpvbmVzLW9hdXRoLW1peC11 cC1taXRpZ2F0aW9uLTAwLmh0bWwiPmh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQt am9uZXMtb2F1dGgtbWl4LXVwLW1pdGlnYXRpb24tMDAuaHRtbDwvYT48YnI+DQo8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLSBNaWtl PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UC5T LiAmbmJzcDtUaGlzIG5vdGUgd2FzIGFsc28gcG9zdGVkIGF0PGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmlu Zm8vP3A9MTUyNCI+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTUyNDwvYT48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+YW5kIGFzIEBzZWxmaXNzdWVk PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0OzxhIGhy ZWY9Imh0dHBzOi8vdHdpdHRlci5jb20vc2VsZmlzc3VlZCI+aHR0cHM6Ly90d2l0dGVyLmNvbS9z ZWxmaXNzdWVkPC9hPiZndDsuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8YSBocmVmPSJtYWlsdG86 T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIj5tYWlsdG86T0F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7LS08YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtDaGllZiBBcmNoaXRlY3Q8 YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtJZGVudGl0eSBTZXJ2aWNlcyBFbmdpbmVlcmlu ZyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtXb3JrOjxhIGhyZWY9Im1haWx0bzpnZW9yZ2UuZmxl dGNoZXJAdGVhbWFvbC5jb20iPmdlb3JnZS5mbGV0Y2hlckB0ZWFtYW9sLmNvbTwvYT48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0OzxhIGhyZWY9Im1h aWx0bzpnZW9yZ2UuZmxldGNoZXJAdGVhbWFvbC5jb20iPm1haWx0bzpnZW9yZ2UuZmxldGNoZXJA dGVhbWFvbC5jb208L2E+Jmd0Ozxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0FPTCBJbmMu ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0FJTTogJm5ic3A7Z2ZmbGV0Y2g8 YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtNb2JpbGU6ICYjNDM7MS03MDMtNDYyLTM0OTQg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7VHdpdHRlcjo8YSBocmVmPSJodHRwOi8vdHdpdHRlci5jb20vZ2ZmbGV0Y2giPmh0dHA6Ly90 d2l0dGVyLmNvbS9nZmZsZXRjaDwvYT48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtPZmZp Y2U6ICYjNDM7MS03MDMtMjY1LTI1NDQgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UGhvdG9zOjxhIGhyZWY9Imh0dHA6Ly9nZW9yZ2Vm bGV0Y2hlci5waG90b2dyYXBoeS8iPmh0dHA6Ly9nZW9yZ2VmbGV0Y2hlci5waG90b2dyYXBoeTwv YT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLTxicj4NCjxicj4NCkNoaWVmIEFyY2hpdGVjdDxi cj4NCjxicj4NCklkZW50aXR5IFNlcnZpY2VzIEVuZ2luZWVyaW5nICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO1dvcms6PGEgaHJlZj0ibWFpbHRvOmdlb3JnZS5mbGV0Y2hlckB0ZWFtYW9sLmNvbSI+ Z2VvcmdlLmZsZXRjaGVyQHRlYW1hb2wuY29tPC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmdlb3JnZS5mbGV0Y2hl ckB0ZWFtYW9sLmNvbSI+bWFpbHRvOmdlb3JnZS5mbGV0Y2hlckB0ZWFtYW9sLmNvbTwvYT4mZ3Q7 PGJyPg0KPGJyPg0KQU9MIEluYy4gJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 QUlNOiAmbmJzcDtnZmZsZXRjaDxicj4NCjxicj4NCk1vYmlsZTogJiM0MzsxLTcwMy00NjItMzQ5 NCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtUd2l0dGVyOjxhIGhyZWY9Imh0dHA6Ly90d2l0dGVyLmNvbS9nZmZsZXRjaCI+aHR0cDov L3R3aXR0ZXIuY29tL2dmZmxldGNoPC9hPjxicj4NCjxicj4NCk9mZmljZTogJiM0MzsxLTcwMy0y NjUtMjU0NCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtQaG90b3M6PGEgaHJlZj0iaHR0cDovL2dlb3JnZWZsZXRjaGVyLnBob3RvZ3Jh cGh5LyI+aHR0cDovL2dlb3JnZWZsZXRjaGVyLnBob3RvZ3JhcGh5PC9hPjxicj4NCjxicj4NCjxi cj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu b3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCi0tPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCkhhbnMgWmFuZGJlbHQg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBTci4gVGVjaG5pY2FsIEFyY2hpdGVjdDxicj4NCjwvc3Bh bj48YSBocmVmPSJtYWlsdG86aHphbmRiZWx0QHBpbmdpZGVudGl0eS5jb20iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPmh6YW5kYmVsdEBwaW5naWRlbnRpdHkuY29tPC9zcGFuPjwvYT48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnwNCiBQaW5nIElkZW50aXR5PGJyPg0KPGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls aW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BY2PR03MB4420A5F143FBCCEA01265D8F5C30BY2PR03MB442namprd_-- From nobody Thu Jan 21 00:38:58 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75191A1A66 for ; Thu, 21 Jan 2016 00:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvlT9eIQ5lVT for ; Thu, 21 Jan 2016 00:38:53 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 AB9B61A1A62 for ; Thu, 21 Jan 2016 00:38:53 -0800 (PST) Received: by mail-qg0-x236.google.com with SMTP id b35so26393687qge.0 for ; Thu, 21 Jan 2016 00:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=WNf2GanSy6GKi8AoS9N2YPjOR3LRtxH1jTog/cD8pA4=; b=BXxNi06ZYgREXciDGwOaWppJ2/fT2BXkDrzUhkFsAR7cg8MfFzE896PLXdu7SVwNU5 Otuw/e/l+TGCGQ0APQX98hpQ4123/IJFxaPJHhrkGKkCBX70oaQYy4mCe5TWMOi9nrPe RLzZixvF3eiQLdpM50gu2TuCxdvEUn3M0OR1yZdRIVgwNGtTtxDt5d08Sf1MO6DAs25c 1MEZ70SdrMBe5U4NNO1LMQg6L4bPtGrElUDUSMth9CkWily/TpXrOH8UkUDMWbRD5dOF jUNqmCZOje2WzRtZF5N8rzLdVUZU03tPmHFbztioVX6kbMWJCJkFIO7iHOtdbH+Xv5+s 1T8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=WNf2GanSy6GKi8AoS9N2YPjOR3LRtxH1jTog/cD8pA4=; b=KCkfQsUyrgqSK4gyB/luJWmreWJVngMk4MwqgONvKszIZf4beZTv3kSTNDQCnrIGBq edNsf/JTMnKzm0r4l2TouBgKjh6h2hDzb2cRBGJYsrH7wj4GPSamUSsntpgF9sZTUdn0 E/Hvku7t0XikFBx/G4MqOQ4xJneveecScADruuvP1yqgE3Dm3nNjgAVy0tsBO+KZZXMP h4/pzwk2CGpc4/de46VgLTb4bQ6nOELMRZxUomaus2c0LaF3qSDSSm0TRMB3oTKPEkqb J+6YhtLTnNHXLh99FW+1HUNKoB+TUL7zDZfZ7wFrc21OJw4JOw0TaECk4zJUcmWntc8p h0FA== X-Gm-Message-State: AG10YOSVgP1iXfS5n49WnmYzpS4H5WYUVEN++99sCDraoPzQkIdQx9QrnRTNNYvD5BVdsZJcjHCrHZyqpKMvPQ== X-Received: by 10.140.22.139 with SMTP id 11mr43309479qgn.34.1453365532647; Thu, 21 Jan 2016 00:38:52 -0800 (PST) MIME-Version: 1.0 References: <569E22E1.5010402@gmx.net> <3663C301-FE1B-465C-B8FF-3BBF2F4C0A43@adobe.com> In-Reply-To: <3663C301-FE1B-465C-B8FF-3BBF2F4C0A43@adobe.com> From: Nat Sakimura Date: Thu, 21 Jan 2016 08:38:41 +0000 Message-ID: To: Antonio Sanso , Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c151e24d6abb0529d40807 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 08:38:57 -0000 --001a11c151e24d6abb0529d40807 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, re-reading, I have a bit of problem with the draft. It is defining a new concept 'issuer', which is not found in RFC6749, as the authorization server's configuration information location. It is returned in 'iss' authorization response parameter. On the other hand, there is an existing concept of 'issuer' for identifying the authorization server in OpenID Connect. e.g., Google's discovery document's URI is https://accounts.google.com/.well-known/openid-configuration and issuer in it is https://accounts.google.com . This value MUST exactly match the "iss" in ID Token. Unfortunately, this does not match the value of OAuth issuer defined in Section 2 of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as specified in 3.1. As such, validation as specified in bullet 1 of Section 4 fails in Google's case -- OR it means that the document is internally inconsistent. Also, I do not understand the value of OAuth issuer when there is no configuration file but everything is determined in the developer documentation. This is one of the assumption of RFC6749 and many OAuth servers are operated like that. Technically, since the discovery document does not exist, it is an empty string, which fails the validation rule set here. As to section 5 is concerned, I could not read out what threat it is trying to mitigate. Is it trying to address the case that the client is not doing a proper state check? From section 6, it seems it is trying to do the binding between the authorization request and the token request, but if that is the case, is it not better to just use PKCE than introducing something new? The draft-sakimura-oauth-meta-05 approach is similar, but it avoids these confusions. Instead of relying on 'issuer' concept, it uses token endpoint URI. Per discussion in Yokohama, the identifier that distinguishes the authorization server is the URI of the authorization endpoint uri. This is the trust anchor of the entire flow, and it exists even if the client is not using discovery of any kind. If you cannot trust this endpoint, everything breaks. Oauth-meta chains the trust through metadata step by step. In case of 'code' flow, the next step on the server side is the token endpoint uri. This is returned in a parameter called 'turi', a shorthand for token endpoint uri. The validation rule is that the client MUST check that turi and the token endpoint uri that is previously known to the client exactly matches. (Actually, a simpler way is just use the value returned in turi.) Then, the client sends the token request to turi. If additional security through authorization and token request binding, or making sure that the client instance is really the intended audience, then use PKCE [RFC7636]. The client_id parameter in draft-jones-oauth-mix-up-mitigation-01 does not help in the case of public client, but PKCE works. In addition, draft-sakimura-oauth-meta-05 [1] provides other goodies as well, such as HATEOAS. It achieves all these by the full use of RFC5988 and introducing very little new things. It is only one page! So, IMHO, the combination of draft-sakimura-oauth-meta-05 and RFC7636 seems to be a better solution. - It does not break the existing implementations; - It does not confuse the reader by defining two concepts of issuer depending on the context; - It works in the case that the configuration is done through the developer documentation. i.e., it does not require yet to be defined discovery spec. - It works for public client as well; - It enables HATEOAS - Yes. It makes OAuth finally RESTful!; There is one discussion point that I want to raise for oauth-meta. Currently, the authorization response metadata such as turi are returned as query parameters. This is to enable the dynamic reallocation of the endpoints, and adhere to the HATEOS principle. If you do not need this dynamism, then there is an alternative proposal that I have, that makes it extremely simple to implement for the server. In this case, the client just sends HEAD request to the authorization endpoint. Then the authorization endpoint returns 200 OK with turi in the header. e.g., HTTP/1.1 200 OK Link: ; rel=3D"turi", Content-Type: application/JSON; charset=3Dutf-8 This can be achieved without touching the authorization endpoint code, but just by configuration. In case of apache, use 'header append' in the apache configuration. If we take this course, then there is another advantage to be added: - You do not need to change the server code. Is it not attractive? Cheers, Nat Sakimura [1] https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 15:14 Antonio Sanso : > +1 for adoption > On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig > wrote: > > > Hi all, > > > > this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see > > https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 > > > > Please let us know by Feb 9th whether you accept / object to the > > adoption of this document as a starting point for work in the OAuth > > working group. > > > > Note: This call is related to the announcement made on the list earlier > > this month, see > > http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More > > time for analysis is provided due to the complexity of the topic. > > > > Ciao > > Hannes & Derek > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a11c151e24d6abb0529d40807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, re-reading, I have a bit of problem with the draft.= =C2=A0

It is defining a new concept 'issuer', wh= ich is not found in RFC6749, as the=C2=A0authorization server's configurat= ion=C2=A0information location. It is returned in 'iss' authoriz= ation response parameter. On the other hand, there is an existing concept o= f 'issuer' for identifying the authorization server in OpenID Conne= ct. e.g., Google's discovery document's URI is=C2=A0https:= //accounts.google.com/.well-known/openid-configuration=C2=A0and issuer = in it is=C2=A0https://a= ccounts.google.com . This value MUS= T exactly match the "iss" in ID Token.
Unfortunately, this does not match the= value of OAuth issuer defined in Section 2 of=C2=A0draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as specified in 3.1.=C2=A0A= s such, validation as specified in bullet 1 of Section 4 fails in Google= 9;s case -- OR it means that the document is internally inconsistent.

Also, I do not understand the val= ue of OAuth issuer when there is no configuration file but everything is de= termined in the developer documentation. This is one of the assumption of R= FC6749 and many OAuth servers are operated like that. Technically, since th= e discovery document does not exist, it is an empty string, which fails the= validation rule set here.

A= s to section 5 is concerned, I could not read out what threat it is trying = to mitigate. Is it trying to address the case that the client is not doing = a proper state check? From section 6, it seems it is trying to do the bindi= ng between the authorization request and the token request, but if that is = the case, is it not better to just use PKCE than introducing something new?=

The draft-sakimura-oauth-me= ta-05 approach is similar, but it avoids these confusions.
Instead of relying on 'issue= r' concept, it uses token endpoint URI. Per discussion in Yokohama, the= identifier that distinguishes the authorization server is the URI of the a= uthorization endpoint uri. This is the trust anchor of the entire flow, and= it exists even if the client is not using discovery of any kind.=C2=A0If y= ou cannot trust this endpoint, everything breaks. Oauth-meta chains the tru= st through metadata step by step.

In case of 'code' flow, the next step on the server side is t= he token endpoint uri. This is returned in a parameter called 'turi'= ;, a shorthand for token endpoint uri. The validation rule is that the clie= nt MUST check that turi and the token endpoint uri that is previously known= to the client exactly matches. (Actually, a simpler way is just use the va= lue returned in turi.)

Then,= the client sends the token request to turi. If additional security through= authorization and token request binding, or making sure that the client in= stance is really the intended audience, then use PKCE [RFC7636]. The client= _id parameter in draft-jones-oauth-m= ix-up-mitigation-01 does not help in the case of public client, but PKCE wo= rks.

In addition, dr= aft-sakimura-oauth-meta-05 [1] provides other goodies as well, such as = HATEOAS. It achieves all these by the full use of RFC5988 and introducing v= ery little new things. It is only one page! =

So, IMHO, the combination of draft-sakimu= ra-oauth-meta-05 and RFC7636 seems to be a better solution. <= /div>
  • It does not break the existing implemen= tations;
  • It does not confuse the read= er by defining two concepts of issuer depending on the context;
    =
  • It works in the case that the configuration is d= one through the developer documentation. i.e., it = does not require yet to be defined discovery spec.
  • It works for public client as well;
  • It enables HATEOAS - Yes. It makes OAuth finally RESTful!;
There is one discussion poi= nt that I want to raise for oauth-meta.
Currently, the authorization response metadata such as= turi are returned as query parameters. This is to enable the dynamic reall= ocation of the endpoints, and adhere to the HATEOS principle. If you do not= need this dynamism, then there is an alternative proposal that I have, tha= t makes it extremely simple to implement for the server. In this case, the = client just sends HEAD request to the authorization endpoint. Then the auth= orization endpoint returns 200 OK with turi in the header. e.g., 

 HTTP/1.1 200 OK
   Link: <https://example.com/toke=
n>; rel=3D"turi",
   Content-Type: application/JSON; charset=3Dutf-8

This can = be achieved without touching the authorization endpoint code, but just by c= onfiguration. In case of apache, use 'h= eader append' in the apache configuration. If we take this course, then= there is another advantage to be added:=C2=A0
  • You do not need to change the server code.
    • =
Is it not attractive?

Cheers,
<= span style=3D"font-size:13.3333px;line-height:normal;white-space:pre-wrap">=
Nat Sakimura



2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 15:14 Anto= nio Sanso <asanso@adobe.com>:=
+1 for adoption
On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> w= rote:

> Hi all,
>
> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
> https://tools.ietf.org/html/d= raft-jones-oauth-mix-up-mitigation-00
>
> Please let us know by Feb 9th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth > working group.
>
> Note: This call is related to the announcement made on the list earlie= r
> this month, see
> http://www.ietf.org/mail-archiv= e/web/oauth/current/msg15336.html. More
> time for analysis is provided due to the complexity of the topic.
>
> Ciao
> Hannes & Derek
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org=
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a11c151e24d6abb0529d40807-- From nobody Thu Jan 21 01:57:26 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C16C1A1EFC for ; Thu, 21 Jan 2016 01:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWNYVFIoZGTI for ; Thu, 21 Jan 2016 01:57:23 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3E61A1EFB for ; Thu, 21 Jan 2016 01:57:22 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id r129so164825747wmr.0 for ; Thu, 21 Jan 2016 01:57:22 -0800 (PST) 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-type:content-transfer-encoding; bh=mQeBMYjeyBf4q8RYYnEtQve/d9JbXSvmtrDwS6USgOg=; b=RXngwFMMbF+W1Bk3/xxYlw5LyZxoc8n+edqERUFVUBUE9QeujcVpQnKBIjxYfY3Gp/ DfQC9tU5LHtCwwqacgcTvZ6OYMNagoNru+Ecp+CsCTb+zCiLREEaNNBzMAGxzHGd6/eq LGpuMdfW5WxbWa2yGCa4Uox4crVCpPRpzyefcBOW7T4auScAp2cK91kO5L+Rfw7KvxTm vcMKA7ObiPjjai6BK+6if/Su77wR5Y0tb+I5LLaf1gOeGuXweKavRLxdko6RsJhb9dbV nwqD+SRbC/X68Tq/V9d6gEUa0U5rigri/rsbmqfRAx4RPXkz0U0DlF7h6EI45vd9NWOH YyyA== 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-type :content-transfer-encoding; bh=mQeBMYjeyBf4q8RYYnEtQve/d9JbXSvmtrDwS6USgOg=; b=Wy2uxA7Gx6z2R7I8QKcCTkzQRQIm8wyhE1NEWqoroxcX8vacYJKLjalC9UgOweVrlm RH/uEclXyaaGQnc4KsI/bMsZ4u0/l2iAJSznmVHdRaM4evK/+MwS4qCE6Ay/HyEy13L/ htgVMQwuEDFBBgY0KTDNCIQnSV+rF4ssHTvW0CfFDUGyHYzvTBBIRqWnjDfAIAUkoN/o Emrh9CUQ2UGg8dOXiSMF+nMIVpvg41AHn8t4t4GhcbF1WURv2PpMTkYh8UYAz2Ta/9RK vzbb4ATdwBRuHVmJ5FcDJCugE6q5tjZQI4srB1P8qwf2PNd+IvC5pSeDOjzCvfkTfI0s LxeQ== X-Gm-Message-State: AG10YOSHCAGCAEM/cDbD7fCEV94NHlY24jRH3MOFcy1H3/01PSwYNMQKY+1ho5awuJKizw== X-Received: by 10.194.174.129 with SMTP id bs1mr38543522wjc.13.1453370241494; Thu, 21 Jan 2016 01:57:21 -0800 (PST) Received: from [192.168.2.7] ([5.179.70.21]) by smtp.googlemail.com with ESMTPSA id df10sm608724wjb.44.2016.01.21.01.57.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 01:57:19 -0800 (PST) To: Hannes Tschofenig , oauth@ietf.org References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> <569F60B3.3030501@gmail.com> <569F9955.9030001@gmx.net> From: Sergey Beryozkin Message-ID: <56A0AB7F.8060806@gmail.com> Date: Thu, 21 Jan 2016 09:57:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <569F9955.9030001@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 09:57:25 -0000 Hi Hannes, thanks for supporting it, I agree the audience concept is not tied to the PoP work Cheers, Sergey On 20/01/16 14:27, Hannes Tschofenig wrote: > Hi Sergey, > > that's a good question. After this document was published the > functionality had been integrated into the PoP solution document. > Recently, I got feedback that the functionality should be more generic > and it is independent of the PoP work. > > So, I guess it is a good time to discuss the needed functionality and > where it should be included. > > Ciao > Hannes > > > On 01/20/2016 11:25 AM, Sergey Beryozkin wrote: >> Hi >> >> Given that the draft-tschofenig-oauth-audience [1] has expired, I'm >> wondering if it is still relevant. >> >> I know the token introspection response can provide the audience >> value(s), but the question is really how a client is associated with a a >> given audience in the first place. As such [1] may still make sense, for >> example, I can think of two options: >> 1. the client audiences are set out of band during the client >> registration time and all the tokens issued to that client will be >> restricted accordingly >> 2. the client is requesting a specific audience during the grant to >> token exchange as per [1] >> >> I guess 1. is how it is done in practice or is 2. is also a valid option ? >> >> >> Thanks, Sergey >> >> >> [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > From nobody Thu Jan 21 02:05:09 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03B31A21AC for ; Thu, 21 Jan 2016 02:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aNoE1JT4vaQ for ; Thu, 21 Jan 2016 02:05:06 -0800 (PST) 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 E14841A1EFD for ; Thu, 21 Jan 2016 02:05:05 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id l65so212983832wmf.1 for ; Thu, 21 Jan 2016 02:05:05 -0800 (PST) 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-type:content-transfer-encoding; bh=2FSiGM+JXmRa8cmzR7iRRiUrOAkYiYh0WlH+8YVpaHs=; b=yuMJLNTn0QDPU9Q+pXbV/MnYW05arcPmAtISN5jNhfMpeirywf8+R78yl0vGSNhrig X4rl3vu8rzeU2otBYjAQbCBO/3J6bY/nLzAqXj5Gwcs4S6fJiz185dKa3QLzdNk/semT Z3Dex7YNzfV2lkGSyXYUGLG0AXV3OM28rNUnamc06CAnDl5yo5ToSFMWBevJjVG3p7Oy FjPyyRx5WkWtaxuYvq3tKJP+wq90vn1BZvT52wt03br1+Rb7Y7vaTHQeifxq0Yxltxup Xhs4QLui24pJm/doMvXYutqsPpiYkIbKoXqQOHKqRaXgUi+c3kfGQTTB52+PP3iU6JZo k63Q== 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-type :content-transfer-encoding; bh=2FSiGM+JXmRa8cmzR7iRRiUrOAkYiYh0WlH+8YVpaHs=; b=PVHLwbgx/LSczRVK5V/iG/a3ZTzFOdVjKjbARzdG3/foT9AXSKvdDA65ROljPPz94q wrc2G+SfxcCxD7yuEvntKqmE4wologIJgTqjJrU5paIKmhPKV/22U3/3hAWR7F4560wG FVWEUWKq6gcaNzHaFPS/uzc6PiuGw84QE1fIe4+PfuhJxNjrA3B0ldVc4xzZ50E9xcPV UqH2wVZug6uBqTc5JA9oUfAz4yYhJ7ikvZy+zdYJCVdF1yKCp98PBr/xVHUhN/oHc/jA P6a8qyy0tpFXqoeViLEO4FhDNlx8xmdjDMn6Necm8fIbpd40wkGQ+Cx9npCMV9JOcG6A Do+A== X-Gm-Message-State: AG10YOQWzenrdVV7U8zImgG3Mq4GqzeaxbKRyG+sES+CDom0gl9y3irtm+zcyRF3JyJ6/g== X-Received: by 10.28.175.147 with SMTP id y141mr8799781wme.64.1453370704449; Thu, 21 Jan 2016 02:05:04 -0800 (PST) Received: from [192.168.2.7] ([5.179.70.21]) by smtp.googlemail.com with ESMTPSA id g3sm662036wjw.31.2016.01.21.02.05.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 02:05:03 -0800 (PST) To: Brian Campbell , Hannes Tschofenig References: <5CA9073D-BBF7-48BD-BEC5-1F626E8C3818@mit.edu> <8EB68572-DA59-482D-A660-FA6D9848AAD2@oracle.com> <5698CB3D.1030306@gmail.com> <69B0E23E-818A-4FE4-81A0-A8106EB6C312@ve7jtb.com> <5698F885.3030009@gmail.com> <569A69A5.7020006@connect2id.com> <569ABB30.9060703@gmail.com> <569D0AE6.3060708@mit.edu> <569D0E86.60908@gmail.com> <569D1297.2000805@mit.edu> <569D1631.4030705@gmail.com> <569E1804.8010803@gmail.com> <569F60B3.3030501@gmail.com> <569F9955.9030001@gmx.net> From: Sergey Beryozkin Message-ID: <56A0AD4E.9050301@gmail.com> Date: Thu, 21 Jan 2016 10:05:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: oauth Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 10:05:07 -0000 Hi Brian In our own code both authorization code and implicit flow requests can accommodate an audience property too. You are right in the latter case there won't be a separate request to a token endpoint hence we are treating what follows after the user has authorized the implicit client as if it were a token endpoint request. Not sure about using the audience property in the code flow but I guess it can be useful too - for example, the user may be shown this property, and then when the client requests a token and happens to supply an audience property alongside the code then this audience will have to match the one stored in the code grant data... Cheers, Sergey On 20/01/16 22:18, Brian Campbell wrote: > There does seem to be a need to provide the client a means of telling > the AS the place(s) and/or entity(s) where it intends to use the token > it's asking for. And that it's common enough to warrant it's own small > spec. This has come up several times before and I think has some > consensus behind doing it. What needs to happen to move forward? > > The concept shows up in these three different drafts (that I know of > anyway): > > https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 > has an audience parameter > https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3 > has an aud parameter > http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 has > both an audience and a resource resource > > All the above apply only to the token request. However, there are ways > of requesting/obtaining access tokens that don't involve the token > endpoint so I think it > follows that the same facility should be available for the > authorization request too. > > > > > On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig > > wrote: > > Hi Sergey, > > that's a good question. After this document was published the > functionality had been integrated into the PoP solution document. > Recently, I got feedback that the functionality should be more generic > and it is independent of the PoP work. > > So, I guess it is a good time to discuss the needed functionality and > where it should be included. > > Ciao > Hannes > > > On 01/20/2016 11:25 AM, Sergey Beryozkin wrote: > > Hi > > > > Given that the draft-tschofenig-oauth-audience [1] has expired, I'm > > wondering if it is still relevant. > > > > I know the token introspection response can provide the audience > > value(s), but the question is really how a client is associated > with a a > > given audience in the first place. As such [1] may still make > sense, for > > example, I can think of two options: > > 1. the client audiences are set out of band during the client > > registration time and all the tokens issued to that client will be > > restricted accordingly > > 2. the client is requesting a specific audience during the grant to > > token exchange as per [1] > > > > I guess 1. is how it is done in practice or is 2. is also a valid > option ? > > > > > > Thanks, Sergey > > > > > > [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 > > > > _______________________________________________ > > 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 Thu Jan 21 03:47:33 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17941A8A76 for ; Thu, 21 Jan 2016 03:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izavv5pPcndE for ; Thu, 21 Jan 2016 03:47:30 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C6D1A8A6B for ; Thu, 21 Jan 2016 03:47:30 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id 123so170647363wmz.0 for ; Thu, 21 Jan 2016 03:47:30 -0800 (PST) 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-type:content-transfer-encoding; bh=rGosaEtsoFSbg1zndHaIrNPsmJmP1vseEjXa/7Yp4+Q=; b=hGZ7F39fwJ3CB65YL6Fnc6Q6DKm7immqRhO7WQXACf3V5G6pXla3ahK9wMhYd4HLgi 6QVD5w4wzYg/GejF8eeonMlFbICWE4Qb8eD/b2AnI9TYvdFlJV/oZNAwG1E9glWrW9+H buFDX1tkRA1ftgwPe3Bw1JfkuAVzocgBSsNRS4t57+mCn5E1qtsnKSE7X+cjAY8s97Ww 94Ar85xrKm7GFKgnmHaSVb0jBvveSsNhS716UvLUi8VCCnp6DuT3IgHNGC1gBpFYspjB ILALFF+5LDEZ7lfb8TUE1+54ZR5rZNkX5Xik0hdaKRQpfFuTSo3VnoqO5BpPPcgwfkhy /KtQ== 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-type :content-transfer-encoding; bh=rGosaEtsoFSbg1zndHaIrNPsmJmP1vseEjXa/7Yp4+Q=; b=BDaysOXL+aA4CZ9XzucNeiLM5c2mESqlcLAB31BZIS/2Orz3Q46k8kKPccUjvvAhem WKdozyWkBn2R/OcMBt6dACIVEqxNSuSY9DVGDvCndgc5vm1h0aFfmagR2rgnOPmvPwlS Wp39jte8i3YoEMTOrJUN2B9VVhf550RT+mo//wTju7GDqSPzt21zvrMc4d4F4g3UEcfj ni5Bk/l6d/G9rz6PCFzMRGRYFy+ey1i1SVTZnIJBTZ9OItMY1U98blV07grl/Ra0zP+y lqnPYhg7juT4KNBoK+llcg61wPlZfc91WPfYuqt7SjYkwAHGYRt5ZQF2Jhfcjsvxaner 3Mqg== X-Gm-Message-State: ALoCoQkmu2Ctq5TG8GYAGvsK501TaIPXkge+5omggs/PiKudAxSnwarRaaEgd+jCk/c5zwQLysaksSArJo1sj+6R4ZKYFaErAg== X-Received: by 10.194.158.73 with SMTP id ws9mr47457446wjb.40.1453376848854; Thu, 21 Jan 2016 03:47:28 -0800 (PST) Received: from [192.168.2.7] ([5.179.70.21]) by smtp.googlemail.com with ESMTPSA id yz5sm1078416wjc.36.2016.01.21.03.47.27 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 03:47:27 -0800 (PST) To: oauth@ietf.org References: <5693F276.8020501@aol.com> From: Sergey Beryozkin Message-ID: <56A0C54F.7080501@gmail.com> Date: Thu, 21 Jan 2016 11:47:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 11:47:32 -0000 Hi On 11/01/16 19:59, Mike Jones wrote: > The alternatives for the code flow are to return them either in a new > JWT added to the reply containing them in the “iss” and “aud” claims or > to return them in new individual “client_id” and “iss” authorization > response parameters. Both alternatives are described in the draft. I’m > sure that we’ll now be having a good engineering discussion on the > tradeoffs between the alternatives., > > In a separate draft, John Bradley will shortly also be describing the > possibility of securing the “state” value using a “state_hash” value > that works in a way that’s similar to how “at_hash” and “c_hash” secure > the “access_token” and “code” values in Connect. This would be an > alternative means of binding the authorization request and response to > the session – accomplishing the same thing that the Connect “nonce” does. > > While I fully get that some OAuth implementations want to avoid having > to have crypto, it seems like at least support for cryptographic hashing > (SHA-256, etc.) may be necessary to mitigate some of these attacks (at > least for clients that use more than one authorization server). > I'm not sure if it is relevant or misses the point, if so then my apologies, but I guess it is +1 to the *optional* hashing of the *whole* response as opposed to of some individual response properties. Awhile back I posted some proposal to use a JWK thumbprint idea to calculate a thumbprint of the response and sign in and include the result of it as an extra response property. Cheers, Sergey > The other important engineering discussion I know we’re going to have is > whether, when an OAuth profile already returns the information needed > for the mitigation, whether we want to specify that the client obtain it > from the existing location, or whether to also return it in a duplicate > location. I’ll note that OpenID Connect already returns the client ID > and issuer for the flows that return an ID Token in the authorization > response, so this isn’t a hypothetical question. > > Finally, I know that we’ll need to discuss the impact of cut-and-paste > attacks when the issuer and client ID are returned as individual > authorization response parameters that are not cryptographically bound > to the rest of the response. The cut-and-paste attack that returning the > issuer and client_id values as separate parameters enables, even when > state_hash or nonce is used, is for the attacker to capture the > legitimate response containing “iss” and “client_id” results and > substitute different values for these fields, then post that altered > response to the legitimate client. The state and/or nonce values are > protected against substitution but “iss” and “client_id” are not. > > And yes, I absolutely agree that good examples are essential. That’s > high on my list for the -01 version. > > Thanks a bunch, > > -- Mike > > *From:*George Fletcher [mailto:gffletch@aol.com] > *Sent:* Monday, January 11, 2016 10:21 AM > *To:* Mike Jones ; oauth@ietf.org > *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation > > Thanks Mike. One question after reading about the different attack > vectors and this spec... > > How are the 'iss' and 'aud' values returned with the 'code' and 'state' > parameters. It seems the client needs to verify the endpoints before > making the request to exchange the code for a token. If the client is > using the default OAuth2 client_id and client_secret these values will > be sent to the malicious endpoint if the client can't verify the > endpoints before hand. > > Also, it would be nice to add some non-normative examples to the spec. > > Thanks, > George > > On 1/11/16 4:27 AM, Mike Jones wrote: > > Yesterday Hannes Tschofenig announced an OAuth Security Advisory on > Authorization Server Mix-Up > . > This note announces the publication of the strawman OAuth 2.0 Mix-Up > Mitigation draft he mentioned that mitigates the attacks covered in > the advisory. The abstract of the specification is: > > This specification defines an extension to The OAuth 2.0 > Authorization Framework that enables an authorization server to > provide a client using it with a consistent set of metadata about > itself. This information is returned in the authorization response. > It can be used by the client to prevent classes of attacks in which > the client might otherwise be tricked into using inconsistent sets > of metadata from multiple authorization servers, including > potentially using a token endpoint that does not belong to the same > authorization server as the authorization endpoint used. Recent > research publications refer to these as "IdP Mix-Up" and "Malicious > Endpoint" attacks. > > The gist of the mitigation is having the authorization server return > the client ID and its issuer identifier (a value defined in the > OAuth Discovery specification ) so > that the client can verify that it is using a consistent set of > authorization server configuration information, that the client ID > is for that authorization server, and in particular, that the client > is not being confused into sending information intended for one > authorization server to a different one. Note that these attacks > can only be made against clients that are configured to use more > than one authorization server. > > Please give the draft a quick read and provide feedback to the OAuth > working group. This draft is very much a starting point intended to > describe both the mitigations and the decisions and analysis > remaining before we can be confident in standardizing a solution. > Please definitely read the Security Considerations and Open Issues > sections, as they contain important information about the choices > made and the decisions remaining. > > Special thanks go to Daniel Fett (University of Trier), Christian > Mainka (Ruhr-University Bochum), Vladislav Mladenov (Ruhr-University > Bochum), and Guido Schmitz (University of Trier) for notifying us of > the attacks and working with us both on understanding the attacks > and on developing mitigations. Thanks too to Hannes Tschofenig for > organizing a meeting on this topic last month and to Torsten > Lodderstedt and Deutsche Telekom for hosting the meeting. > > The specification is available at: > > ·http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 > > An HTML-formatted version is also available at: > > ·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html > > -- Mike > > P.S. This note was also posted at http://self-issued.info/?p=1524 > and as @selfissued . > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > > Chief Architect > > Identity Services Engineering Work:george.fletcher@teamaol.com > > AOL Inc. AIM: gffletch > > Mobile: +1-703-462-3494 Twitter:http://twitter.com/gffletch > > Office: +1-703-265-2544 Photos:http://georgefletcher.photography > > > > _______________________________________________ > 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 Jan 21 04:18:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AAF1B2B6C for ; Thu, 21 Jan 2016 04:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lKNY8Tw7u8A for ; Thu, 21 Jan 2016 04:18:13 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43DCB1B2AF7 for ; Thu, 21 Jan 2016 04:18:12 -0800 (PST) X-AuditID: 1209190f-f79d06d000004b20-b5-56a0cc82306c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 7E.E0.19232.28CC0A65; Thu, 21 Jan 2016 07:18:10 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u0LCI9vr018955; Thu, 21 Jan 2016 07:18:09 -0500 Received: from [192.168.128.48] (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 u0LCI7KS031541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jan 2016 07:18:08 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_E36CC059-538A-4BBA-BEF3-262DF7CD4440" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Justin Richer In-Reply-To: Date: Thu, 21 Jan 2016 07:18:07 -0500 Message-Id: References: <569E2076.2090405@gmx.net> <569F915D.8020806@mit.edu> To: Mike Jones X-Mailer: Apple Mail (2.2104) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsUixCmqrdt0ZkGYwaTVMhZ7p31isTj59hWb xZlbKxgtNs1pZndg8dg56y67x4JNpR5Llvxk8mjd8Zc9gCWKyyYlNSezLLVI3y6BK2PGopXM BcsPMlUcfvmPpYFx70ymLkZODgkBE4kZt78zQ9hiEhfurWfrYuTiEBJYzCTxftZzZghnI6PE pq8L2CGc20wSS+fvYAdpYRZIkLjypRPM5hXQk3h16zIriC0soCmx/+4bFhCbTUBVYvqaFrB1 nALREvdeXmIEsVmA4iuXL2KBmFMl8WjWcTaIOVYSN75eYIFY9plZoqPtK1hCREBH4vHFb2wQ t8pK7P79iGkCo8AsJHfMQnIHRFxbYtnC18wQNtBN3ctZMMU1JDq/TWRdwMi2ilE2JbdKNzcx M6c4NVm3ODkxLy+1SNdELzezRC81pXQTIzg+JPl3MH47qHSIUYCDUYmH98a1+WFCrIllxZW5 hxglOZiURHmrjywIE+JLyk+pzEgszogvKs1JLT7EKMHBrCTCe/sEUI43JbGyKrUoHyYlzcGi JM67q2NumJBAemJJanZqakFqEUxWhoNDSYJX4zRQo2BRanpqRVpmTglCmomDE2Q4D9DwE6dA hhcXJOYWZ6ZD5E8xKkqJ87KCNAuAJDJK8+B6Qekr4e1h01eM4kCvCPM2gFTxAFMfXPcroMFM QIP3ms0HGVySiJCSamCc2ufny8u8WG55inlEblh/2bRZc+Oz3+w8v/nl/zO8p3kDjvrZ5PyS y7Bomrqo1/vbwoC1xTU29dUTP/g6MP26/bK8XaDBeg7Dv0b2qu7oK3c3aru4PmwPCJXVrD50 LtaMq1Rzp3fy/T9MMdzPtIMmN/zcWsRwzT7odbXRYbUFLBul3hd2ZimxFGckGmoxFxUnAgBl n/mqOgMAAA== Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 12:18:18 -0000 --Apple-Mail=_E36CC059-538A-4BBA-BEF3-262DF7CD4440 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Convergence is exactly what I=E2=80=99m arguing for, though. These = things ought to work together. =E2=80=94 Justin > On Jan 21, 2016, at 2:55 AM, Mike Jones = wrote: >=20 > My memory of the discussions of the oauth-meta draft in Yokohama were = that many people felt that it was unnecessarily dynamically duplicating = a lot of information that the client already had. Most of us that were = aware of the attacks then were in favor of a more targeted, minimal = approach. You were listened to in Yokohama, but that didn=E2=80=99t = necessarily mean that people agreed with the approach. Participants = were already aware of the oauth-meta proposal in Darmstadt but no one = spoke up in favor of it that I can recall. Rather, I think people were = thinking that =E2=80=9Cless is more=E2=80=9D. > =20 > There have also been discussions in the last day about how dynamically = returning a resource URL, which oauth-meta does, is both unnecessary = (since the client initiated the resource authorization already knowing = what resource it wants to access) and often problematic, since many = authorization servers can authorize access to multiple resources. If = anything, the client should be telling the authorization server what = resource it wants to access =E2=80=93 not the other way around. > =20 > I=E2=80=99m not saying that there aren=E2=80=99t some good ideas in = the oauth-meta draft =E2=80=93 I=E2=80=99m sure there are, just as there = are in the approach designed by the participants in Darmstadt. While I = volunteered to write the first draft of the mix-up-mitigation approach, = it really reflects something a lot of people have already bought into = =E2=80=93 as evidenced in the passion in the high-volume =E2=80=9CMix-Up = About The Mix-Up Mitigation=E2=80=9D thread, and not just my personal = project. > =20 > If you think there are things missing or wrong in the = mix-up-mitigation draft, please say what they are. That will help us = quickly converge on a solution that will work for everyone. > =20 > Sincerely, > -- Mike > =C2=A0 <> > From: Nat Sakimura [mailto:sakimura@gmail.com]=20 > Sent: Wednesday, January 20, 2016 11:17 PM > To: Mike Jones ; William Denniss = ; Justin Richer > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Call for Adoption > =20 > Hi Mike.=20 > =20 > Conversely, I would like to ask why this approach does not work for = Mix-up attack. As Nov stated, we in fact have discussed the approach in = quite a length back in Yokohama. I really would like to know why it does = not work.=20 > =20 > Besides, for oauth-meta approach, mix-up attack is only one of the = thing it solves.=20 > =20 > Nat Sakimura > =20 > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones = >: > Not to be negative, but I disagree with adopting = draft-sakimura-oauth-meta. We should define and promote one mitigation = approach to the mix-up attacks. Having two would confuse implementers = and cause compatibility problems =E2=80=93 reducing overall security. > =20 > The approach defined in draft-jones-oauth-mix-up-mitigation was = created in collaboration with the security researchers who identified = the problems in the first place, was vigorously discussed in the = security meeting Hannes and Torsten held in Darmstadt, and has been = since refined based on substantial input from the working group. And at = least three implementers have already stated that they=E2=80=99ve = implemented it. I=E2=80=99m not saying that it=E2=80=99s, but if there = are things missing or things that need to be improved in our approach, = we should do it there, rather introducing a competing approach. > =20 > Also, standard OAuth deployments register the client and then use the = information gathered at registration time for subsequent protocol = interactions. They do not need all the configuration information for = the authorization server to be retransmitted at runtime. The oauth-meta = draft goes too far in that direction, at least as I see it. Returning = things two ways creates its own problems, as discussed in the Duplicate = Information Attacks security considerations section (7.2) of the = mix-up-mitigation draft. > =20 > I=E2=80=99ll note that the mix-up-mitigation approach is compatible = with existing practice in both static and dynamic metadata discovery. = Replying to Justin=E2=80=99s comment that =E2=80=9CIt's the = pre-configured discovery document that's at the root of the mix-up = attack in the first place=E2=80=9D =E2=80=93 this is not the case. The = attacks can be performed without either discovery or dynamic = registration. > =20 > I would be interested in hearing a technical discussion on whether = there are aspects of the oauth-meta approach that mitigate aspects of = the attacks that the mix-up-mitigation approach does not. That could = help inform whether there are additional things we should add to or = change in the mix-up draft. > =20 > -- Mike > =C2=A0 <> > From: OAuth [mailto:oauth-bounces@ietf.org = ] On Behalf Of William Denniss > Sent: Wednesday, January 20, 2016 10:37 PM > To: Justin Richer > > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Call for Adoption > =20 > +1 to adopt this, and I agree with Justin's comments. > =20 > On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer > wrote: > +1 >=20 > Inline discovery and pre-configured discovery (ie, .well-known) should = at the very least be compatible and developed together. It's the = pre-configured discovery document that's at the root of the mix-up = attack in the first place. >=20 > -- Justin > =20 >=20 > On 1/19/2016 10:30 PM, Nat Sakimura wrote: > Just to give more context, at IETF 94, I have done a presentation on = discovery.=20 > =20 > According to the minutes,=20 > =20 > (f) Discovery (Nat) > =20 > Nat explains his document as an example of the work that = has to be done > in the area of discovery, which is a topic that has been = identified > as necessary for interoperability since many years but so = far there > was not time to work on it. Mike, John and Nat are = working on a new > document that describes additional discovery-relevant = components. > =20 > Poll: 19 for / zero against / 4 persons need more = information. > =20 > The document discussed there was = https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 = . This is a = simple (only 1-page!) but a very powerful document that nudges towards = HATEOAS which is at the core of RESTful-ness. It also mitigates the = Mix-up attack without introducing the concept of issuer which is not in = RFC6749. It is also good for selecting different endpoints depending on = the user authentication and authorization results and more privacy = sensitive than pre-announced Discovery document. It also allows you to = find to which protected resource endpoint you can use the access token = against.=20 > =20 > In the last sentence of the minutes, it talks about "a new document = that describes additional discovery-relevant components". This is = https://tools.ietf.org/html/draft-jones-oauth-discovery-00 = . It went = for the call for adoption. However, it is only a half of the story. I = believe https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 = that was = discussed at IETF 94 and had support there should be adopted as well.=20 > =20 > Nat Sakimura > =20 > =20 > =20 > =20 > 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura = >: > Thanks Hannes.=20 > =20 > I did not find = https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 = , which was = discussed in Yokohama, and was largely in agreement if my recollection = is correct. Why is it not in the call for adoption?=20 > =20 > =20 > =20 > 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig = >: > Hi all, >=20 > we have submitted our new charter to the IESG (see > http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html = ) and > since some IESG members like to see an updated list of milestones as > well. For this reason, based on a suggestion from Barry, we are also > starting a call for adoption concurrently with the review of the = charter > text by the IESG. >=20 > We will post separate mails on the individual documents. Your feedback > is important! Please take the time to look at the documents and = provide > your feedback. >=20 > Ciao > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_E36CC059-538A-4BBA-BEF3-262DF7CD4440 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Convergence is exactly what I=E2=80=99m arguing for, though. = These things ought to work together.

 =E2=80=94 Justin

On Jan 21, 2016, at 2:55 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:

My memory of the discussions of the oauth-meta = draft in Yokohama were that many people felt that it was unnecessarily = dynamically duplicating a lot of information that the client already had.  Most of us that were aware of the = attacks then were in favor of a more targeted, minimal approach.  = You were listened to in Yokohama, but that didn=E2=80=99t necessarily = mean that people agreed with the approach.  Participants were = already aware of the oauth-meta proposal in Darmstadt but no one spoke up in = favor of it that I can recall.  Rather, I think people were = thinking that =E2=80=9Cless is more=E2=80=9D.

 

There have also been discussions in the last day = about how dynamically returning a resource URL, which oauth-meta does, = is both unnecessary (since the client initiated the resource authorization already knowing what resource it = wants to access) and often problematic, since many authorization servers = can authorize access to multiple resources.  If anything, the = client should be telling the authorization server what resource it wants to access =E2=80=93 not the other way around.

 

I=E2=80=99m not saying that there aren=E2=80=99t = some good ideas in the oauth-meta draft =E2=80=93 I=E2=80=99m sure there = are, just as there are in the approach designed by the participants in Darmstadt.  While I volunteered to write the first draft of the = mix-up-mitigation approach, it really reflects something a lot of people = have already bought into =E2=80=93 as evidenced in the passion in the = high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D thread, and not just my personal project.

 

If you think there are things missing or wrong in = the mix-up-mitigation draft, please say what they are.  That will = help us quickly converge on a solution that will work for everyone.

 

          &nb= sp;            = ;            &= nbsp;           &nb= sp;          Sincerely,

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

 

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, January 20, 2016 11:17 PM
To: Mike Jones <Michael.Jones@microsoft.com>; William Denniss <wdenniss@google.com>; Justin Richer <jricher@mit.edu>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption

 

Hi Mike. 

 

Conversely, I would like to ask = why this approach does not work for Mix-up attack. As Nov stated, = we in fact have discussed the approach in quite a length back in = Yokohama. I really would like to know why it does not work. 

 

Besides, for oauth-meta approach, = mix-up attack is only one of the thing it solves. 

 

Nat Sakimura

 

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones <Michael.Jones@microsoft.com>:

Not to be negative, but I disagree with adopting = draft-sakimura-oauth-meta.  We should define and promote one mitigation approach to the mix-up attacks.  Having two would = confuse implementers and cause compatibility problems =E2=80=93 reducing = overall security.

 

The approach defined in = draft-jones-oauth-mix-up-mitigation was created in collaboration with = the security researchers who identified the problems in the first place, was = vigorously discussed in the security meeting Hannes and Torsten held in = Darmstadt, and has been since refined based on substantial input from = the working group.  And at least three implementers have already stated that they=E2=80=99ve implemented it.  I=E2=80=99= m not saying that it=E2=80=99s, but if there are things missing or = things that need to be improved in our approach, we should do it there, = rather introducing a competing approach.

 

Also, standard OAuth deployments register the = client and then use the information gathered at registration time for subsequent protocol interactions.  They do not need all = the configuration information for the authorization server to be = retransmitted at runtime.  The oauth-meta draft goes too far in = that direction, at least as I see it.  Returning things two ways creates its own problems, as discussed in the Duplicate Information = Attacks security considerations section (7.2) of the mix-up-mitigation = draft.

 

I=E2=80=99ll note that the mix-up-mitigation = approach is compatible with existing practice in both static and dynamic metadata discovery.  Replying to Justin=E2=80=99s comment = that =E2=80=9CIt's the pre-configured discovery document that's = at the root of the mix-up attack in the first place=E2=80=9D =E2=80=93 this is not the case.  The attacks can be performed without either = discovery or dynamic registration.

 

I would be interested in hearing a technical = discussion on whether there are aspects of the oauth-meta approach that mitigate aspects of the attacks that the = mix-up-mitigation approach does not.  That could help inform = whether there are additional things we should add to or change in the = mix-up draft.

 

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

 

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of William Denniss
Sent: Wednesday, January 20, 2016 10:37 PM
To: Justin Richer <jricher@mit.edu>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption

 

+1 to adopt = this, and I agree with Justin's comments.

 

On Wed, Jan = 20, 2016 at 9:53 PM, Justin Richer <jricher@mit.edu> wrote:

+1

Inline discovery and pre-configured discovery (ie, .well-known) should = at the very least be compatible and developed together. It's the = pre-configured discovery document that's at the root of the mix-up = attack in the first place.

 -- Justin

 

On = 1/19/2016 10:30 PM, Nat Sakimura wrote:

Just to = give more context, at IETF 94, I have done a presentation on = discovery. 

 

According = to the minutes, 

 

    (f) Discovery (Nat)
          =

          &nb=
sp;  Nat explains his document as an example of the work that =
has to be done
          &nb=
sp;  in the area of discovery, which is a topic that has been =
identified
          &nb=
sp;  as necessary for interoperability since many years but so far =
there
          &nb=
sp;  was not time to work on it. Mike, John and Nat are working on =
a new
          &nb=
sp;  document that describes additional discovery-relevant =
components.
          =

          &nb=
sp;  Poll: 19 for / zero against / 4 persons need more =
information.
 

The = document discussed there was https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a = simple (only 1-page!) but a very powerful document that nudges towards = HATEOAS which is at the core of RESTful-ness. It also mitigates the = Mix-up attack without introducing the concept of issuer which is not in RFC6749. It is also good for selecting = different endpoints depending on the user authentication and = authorization results and more privacy sensitive than pre-announced = Discovery document. It also allows you to find to which protected resource endpoint you can use the access token against. 

 

In the last = sentence of the minutes, it talks about "a new document that describes = additional discovery-relevant components". This is https://tools.ietf.org/html/draft-jones-oauth-discovery-00.=   It went for the call for adoption. However, it is only a half of the = story. I believe https://tools.ietf.org/html/draft-sakimura-oauth-meta-05&nb= sp;that was discussed at IETF 94 and had support there should be adopted as well. 

 

Nat = Sakimura

 

 

 

 

2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura <sakimura@gmail.com>:

Thanks = Hannes. 

 

I did not = find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05,&n= bsp;which was discussed in Yokohama, and was largely in agreement if my recollection is = correct. Why is it not in the call for adoption? 

 

 

 

2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:

Hi all,

we have submitted our new charter to the IESG (see
http://www.ietf.org/mail-archive/web/oauth/current/msg15379.htm= l) and
since some IESG members like to see an updated list of milestones as
well. For this reason, based on a suggestion from Barry, we are also
starting a call for adoption concurrently with the review of the = charter
text by the IESG.

We will post separate mails on the individual documents. Your = feedback
is important! Please take the time to look at the documents and = provide
your feedback.

Ciao
Hannes & Derek

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

 

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

 


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

 

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


= --Apple-Mail=_E36CC059-538A-4BBA-BEF3-262DF7CD4440-- From nobody Thu Jan 21 06:04:15 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3811A87D9 for ; Thu, 21 Jan 2016 06:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY8LhJzkjigE for ; Thu, 21 Jan 2016 06:04:11 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::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 4DC9F1A87D7 for ; Thu, 21 Jan 2016 06:04:11 -0800 (PST) Received: by mail-yk0-x22b.google.com with SMTP id k129so49093532yke.0 for ; Thu, 21 Jan 2016 06:04:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kfa/4330G8m/isQAAlLhi19K0fXqNTDOwj8lHBbDSk4=; b=jPpjon2T4hhgzl6Qh0ZVaPkgL9rvrC5z/boP/XnV5+0TZq1+tZCkeMfn8wWZDP6fBQ CJuuTE78kh+F0tO0FXvcXtUQPxCDi/6MErv2O/edKmO2P4ez6terLJ2JbFidt/pdE7IZ fniiQqwcIlpaNcY/rlyw67MKEEqnibJnpnqHFic2x+XBTMlIIBJEi7hQ7v9OkpH9Pqe2 4Y8PoL+6LBP0ur0dzuBdjlm29HyUh8zhUgBpkLdEeCjUfOkGAMDbxSA/Aj93BYo5QKR1 Afotp7bZLNCdP/BDRPJAvkCy1jlWfvhufepTGjlJI5MzBey1RO+/r/jPdwQJjg7k0Nof ROWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kfa/4330G8m/isQAAlLhi19K0fXqNTDOwj8lHBbDSk4=; b=OkK8Ca7iu2DtJxAO2/NMvxFvQs8ZUU7/2l/zRJ9L9n2rffrLvmhadI8XT+t6eEfwKh bC1y5fizQq4yZp/X8krkBxFGEgY63XWSV5WyAxQ98z/OOtZOPCL6861YDdFHa7CzoMZD MFP3P7Wzev9zuhauOPOPV3wH2aHFuXkKutU2P0eEePRqKElsSeDYoqJF5qWbkwBwujjW LfaNSuUfS6hzIr9ZHA7CjBRd2ZCAjcBFZlMkLGYPp8aNoSXYRFA/D87KoOtBDfZWtqsX A8IdP1KV+6FO8Mb2mgY8ugJohhlowiEQt2I3YD0jcvF9MtUds2V9aPE5J/HilYDpt361 yMcA== X-Gm-Message-State: ALoCoQnnFrFnxUqhPd3EG2bOjoPgUoq68I1FqgjvesKx+LLavqqBHG7TrcHpZ4gogarcLzLRhNc+9K3PjJNM0egv4TqzBBYNuw== MIME-Version: 1.0 X-Received: by 10.37.82.8 with SMTP id g8mr14085792ybb.91.1453385050536; Thu, 21 Jan 2016 06:04:10 -0800 (PST) Received: by 10.37.224.84 with HTTP; Thu, 21 Jan 2016 06:04:10 -0800 (PST) Received: by 10.37.224.84 with HTTP; Thu, 21 Jan 2016 06:04:10 -0800 (PST) In-Reply-To: <569E22E1.5010402@gmx.net> References: <569E22E1.5010402@gmx.net> Date: Thu, 21 Jan 2016 09:04:10 -0500 Message-ID: From: Josh Mandel To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11c157daa8c46c0529d893e4 Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:04:14 -0000 --001a11c157daa8c46c0529d893e4 Content-Type: text/plain; charset=UTF-8 Apologies if this is the wrong forum for my comment (and please direct me to the appropriate place in that case), but I have two questions about the propose mitigation (and the thinking behind it) that I think the write-up could address: 1. Could the writeup clarify whether/how the primary "mixup" threat differs from what RFC6819 identifies as in section 4.6.4? 2. Has the workgroup considered a mitigation that puts more responsibility on the authorization server, and less on the client? For example, if would be helpful for the writeup to clarify why having the client send an "audience field" (in the terminology of RFC6819) to the authorization endpoint would not mitigate the threat. (In that scenario, the authorization server can recognize that the audience does not correspond to a resource server it knows, rather than asking clients to make this check). I assume this approach has been considered and rejected as an incomplete mitigation, but I don't have visibility into where/how that discussion went. Thanks, Josh Hi all, this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 Please let us know by Feb 9th whether you accept / object to the adoption of this document as a starting point for work in the OAuth working group. Note: This call is related to the announcement made on the list earlier this month, see http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More time for analysis is provided due to the complexity of the topic. Ciao Hannes & Derek _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --001a11c157daa8c46c0529d893e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Apologies if this is the wrong forum for my comment (and ple= ase direct me to the appropriate place in that case), but I have two questi= ons about the propose mitigation (and the thinking behind it) that I think = the write-up could address:

1. Could the writeup clarify whether/how the primary "m= ixup" threat differs from what RFC6819 identifies as in section 4.6.4?=

2. Has the workgroup considered a mitigation that puts more = responsibility on the authorization server, and less on the client? For exa= mple, if would be helpful for the writeup to clarify why having the client = send an "audience field" (in the terminology of RFC6819) to the a= uthorization endpoint would not mitigate the threat. (In that scenario, the= authorization server can recognize that the audience does not correspond t= o a resource server it knows, rather than asking clients to make this check= ). I assume this approach has been considered and rejected as an incomplete= mitigation, but I don't have visibility into where/how that discussion= went.

Thanks,

Josh

Hi all,

this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
https://tools.ietf.org/html/draft-= jones-oauth-mix-up-mitigation-00

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

Note: This call is related to the announcement made on the list earlier
this month, see
http://www.ietf.org/mail-archive/web= /oauth/current/msg15336.html. More
time for analysis is provided due to the complexity of the topic.

Ciao
Hannes & Derek


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

--001a11c157daa8c46c0529d893e4-- From nobody Thu Jan 21 06:08:34 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D1A1A87D2 for ; Thu, 21 Jan 2016 06:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vN-wkl2ddOLI for ; Thu, 21 Jan 2016 06:08:28 -0800 (PST) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C4E1A8799 for ; Thu, 21 Jan 2016 06:08:26 -0800 (PST) Received: by mail-qg0-x231.google.com with SMTP id e32so32342082qgf.3 for ; Thu, 21 Jan 2016 06:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=dMA1o5f4heVed//3Yg7YXUH6/cLrzZUSgkZcp/VgEho=; b=v0OQoZmnVdEy9ROx3JPDjtIgh+wfLSecVDtVmmZ5YbzgxcTLm1i8nH0cAwkvsClaVQ zv8H5mdgVG0301t1UfQSxBy97TnLaMbgk7dQDNlpADRNCjkc5Roy6YjESDKhE+c2IDFf uFl1/2OkWzaR08OysSqAz5chPzVnoHk5KoR23AlMFMU2/pzAGuMogOmom8M6K69EqNe9 WG49r1bdxigR8Akurhe+8EKnPJrcpAuk6ISbO4WmPQ5YnQ2iAls9UNz+4Twn+UBW5J/p vuZm0tCXXAk4ckIEAcc549xdVVpr6PF/dxsFtaMtx5u5498Km9Ihsa0s+htHFYUqKfxJ ohNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=dMA1o5f4heVed//3Yg7YXUH6/cLrzZUSgkZcp/VgEho=; b=V8+sL3wZUXdx3VKJcumQ9cCBBy4wVEhjU9fWuOK43r78VXB7/tH22vrtIr3rgJtS0C BH4HISJFZIvvmfbDWdKoIBC74PswOVnDmhAqmcT8Xx5XKjDV7sDoKKfAhJZPTyeXe78A 8XYo2IKbb/Vj2o8G1ZMa7LJnmUmPdwTk3JlyIr8fkntSsOvNrxHk0mq7VryUHHp/yrs7 R4LXw2fqrCUwXt3XQ6zhGQLBgqEThWREn3je/+sDDgRmA+ZOWYjBHKPqGPsCvEXY1iKG X4MIVA+tecvOO5IWO/k6vwx9kO9ZRLmVgTdfoJVfnveYm6F7ziGhF6aoYTq9xBrttTbN TURg== X-Gm-Message-State: AG10YORvxkL/Hdte1tcKO1Uc9aZcNKKozsbR9NtZwHmvOy9c/87mLmPWOZYqDC4DZ7OvCA== X-Received: by 10.140.22.139 with SMTP id 11mr45054107qgn.34.1453385305713; Thu, 21 Jan 2016 06:08:25 -0800 (PST) Received: from [192.168.8.100] ([181.202.73.168]) by smtp.gmail.com with ESMTPSA id z106sm584396qge.18.2016.01.21.06.08.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 06:08:24 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_1816ECAE-CB1A-4874-8986-E3EE2CE8D7AB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Thu, 21 Jan 2016 11:08:23 -0300 Message-Id: References: <569E2260.4080904@gmx.net> To: William Denniss X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:08:33 -0000 --Apple-Mail=_1816ECAE-CB1A-4874-8986-E3EE2CE8D7AB Content-Type: multipart/alternative; boundary="Apple-Mail=_4A0D6369-C4AE-4236-9E3A-8C8A11C4491D" --Apple-Mail=_4A0D6369-C4AE-4236-9E3A-8C8A11C4491D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 for adoption > On Jan 21, 2016, at 3:18 AM, William Denniss = wrote: >=20 > +1 for adoption. >=20 > On Tue, Jan 19, 2016 at 7:47 PM, Hannes Tschofenig = > wrote: > Hi all, >=20 > this is the call for adoption of OAuth 2.0 Security: OAuth Open > Redirector, see > https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02 = >=20 > Please let us know by Feb 2nd whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. >=20 > Note: At the IETF Yokohama we asked for generic feedback about doing > security work in the OAuth working group and there was very positive > feedback. However, for the adoption call we need to ask for individual > documents. Hence, you need to state your view again. >=20 > Ciao > Hannes & Derek >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_4A0D6369-C4AE-4236-9E3A-8C8A11C4491D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii +1 for adoption

On Jan 21, 2016, at 3:18 AM, William Denniss <wdenniss@google.com> wrote:

+1 for adoption.

On Tue, Jan 19, 2016 at 7:47 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi all,

this is the call for adoption of OAuth 2.0 Security: OAuth Open
Redirector, see
https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02

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

Note: At the IETF Yokohama we asked for generic feedback about doing
security work in the OAuth working group and there was very positive
feedback. However, for the adoption call we need to ask for individual
documents. Hence, you need to state your view again.

Ciao
Hannes & Derek





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


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

--Apple-Mail=_4A0D6369-C4AE-4236-9E3A-8C8A11C4491D-- --Apple-Mail=_1816ECAE-CB1A-4874-8986-E3EE2CE8D7AB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMjExNDA4MjRaMCMGCSqGSIb3DQEJBDEWBBR4fYMnFkZtiKNKU0ecA4G/ aDIEGTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBDVZ+5qaoYaZIjj3sPSAju+4UDqM9Xm1UaA3A6HmDL5MPZVaohn2RZ hZipq7XEA71s4QYu9uEeUDtXHvClw+2S0UNWApeTNYzQ7rPAoMyQgDOPhx1vvAXpqX47Ahg05/Sq SoN5Hy4ylzmFDbE9bYo7y46JRs/pZpj5v14uW7awqGdvx+3wFrPVX01hfIN5vcq3oYBSUel6mSRY KmIdbqqhbmSOblDzR3GbrUY6oAxFQRn0mWH+D1B5t5108Tjxw8TeA0TzSM+l6xffinciOOKPUcdI xGInAfsPFa4jgOjDEBT3NE7CUI1M10a1OQ5m5txxI2hfSc6SGfv3ENcE8u1jAAAAAAAA --Apple-Mail=_1816ECAE-CB1A-4874-8986-E3EE2CE8D7AB-- From nobody Thu Jan 21 06:17:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881A61A8843 for ; Thu, 21 Jan 2016 06:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlEWl4GKeQi8 for ; Thu, 21 Jan 2016 06:17:44 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 339EA1A8835 for ; Thu, 21 Jan 2016 06:17:44 -0800 (PST) Received: by mail-qg0-x22d.google.com with SMTP id o11so32300075qge.2 for ; Thu, 21 Jan 2016 06:17:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=2Qx2LxZL/mqN8TZLWFjp6MyURTnfsR7TlB7oGY2W+dU=; b=vAl8IKiJ7UuEZCls4/QZWF+5SOpHiTCLpS2Xafd3sNMPKV8bsWVAGOcQfDoC2PCeCY N6v0hBiryEZWqKKpzXKbeXhTsYN81Z5QuBxkkVhU6RpCGUaqcB1ugGcUK573X1E2PrJa J/NwTP3YqNxwf54VRtglR9ynP8ZIMZDTc4hnQBfOcbOyIx3l/SRWj0zWawTKPp9nWtxm s1ZzoNK3OtENI8PD33YI7vCp735VqzQxNeC3I+848nc03lnlmZIorT+oCwYof91VzgQS 7mhBbEnJKyDuFlAr3VvklgUhRk+EkI/Xlckt25xqvx+ZVDIeCxW7Z4eHHjMmt2BqbClt OVYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=2Qx2LxZL/mqN8TZLWFjp6MyURTnfsR7TlB7oGY2W+dU=; b=miGJ2tDCx9j62LbStyc5qobDxr+cFhkJs8izxH5VUZmUr81M/dNMok+DPqi9euw2iD PRO8U+8SOzjf+by0aL5JLR8W3pQsqD8DwXUFlZyGZA04UdCALbDRliSLi79syCAL0kr4 fL/4j0+7bh5TVUoR+S36GBRHoSEWRhgx2s6X/1zJEzRJ79wyOsZmerwAdAR0jAGDFWSw veuWsBef+G+bfSbFfGy2lq8+snB3caiGRdIjb8U3xa54HCdgZ6iN59Rz+JXNLnMHTbyH r57KAtISJClbSOURaG8D0OmJVMTllmSWtzMHDQhN17NwzM1ATbvhMxi1hknJ7KpMjavH OcpQ== X-Gm-Message-State: AG10YOSbz3hwFUT0g/yuFSLC+wxxjSKMnVigIJumAmiTIRQTdtdOLxDwIHgrWHt9dDl6wA== X-Received: by 10.140.104.100 with SMTP id z91mr18959773qge.26.1453385863273; Thu, 21 Jan 2016 06:17:43 -0800 (PST) Received: from [192.168.8.100] ([181.202.73.168]) by smtp.gmail.com with ESMTPSA id l18sm593615qgd.36.2016.01.21.06.17.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 06:17:42 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_C4B842D3-E644-44EE-A384-FD4A444143B6"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Thu, 21 Jan 2016 11:17:41 -0300 Message-Id: <10631235-AF1B-4122-AEAE-D56BBF38F87E@ve7jtb.com> References: <568D24DD.3050501@connect2id.com> <568D5610.6000506@lodderstedt.net> To: William Denniss X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:17:47 -0000 --Apple-Mail=_C4B842D3-E644-44EE-A384-FD4A444143B6 Content-Type: multipart/alternative; boundary="Apple-Mail=_848EDE11-3008-4A12-A011-AAC205994E36" --Apple-Mail=_848EDE11-3008-4A12-A011-AAC205994E36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The code_challenge and code_challenge_method parameter names predate = calling the spec PKCE. =20 Given that some of us deployed early versions of PKCE in products and = opensource to mitigate the problem before the spec was completed we = decided not to rename the parameter names from code_verifier_method to = pkce_verifier_method. =20 For consistency we should stick with code_verifier_methods_supported in = discovery. John B. > On Jan 21, 2016, at 3:12 AM, William Denniss = wrote: >=20 > "code_challenge_methods_supported" definitely works for me. >=20 > Any objections to moving forward with that? I would like to update our = discovery doc shortly. >=20 > On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura > wrote: > Ah, OK. That's actually reasonable.=20 >=20 > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matake = >: > I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since the = registered parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, = not =E2=80=9Cpkce_method". >=20 >> On Jan 19, 2016, at 11:58, William Denniss > wrote: >>=20 >> Seems like we agree this should be added. How should it look? >>=20 >> Two ideas: >>=20 >> "code_challenge_methods_supported": ["plain", "S256"] >>=20 >> or >>=20 >> "pkce_methods_supported": ["plain", "S256"] >>=20 >>=20 >>=20 >> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt = > wrote: >> +1 >>=20 >>=20 >> Am 06.01.2016 um 18:25 schrieb William Denniss: >>> +1 >>>=20 >>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley > wrote: >>> Good point. Now that PKCE is a RFC we should add it to discovery. >>>=20 >>> John B. >>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov = > wrote: >>> > >>> > I just noticed PKCE support is missing from the discovery = metadata. >>> > >>> > Is it a good idea to add it? >>> > >>> > Cheers, >>> > >>> > Vladimir >>> > >>> > -- >>> > 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 >>>=20 >>>=20 >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_848EDE11-3008-4A12-A011-AAC205994E36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The code_challenge and code_challenge_method parameter = names predate calling the spec PKCE.  

Given that some of us deployed early = versions of PKCE in products and opensource to mitigate the problem = before the spec was completed we decided not to rename the parameter = names from code_verifier_method to pkce_verifier_method. =  

For = consistency we should stick with code_verifier_methods_supported in = discovery.

John = B.

On Jan 21, 2016, at 3:12 AM, William Denniss = <wdenniss@google.com> wrote:

"code_challenge_methods_supported" = definitely works for me.

Any objections to = moving forward with that? I would like to update our discovery doc = shortly.

On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura = <sakimura@gmail.com> wrote:
Ah, OK. That's actually reasonable. 

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matake = <matake@gmail.com>:
I = prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since the = registered parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, = not =E2=80=9Cpkce_method".

On Jan 19, 2016, at 11:58, = William Denniss <wdenniss@google.com> wrote:

Seems like we = agree this should be added. How should it look?

Two ideas:

"code_challenge_methods_supported": ["plain", "S256"]

or

"pkce_methods_supported": = ["plain", "S256"]



On Wed, Jan 6, 2016 at 9:59 AM, = Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
=20 =20 =20
+1


Am 06.01.2016 um 18:25 schrieb William Denniss:
+1

On Wed, Jan 6, 2016 at 6:40 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Good point.  Now that PKCE is a RFC we should add it to discovery.

John B.
> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
>
> I just noticed PKCE support is missing from the discovery metadata.
>
> Is it a good idea to add it?
>
> Cheers,
>
> Vladimir
>
> --
> 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



_______________________________________________
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=_848EDE11-3008-4A12-A011-AAC205994E36-- --Apple-Mail=_C4B842D3-E644-44EE-A384-FD4A444143B6 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMjExNDE3NDFaMCMGCSqGSIb3DQEJBDEWBBQDSktPbbICjwQpLq3y32lX kei3ajCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQApSUbsyMXAKdbX9owJJ6wbkcJjz1UdvvL/gg+6ExIwrYKKXxuxcryN wgRR3RWK5m5e8tMk/JOZYfumYQzl/LoQbO9XRaW8KxQCyNWRTHb5KaKc2LD+3wgae+O4enR5CAXz FnWTnecuszj3jy7wIro83Dm596wvL4rZHqBha2ewpAhwlmOg1QuiVjAtBsCXgLxWiHl0bRqaYv1o R6/p5TiXQ/SKXDxQG8lX4tjkYmP6SIRl5v7M4Yr/xqdxbKgKOsppt06QcO/nZ0gsfYoA9tx1XQyD KO6K7fEPhzghnE1j+qk0KVDmyCdH/HVPfOr7GMDB55aPYYqSAWEDuIbGFk0vAAAAAAAA --Apple-Mail=_C4B842D3-E644-44EE-A384-FD4A444143B6-- From nobody Thu Jan 21 06:23:56 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15AA1A8869 for ; Thu, 21 Jan 2016 06:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIQaJr6XSH20 for ; Thu, 21 Jan 2016 06:23:50 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 E01B91A8861 for ; Thu, 21 Jan 2016 06:23:49 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id e32so32712122qgf.3 for ; Thu, 21 Jan 2016 06:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=C039t73V5cLcLzt/43goufA6kywBDD9Mq7BCIKilqBk=; b=QcB5vTtOK+DW3cYW8Tgq3OM9bwlECasHB1GOmyFmK5/o9uHz63i9137t0hIA6NOlW2 00TdT82/kykK0AZCZm5cFfz8upBLodEp/f+JT534U8g+4ZapBZekwyxv3p1796FwrGZh XmcOiFZLCmz8UzlouGPy8IwsV90PSN+fn8NUpuLtptDx/MXCzlX/JQmVg4f3UXcbdXLv IMj+fBfDiNx+SvtqADXjn316WTs/1lPe6QwFP4ptvOeAnMlABn5efAPu1x8Gn9RcuKC8 rSO5KdS6t6OmezLrOR/JBrcNuLzXONwaG3z+l2ecsJ8IEA+HkL+/JNq/XMGRgs5weJal 8vdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=C039t73V5cLcLzt/43goufA6kywBDD9Mq7BCIKilqBk=; b=UlmVjSI21hXkBd2ogBOf8hmp9GWJm+tr/koF+J6KN1iVGveWecGMhZhSre5l4+t1vn v6lVrLmIeRF/Y6UPEypNZBwblWeI/CKLlqAWvCld7RCmmGWdoEi0PQ/h5e4MtFxjlhnJ r7XEYJijnLO03tQtwBTmbhRjZ3pNKfatQaekNDh4T3rGjsX8UEBXaKXBXv+4d+0uXPyL JXGBwRCo4krLlCKkfafqKTcgDuP7FIUAMlqe39m3ZyTb2nwhRDpDOT8X7UK3ZgqkHTTU +zZn+ItspZU/MPSkFDBEdj4r+GSFPLWhJVT7fvcqyIJ0FzN1rEtusFHGo/lxt2kLpk5X YGsQ== X-Gm-Message-State: AG10YOT2fSuisVPL0cexBLYckRUp1N8jLkxQJM2CRzhvd7BE2YWStQ91tKnqJy1CbO5eVGo7brpksIdfOzm3lQ== X-Received: by 10.140.144.16 with SMTP id 16mr10082467qhq.81.1453386228980; Thu, 21 Jan 2016 06:23:48 -0800 (PST) MIME-Version: 1.0 References: <569E2076.2090405@gmx.net> <569F915D.8020806@mit.edu> In-Reply-To: From: Nat Sakimura Date: Thu, 21 Jan 2016 14:23:38 +0000 Message-ID: To: Justin Richer , Mike Jones Content-Type: multipart/alternative; boundary=001a11355ee2e668560529d8d9f4 Archived-At: Cc: "" Subject: Re: [OAUTH-WG] Call for Adoption X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:23:54 -0000 --001a11355ee2e668560529d8d9f4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mike, You just criticize my draft. That's ok, but I would really like to get some response to my questions stated in https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To me, it just does not seem to work, and the combination of the oauth-meta and PKCE seems to be much more elegan, nicer, and much simpler to implement. If you just give up the dynamic response at the authorization endpoint, then you even do not have to touch the code but just change a config file. Please convince me by answering to my questions. For the record of Yokohama, I do not recall much about duplication in OAuth session. The poll in the room was 19 for / zero against / 4 persons need more information. Indeed, it is not duplicating much. And if you move to a new model without pre-configured discovery, it is not duplicating any but the resource endpoint URI, which is optional and is for the cases where the client did not know the concrete resource endpoint to start with. I understand your usecases always start from a concrete endpoint location. Mine do not. In a four party model, it is likely not. The user just want to have the service to fetch his data from some resource endpoint. He just hits the service. He does not hit the resource endpoint directly. For example, in the case of a consumer using a personal finance platform (PFP)to manage his pension fund, he hits the PFP and not the Pension fund. Assuming that the pension fund has delegated the authorization control to the authorization server, then, the authorization server should return both the access token and the endpoint of the pension fund so that the PFP can pull the data using them. A similar model holds for personal health service and health care providers. Best, Nat 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 21:18 Justin Richer : > Convergence is exactly what I=E2=80=99m arguing for, though. These things= ought to > work together. > > =E2=80=94 Justin > > On Jan 21, 2016, at 2:55 AM, Mike Jones > wrote: > > My memory of the discussions of the oauth-meta draft in Yokohama were tha= t > many people felt that it was unnecessarily dynamically duplicating a lot = of > information that the client already had. Most of us that were aware of t= he > attacks then were in favor of a more targeted, minimal approach. You wer= e > listened to in Yokohama, but that didn=E2=80=99t necessarily mean that pe= ople > agreed with the approach. Participants were already aware of the > oauth-meta proposal in Darmstadt but no one spoke up in favor of it that = I > can recall. Rather, I think people were thinking that =E2=80=9Cless is m= ore=E2=80=9D. > > > > There have also been discussions in the last day about how dynamically > returning a resource URL, which oauth-meta does, is both unnecessary (sin= ce > the client initiated the resource authorization already knowing what > resource it wants to access) and often problematic, since many > authorization servers can authorize access to multiple resources. If > anything, the client should be telling the authorization server what > resource it wants to access =E2=80=93 not the other way around. > > > > I=E2=80=99m not saying that there aren=E2=80=99t some good ideas in the o= auth-meta draft =E2=80=93 > I=E2=80=99m sure there are, just as there are in the approach designed by= the > participants in Darmstadt. While I volunteered to write the first draft = of > the mix-up-mitigation approach, it really reflects something a lot of > people have already bought into =E2=80=93 as evidenced in the passion in = the > high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D thread, = and not just my > personal project. > > > > If you think there are things missing or wrong in the mix-up-mitigation > draft, please say what they are. That will help us quickly converge on a > solution that will work for everyone. > > > > Sincerely, > > -- Mike > > > > *From:* Nat Sakimura [mailto:sakimura@gmail.com ] > *Sent:* Wednesday, January 20, 2016 11:17 PM > *To:* Mike Jones ; William Denniss < > wdenniss@google.com>; Justin Richer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Call for Adoption > > > > Hi Mike. > > > > Conversely, I would like to ask why this approach does not work for Mix-u= p > attack. As Nov stated, we in fact have discussed the approach in quite a > length back in Yokohama. I really would like to know why it does not work= . > > > > Besides, for oauth-meta approach, mix-up attack is only one of the thing > it solves. > > > > Nat Sakimura > > > > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones : > > Not to be negative, but I disagree with adopting > draft-sakimura-oauth-meta. We should define and promote one mitigation > approach to the mix-up attacks. Having two would confuse implementers an= d > cause compatibility problems =E2=80=93 reducing overall security. > > > > The approach defined in draft-jones-oauth-mix-up-mitigation was created i= n > collaboration with the security researchers who identified the problems i= n > the first place, was vigorously discussed in the security meeting Hannes > and Torsten held in Darmstadt, and has been since refined based on > substantial input from the working group. And at least three implementer= s > have already stated that they=E2=80=99ve implemented it. I=E2=80=99m not= saying that it=E2=80=99s, > but if there are things missing or things that need to be improved in our > approach, we should do it there, rather introducing a competing approach. > > > > Also, standard OAuth deployments register the client and then use the > information gathered at registration time for subsequent protocol > interactions. They do not need all the configuration information for the > authorization server to be retransmitted at runtime. The oauth-meta draf= t > goes too far in that direction, at least as I see it. Returning things t= wo > ways creates its own problems, as discussed in the Duplicate Information > Attacks security considerations section (7.2) of the mix-up-mitigation > draft. > > > > I=E2=80=99ll note that the mix-up-mitigation approach is compatible with = existing > practice in both static and dynamic metadata discovery. Replying to > Justin=E2=80=99s comment that =E2=80=9CIt's the pre-configured discovery = document that's > at the root of the mix-up attack in the first place=E2=80=9D =E2=80=93 th= is is not the > case. The attacks can be performed without either discovery or dynamic > registration. > > > > I would be interested in hearing a technical discussion on whether there > are aspects of the oauth-meta approach that mitigate aspects of the attac= ks > that the mix-up-mitigation approach does not. That could help inform > whether there are additional things we should add to or change in the > mix-up draft. > > > > -- Mike > > > > *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William > Denniss > *Sent:* Wednesday, January 20, 2016 10:37 PM > *To:* Justin Richer > *Cc:* oauth@ietf.org > *Subject:* Re: [OAUTH-WG] Call for Adoption > > > > +1 to adopt this, and I agree with Justin's comments. > > > > On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer wrote: > > +1 > > Inline discovery and pre-configured discovery (ie, .well-known) should at > the very least be compatible and developed together. It's the > pre-configured discovery document that's at the root of the mix-up attack > in the first place. > > -- Justin > > > > On 1/19/2016 10:30 PM, Nat Sakimura wrote: > > Just to give more context, at IETF 94, I have done a presentation on > discovery. > > > > According to the minutes, > > > > (f) Discovery (Nat) > > > > Nat explains his document as an example of the work that has= to be done > > in the area of discovery, which is a topic that has been ide= ntified > > as necessary for interoperability since many years but so fa= r there > > was not time to work on it. Mike, John and Nat are working o= n a new > > document that describes additional discovery-relevant compon= ents. > > > > Poll: 19 for / zero against / 4 persons need more informatio= n. > > > > The document discussed there was > https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a > simple (only 1-page!) but a very powerful document that nudges towards > HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-u= p > attack without introducing the concept of issuer which is not in RFC6749. > It is also good for selecting different endpoints depending on the user > authentication and authorization results and more privacy sensitive than > pre-announced Discovery document. It also allows you to find to which > protected resource endpoint you can use the access token against. > > > > In the last sentence of the minutes, it talks about "a new document that > describes additional discovery-relevant components". This is > https://tools.ietf.org/html/draft-jones-oauth-discovery-00. It went for > the call for adoption. However, it is only a half of the story. I believe > https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was > discussed at IETF 94 and had support there should be adopted as well. > > > > Nat Sakimura > > > > > > > > > > 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura : > > Thanks Hannes. > > > > I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, = which > was discussed in Yokohama, and was largely in agreement if my recollectio= n > is correct. Why is it not in the call for adoption? > > > > > > > > 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig : > > Hi all, > > we have submitted our new charter to the IESG (see > http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and > since some IESG members like to see an updated list of milestones as > well. For this reason, based on a suggestion from Barry, we are also > starting a call for adoption concurrently with the review of the charter > text by the IESG. > > We will post separate mails on the individual documents. Your feedback > is important! Please take the time to look at the documents and provide > your feedback. > > Ciao > Hannes & Derek > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --001a11355ee2e668560529d8d9f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mike,=C2=A0

You just criticize my draft= . That's ok, but I would really like to get some response to my questio= ns stated in=C2=A0https://www.ietf.org/mail-archive/web/oauth/current/ms= g15483.html=C2=A0. To me, it just does not seem to work, and the combin= ation of the oauth-meta and PKCE seems to be much more elegan, nicer, and m= uch simpler to implement. If you just give up the dynamic response at the a= uthorization endpoint, then you even do not have to touch the code but just= change a config file.=C2=A0

Please convince me by= answering to my questions.=C2=A0

For the record o= f Yokohama, I do not recall much about duplication in OAuth session. The po= ll in the room was=C2=A019 for / zero against / 4 persons need more information. In= deed, it is not duplicating much. And if you move to a new model without pr= e-configured discovery, it is not duplicating any but the resource endpoint= URI, which is optional and is for the cases where the client did not know = the concrete resource endpoint to start with.=C2=A0

= I understand your usecases always start from a concrete endpoint location. = Mine do not. In a four party model, it is likely not. The user just want to= have the service to fetch his data from some resource endpoint. He just hi= ts the service. He does not hit the resource endpoint directly. For example= , in the case of a consumer using a personal finance platform (PFP)to manag= e his pension fund, he hits the PFP and not the Pension fund. Assuming that= the pension fund has delegated the authorization control to the authorizat= ion server, then, the authorization server should return both the access to= ken and the endpoint of the pension fund so that the PFP can pull the data = using them. A similar model holds for personal health service and health ca= re providers.=C2=A0

Best,=C2=A0
Nat


2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 21:18 Justin R= icher <jricher@mit.edu>:
Conv= ergence is exactly what I=E2=80=99m arguing for, though. These things ought= to work together.

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

On Jan 21, 2016, at 2:55 AM, M= ike Jones <Michael.Jones@microsoft.com> wrote:

My memory of the discussions of = the oauth-meta draft in Yokohama were that many people felt that it was unn= ecessarily dynamically duplicating a lot of information that the client already had.=C2=A0 Most of us that were aware of the attac= ks then were in favor of a more targeted, minimal approach.=C2=A0 You were = listened to in Yokohama, but that didn=E2=80=99t necessarily mean that peop= le agreed with the approach.=C2=A0 Participants were already aware of the oauth-meta proposal in Darmstadt but no one spoke up in favor= of it that I can recall.=C2=A0 Rather, I think people were thinking that = =E2=80=9Cless is more=E2=80=9D.

=C2=A0

T= here have also been discussions in the last day about how dynamically retur= ning a resource URL, which oauth-meta does, is both unnecessary (since the = client initiated the resource authorization already knowing what resource it want= s to access) and often problematic, since many authorization servers can au= thorize access to multiple resources.=C2=A0 If anything, the client should = be telling the authorization server what resource it wants to access =E2=80=93 not the other way around.<= /u>

=C2=A0

I=E2=80=99m not saying that there aren=E2= =80=99t some good ideas in the oauth-meta draft =E2=80=93 I=E2=80=99m sure = there are, just as there are in the approach designed by the participants in Darmstadt.=C2=A0 While I volunteered to write the first draft of the mi= x-up-mitigation approach, it really reflects something a lot of people have= already bought into =E2=80=93 as evidenced in the passion in the high-volu= me =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D thread, and not just my personal project.

=C2=A0

If you think there are things missing or wrong in the mix-up-mitigation= draft, please say what they are.=C2=A0 That will help us quickly converge = on a solution that will work for everyone.

=C2=A0

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Sincerely,

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

=C2=A0

From: Nat Sakimura [mailto:sakimura@gmail.= com]
Sent: Wednesday, January 20, 2016 11:17 PM
To: Mike Jones <Michael.Jones@microsoft.com>; William Denniss <wdenniss@google.com<= /a>>; Justin Richer <jricher@mit.edu>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Call for Adoption

=C2=A0

Hi Mike.=C2=A0

=C2=A0

Conversely, I would like to ask why this approa= ch does not work for Mix-up attack.=C2=A0As Nov stated, we in fact have dis= cussed the approach in quite a length back in Yokohama. I really would like= to know why it does not work.=C2=A0

=C2=A0

Besides, for oauth-meta approach, mix-up attack= is only one of the thing it solves.=C2=A0

=C2=A0

Nat Sakimura

=C2=A0

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones <Michael.Jones@microsoft.com>:

Not to be negative, but I disagr= ee with adopting draft-sakimura-oauth-meta.=C2=A0 We should define and prom= ote one mitigation approach to the mix-up attacks.=C2=A0 Having two would conf= use implementers and cause compatibility problems =E2=80=93 reducing overal= l security.

= =C2=A0

The ap= proach defined in draft-jones-oauth-mix-up-mitigation was created in collab= oration with the security researchers who identified the problems in the first place, was vigorously= discussed in the security meeting Hannes and Torsten held in Darmstadt, an= d has been since refined based on substantial input from the working group.= =C2=A0 And at least three implementers have already stated that they=E2=80=99ve implemented it.=C2=A0 I=E2=80=99m= not saying that it=E2=80=99s, but if there are things missing or things th= at need to be improved in our approach, we should do it there, rather intro= ducing a competing approach.

=C2=A0

Also, standard OAuth deployments register the client and then use= the information gathered at registration time for subsequent protocol interactions.=C2=A0 They do not need all the = configuration information for the authorization server to be retransmitted = at runtime.=C2=A0 The oauth-meta draft goes too far in that direction, at l= east as I see it.=C2=A0 Returning things two ways creates its own problems, as discussed in the Duplicate Information Attack= s security considerations section (7.2) of the mix-up-mitigation draft.

=C2=A0=

I=E2=80=99ll note that= the mix-up-mitigation approach is compatible with existing practice in bot= h static and dynamic metadata discovery.=C2=A0 Replying to Justin=E2=80=99s comment tha= t =E2=80=9CIt's the pre-configured discovery document that's= at the root of the mix-up attack in the first place=E2=80= =9D =E2=80=93 this is not the case.=C2=A0 The attacks can be performed without either discove= ry or dynamic registration.

= =C2=A0

I would be interested in hearing a technical discussion on whether= there are aspects of the oauth-meta approach that mitigate aspects of the attacks that the mix-up-mitigation a= pproach does not.=C2=A0 That could help inform whether there are additional= things we should add to or change in the mix-up draft.

=C2=A0

<= p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 -- Mike

=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of William Denniss
Sent: Wednesday, January 20, 2016 10:37 PM
To: Justin Richer <jricher@mit.edu>
Cc: oauth@ietf.o= rg
Subject: Re: [OAUTH-WG] Call for Adoption

=C2=A0

+1 to adopt this, and I agree with Justin's= comments.

=C2=A0

On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer = <jricher@mit.edu> wrote:

+1

Inline discovery and pre-configured discovery (ie, .well-known) should at t= he very least be compatible and developed together. It's the pre-config= ured discovery document that's at the root of the mix-up attack in the = first place.

=C2=A0-- Justin

=C2=A0=

On 1/19/2016 10:30 PM, Nat Sakimura wrote:

Just to give more context, at IETF 94, I have d= one a presentation on discovery.=C2=A0

=C2=A0

According to the minutes,=C2=A0

=C2=A0

=C2=A0=C2=A0=C2=A0 (f) Discovery (Nat)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Nat explains his document as an exam=
ple of the work that has to be done
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the area of discovery, which is a topi=
c that has been identified
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as necessary for interoperability since m=
any years but so far there
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was not time to work on it. Mike, John an=
d Nat are working on a new
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document that describes additional discov=
ery-relevant components.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Poll: 19 for / zero against / 4 pers=
ons need more information.
=C2=A0<=
/span>

The document discussed the= re was https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a sim= ple (only 1-page!) but a very powerful document that nudges towards HATEOAS= which is at the core of RESTful-ness. It also mitigates the Mix-up attack = without introducing the concept of issuer which is not in RFC6749. It is also good for selecting different= endpoints depending on the user authentication and authorization results a= nd more privacy sensitive than pre-announced Discovery document. It also al= lows you to find to which protected resource endpoint you can use the access token against.=C2=A0

=C2=A0

In the last sentence of the minutes, it talks = about "a new document that describes additional discovery-relevant com= ponents". This is=C2=A0https://tools.ietf.org/html/draft= -jones-oauth-discovery-00.=C2=A0 It went for the call for adoption. However, it is only a half of the story= . I believe=C2=A0https://tools.ietf.org/html/draft-sakimura-oau= th-meta-05=C2=A0that was discussed at IETF 94 and had support there=C2=A0should be adopted as well.=C2=A0 <= /u>

=C2=A0

Nat Sakimura

=C2=A0

=C2=A0

=C2=A0

=C2=A0

2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura <sakimura@gmail.com>:

Thanks Hannes.=C2=A0

=C2=A0

I did not find=C2=A0https://tools.i= etf.org/html/draft-sakimura-oauth-meta-05,=C2=A0which was discussed in Yokohama, and was largely in agreement if my recollection is correct. W= hy is it not in the call for adoption?=C2=A0

=C2=A0

=C2=A0

=C2=A0

2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:

Hi all,

we have submitted our new charter to the IESG (see
http://www.ietf.org/mail-archive/web/oauth/current/msg1= 5379.html) and
since some IESG members like to see an updated list of milestones as
well. For this reason, based on a suggestion from Barry, we are also
starting a call for adoption concurrently with the review of the charter text by the IESG.

We will post separate mails on the individual documents. Your feedback
is important! Please take the time to look at the documents and provide
your feedback.

Ciao
Hannes & Derek

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

=C2=A0

_______________________________________________
OAuth mailing list
OAuth@ietf.org=

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

=C2=A0


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

=C2=A0

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


--001a11355ee2e668560529d8d9f4-- From nobody Thu Jan 21 06:26:23 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B2C1A87D9 for ; Thu, 21 Jan 2016 06:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76xp3jMSQK1S for ; Thu, 21 Jan 2016 06:26:19 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073CB1A87A5 for ; Thu, 21 Jan 2016 06:26:19 -0800 (PST) Received: by mail-qg0-x229.google.com with SMTP id 6so32496577qgy.1 for ; Thu, 21 Jan 2016 06:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=J4LzLR1YWVkdSx69Ro3ZOsCo4KNVvenXdT6prMFPjU4=; b=ipDefOiDqtqrXls5+E7M5eMu84pDZjZHTg+UguZhFEpGS9AovSvCVEG1L6UmpqPpGd LYBQr1j9MtFA2hQgZN/Io2y1JnvcK6OZler66fjA9Ns27RQKR12lbVyXBRDND3d6cinr 9dNWHD+5m9RbG8mPQutLog1kW+vAQE48xWFJMC9TXdsSvjOvy/kabvCrMJ7DqhCGqIbW eM4HpKFsXevaIRD5/sm6/CfaRIMZeLYGoOaKMWL6Gd93NDvmDJpcfe5baG5Ib71hWhAR DbeHjUW87Jp9V+5Mqo4ZQ/PHJjL/ppHl8rHUhj+TmpQknyWUtPQlTMxBcekS281+GLW8 wBIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=J4LzLR1YWVkdSx69Ro3ZOsCo4KNVvenXdT6prMFPjU4=; b=cQlHHfHDaDCweGNINjuJz0YQFGYAPG139uYzlwzK5jXq6EnEIjwzcP6oyuVVG5JGvk rLsao9KVoajGwVk7/IXh5366CjJwgtg577x85tRPtO+k7vvLYYX1sXU+o/P3P2BeaHPf LBte1rYZUUJVcsOjGH8S1F+f52A4tR7YU11VI4AtZMNN6RmovAY+z9b+n4EaPernH6xC qsStpjHSqPWbfmfqmXXYNkzLRMI/yCmNwJ4GI1u2oRsC/utD3UOd4TjG6Ey88I3hm+/b Lh6qjpqppK/0wnuBjwuymky/GV7VNuaDN3JubqZ+V313zcE4B0yBg4Pu0NBYElh9guzC RDPw== X-Gm-Message-State: ALoCoQkulnWSiLROofN5uEH+qxHlEEQGgmJeweNZ+Ar5zaWn0vVH1SUj07MEql8WctoCXY/eE7I2Nd1W2GVo/2rFIA9eW9VwqA== X-Received: by 10.140.101.201 with SMTP id u67mr52621034qge.33.1453386377943; Thu, 21 Jan 2016 06:26:17 -0800 (PST) MIME-Version: 1.0 References: <568D24DD.3050501@connect2id.com> <568D5610.6000506@lodderstedt.net> <10631235-AF1B-4122-AEAE-D56BBF38F87E@ve7jtb.com> In-Reply-To: <10631235-AF1B-4122-AEAE-D56BBF38F87E@ve7jtb.com> From: Nat Sakimura Date: Thu, 21 Jan 2016 14:26:08 +0000 Message-ID: To: John Bradley , William Denniss Content-Type: multipart/alternative; boundary=001a11c16e6ac7613a0529d8e271 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:26:21 -0000 --001a11c16e6ac7613a0529d8e271 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1. Even as the main editor of the spec., I tend to forget the history ;-) 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:17 John Bradley : > The code_challenge and code_challenge_method parameter names predate > calling the spec PKCE. > > Given that some of us deployed early versions of PKCE in products and > opensource to mitigate the problem before the spec was completed we decid= ed > not to rename the parameter names from code_verifier_method to > pkce_verifier_method. > > For consistency we should stick with code_verifier_methods_supported in > discovery. > > John B. > > On Jan 21, 2016, at 3:12 AM, William Denniss wrote: > > "code_challenge_methods_supported" definitely works for me. > > Any objections to moving forward with that? I would like to update our > discovery doc shortly. > > On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura wrote: > >> Ah, OK. That's actually reasonable. >> >> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matake : >> >>> I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since the = registered >>> parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, not =E2=80= =9Cpkce_method". >>> >>> On Jan 19, 2016, at 11:58, William Denniss wrote: >>> >>> Seems like we agree this should be added. How should it look? >>> >>> Two ideas: >>> >>> "code_challenge_methods_supported": ["plain", "S256"] >>> >>> or >>> >>> "pkce_methods_supported": ["plain", "S256"] >>> >>> >>> >>> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt < >>> torsten@lodderstedt.net> wrote: >>> >>>> +1 >>>> >>>> >>>> Am 06.01.2016 um 18:25 schrieb William Denniss: >>>> >>>> +1 >>>> >>>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley wrote= : >>>> >>>>> Good point. Now that PKCE is a RFC we should add it to discovery. >>>>> >>>>> John B. >>>>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov < >>>>> vladimir@connect2id.com> wrote: >>>>> > >>>>> > I just noticed PKCE support is missing from the discovery metadata. >>>>> > >>>>> > Is it a good idea to add it? >>>>> > >>>>> > Cheers, >>>>> > >>>>> > Vladimir >>>>> > >>>>> > -- >>>>> > 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 >>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing listOAuth@ietf.orghttps://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 > > > --001a11c16e6ac7613a0529d8e271 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1. Even as the main editor of the spec., I tend to forget= the history ;-)

2016= =E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:17 John Bradley <ve7jtb@ve7jtb.com>:
The code_challenge a= nd=C2=A0code_challenge_method parameter names predate calling the spec PKCE= . =C2=A0

Given that some of us deployed early versions o= f PKCE in products and opensource to mitigate the problem before the spec w= as completed we decided not to rename the parameter names from code_verifie= r_method to pkce_verifier_method. =C2=A0

For consi= stency we should stick with code_verifier_methods_supported in discovery.

John B.

On Jan 21, 2016, at 3:12 A= M, William Denniss <wdenniss@google.com> wrote:

&quo= t;code_challenge_methods_supported&qu= ot; definitely works for me.
Any objections to movi= ng forward with that? I would like to update our discovery doc shortly.

On= Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura <sakimura@gmail.com>= wrote:
Ah, OK. T= hat's actually reasonable.=C2=A0

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matak= e <matake@gmail.co= m>:
I prefer =E2=80=9Ccode_challenge_methods_supported=E2= =80=9D, since the registered parameter name is =E2=80=9Ccode_challenge_meth= od=E2=80=9D, not =E2=80=9Cpkce_method".

On Jan 19, 2016, at= 11:58, William Denniss <wdenniss@google.com> wrote:

Seems like we agree this should be added. How should it look?

Two= ideas:

"code_challenge_methods_supported": ["plain&q= uot;, "S256"]

or

"pkce= _methods_supported": ["plain", "S256"]


=

On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt <= torsten@lodder= stedt.net> wrote:
=20 =20 =20
+1


Am 06.01.2016 um 18:25 schrieb William Denniss:
+1

On Wed, Jan 6, 2016 at 6:40 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
Good point.=C2=A0 Now that PKCE is a RFC we should add it to discovery.

John B.
> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
>
> I just noticed PKCE support is missing from the discovery metadata.
>
> Is it a good idea to add it?
>
> Cheers,
>
> Vladimir
>
> --
> Vladimir Dzhuvinov
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@= ietf.org
> https://www.ietf.org/mailman/listinfo/oa= uth

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



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


_______________________________________________
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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
http= s://www.ietf.org/mailman/listinfo/oauth
--001a11c16e6ac7613a0529d8e271-- From nobody Thu Jan 21 06:28:49 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15EB71A886C for ; Thu, 21 Jan 2016 06:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKog2yxalZW3 for ; Thu, 21 Jan 2016 06:28:46 -0800 (PST) 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 DD5731A87D9 for ; Thu, 21 Jan 2016 06:28:45 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id x1so16341308qkc.1 for ; Thu, 21 Jan 2016 06:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=KI4+XCP3IDOJ2gJ4YZOYzTOtr9EX53yRMu4cxXPCQGg=; b=r/URMFdF3F6F/LB44CJBh3n2KrNPAFC0aV4KU9QxdMqwtsUewBS0kbVVz32bm/8ZPW A/7ICAtTmyzB0ohFrQRGlCPTgidG9MZRJAWgsxs7VKBNknaV1l3oynjPaTjfwn0Fn09I RFayvKRcgxnC9k4zh2XKHbHAJSm8Zn2RFLmjMhJkfpAWw2y4enPGhWl0tn3ZXs4Ucdf2 wpz8ifUeaICpcqreHQFG4xdpq8Z2iyDb2PGK8mroIdoCV0eDjrw4Rh+U4tB54dq2LIqZ 3rh9EDbyude0URRMeluO2Iq7pM+AdFChF3UPSNEnW6FZzjDyDWS9GMAM57/s+xbzY8hB Yq4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=KI4+XCP3IDOJ2gJ4YZOYzTOtr9EX53yRMu4cxXPCQGg=; b=Gw8sOCq9nLz9HOBLK6v6bREtzaEE7hMsnJOhT1pqvpMWB1Qxf7ivIOCLQKXu90iz8K ki7H2IJpy92/lY1TbR4qJCPxk2ZnklJm93Vf+I9w2tL3KpF7ix/gKhR57Mx1kecxv9J4 tBPigmW2xXbMkCFU4RkEOz3DGC0d1GAc8J/+TaEj0rgkDKpFVpR4fDv+8E0p6lXDWbxC PVwpqj4LJ9ii3ouM29EmmqZoO8VLKIE+PwFiEjbmC0yKoYjrV9LFMJo4G7+TGRLINkID X8W7QgKhIN29BmPFvAgoyEkFkmaxmelQuH8eR1cXCxpPoUZgy29276lZe+JIrXLyyQJe 8EnA== X-Gm-Message-State: ALoCoQksG3UFFuRofm2A53SVFaaBOMRphFkdPzsYNwcYBqqZ+ws5mGR5YKPZFPrVF7rRLz32dnaiiwW7Fd5st0SRDzZ+cCF6CA== X-Received: by 10.55.78.207 with SMTP id c198mr51687730qkb.34.1453386525109; Thu, 21 Jan 2016 06:28:45 -0800 (PST) MIME-Version: 1.0 References: <569E2260.4080904@gmx.net> In-Reply-To: From: Nat Sakimura Date: Thu, 21 Jan 2016 14:28:35 +0000 Message-ID: To: John Bradley , William Denniss Content-Type: multipart/alternative; boundary=001a114a7c9c8cf62a0529d8ebd9 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:28:48 -0000 --001a114a7c9c8cf62a0529d8ebd9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 apart from the title... It sounds like the spec is implementing OAuth Open Redirector... Something like "preventing OAuth open redirector" or so might be more descriptive. Nat 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:08 John Bradley : > +1 for adoption > > On Jan 21, 2016, at 3:18 AM, William Denniss wrote: > > +1 for adoption. > > On Tue, Jan 19, 2016 at 7:47 PM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> Hi all, >> >> this is the call for adoption of OAuth 2.0 Security: OAuth Open >> Redirector, see >> https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02 >> >> Please let us know by Feb 2nd whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >> >> Note: At the IETF Yokohama we asked for generic feedback about doing >> security work in the OAuth working group and there was very positive >> feedback. However, for the adoption call we need to ask for individual >> documents. Hence, you need to state your view again. >> >> Ciao >> Hannes & Derek >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a114a7c9c8cf62a0529d8ebd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 apart from the title... It sounds like the spec is impl= ementing OAuth Open Redirector...=C2=A0
Something like "preven= ting OAuth open redirector" or so might be more descriptive.=C2=A0

Nat

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:08 John Bradley = <ve7jtb@ve7jtb.com>:
+1 for= adoption

On Jan 21, 2016, at 3:18 AM, William Denniss <wdenniss@google.com= > wrote:

+1 for adoption.

On Tue, Jan 19, 2016 at 7:4= 7 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> = wrote:
Hi all,

this is the call for adoption of OAuth 2.0 Security: OAuth Open
Redirector, see
https://tools.ietf.org/html/draft-= bradley-oauth-open-redirector-02

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

Note: At the IETF Yokohama we asked for generic feedback about doing
security work in the OAuth working group and there was very positive
feedback. However, for the adoption call we need to ask for individual
documents. Hence, you need to state your view again.

Ciao
Hannes & Derek





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


_______________________________________________
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
--001a114a7c9c8cf62a0529d8ebd9-- From nobody Thu Jan 21 06:40:17 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6B131A8892 for ; Thu, 21 Jan 2016 06:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xht5-kmzPJUa for ; Thu, 21 Jan 2016 06:40:07 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 656651A888F for ; Thu, 21 Jan 2016 06:40:07 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id 6so32832484qgy.1 for ; Thu, 21 Jan 2016 06:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=TMFKNCT6/8UBM6LOd94rvA9QBqRu+u6wkTmRoPgoXfc=; b=rPY8ZWc02T5lW/WOnYRncKQxaGvcTtDh9a/5N3m8eVZhbb1Xtbf1QbUQrC/FsVhl95 xlYx/e59hOoQwo3f0v/kBS8DMglDmdWO8/op5PbE7UnAorlcbJImhY31AeYKIfHHBaim WI4Nn1fRN/spfZ78mKTdLyYWzuGHAeWcsVTgU0Rbo7RSkCacdof+7AIsp415rSWWai0z /hVRetws0dfM0Yr5QMxVmAUQ5y77xbP/kdXWfSjXIJ8ZeBtUUK7mtNoN/9BTiT7WTGMx JMCdt4Rg8m4NNjU5vGMtYVvy74Hy+tA/tcFLdhm6nfv1KlE7jKRLCtt7z3gLWyBjajy7 JnXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=TMFKNCT6/8UBM6LOd94rvA9QBqRu+u6wkTmRoPgoXfc=; b=JOK7OClKaYIIixZKGkURrt7Hxw6RyhFUBd4svmWCeslJY+HpP5euNSrww0j4fuanZo 0ZNMFHAXAKbm32VaFmBOh1mhbjqBC3kRYADL+CggZyUvG5AvkofciNlmTLl/UC0PnQ9b qi2QJNw/1Xa9DAeJP4rTD0VZzBLHK5FJLgG+1+DfDTrzp/Yz4+lY50fTo7QcqZK+KPhn O8KCH8TvCFzrKXSMxfIBHdH3UhFscZ8TEA/GU0YD/oVb85URqokzCLfauCKANRmM+Bva FuN5EKQT3IPtm+qW9l0hYlWFjzBGuNCTfhehioMUobHoTDJD++0Xw+ZT/v0v19xrtHnd B5Dw== X-Gm-Message-State: ALoCoQltA4avLegcMQvUz1ZyuZiTIZAefka16uRbT65mglS6VKap0Iu7PLHRZZrS+LUsaNat26qSDAkKL5Jr2uHef/xN3McTxw== X-Received: by 10.140.250.138 with SMTP id v132mr55923976qhc.0.1453387206555; Thu, 21 Jan 2016 06:40:06 -0800 (PST) MIME-Version: 1.0 References: <569E22E1.5010402@gmx.net> In-Reply-To: From: Nat Sakimura Date: Thu, 21 Jan 2016 14:39:57 +0000 Message-ID: To: Josh Mandel , Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a113a99d02aff980529d9140d Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:40:13 -0000 --001a113a99d02aff980529d9140d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Josh, It is similar but slightly different IMHO. Section 4.6.4 of the RFC6819 is the access token phishing by a counterfeit resource server. The mix-up attack described here is the code phishing by a counterfeit token endpoint. In my view, both can be mitigated by the server returning the next step: i.e., authorization endpoint returning the legitimate token endpoint uri, and token endpoint returning legitimate resource endpoint uris. This involves no discovery endpoint, which is good. Your way also works. It is just the reverse of my proposal. The difference being that my proposal does not need any coding on the server but just configuration, and it can return more metadata if needed. Cheers, Nat 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel : > Apologies if this is the wrong forum for my comment (and please direct me > to the appropriate place in that case), but I have two questions about th= e > propose mitigation (and the thinking behind it) that I think the write-up > could address: > > 1. Could the writeup clarify whether/how the primary "mixup" threat > differs from what RFC6819 identifies as in section 4.6.4? > > 2. Has the workgroup considered a mitigation that puts more responsibilit= y > on the authorization server, and less on the client? For example, if woul= d > be helpful for the writeup to clarify why having the client send an > "audience field" (in the terminology of RFC6819) to the authorization > endpoint would not mitigate the threat. (In that scenario, the > authorization server can recognize that the audience does not correspond = to > a resource server it knows, rather than asking clients to make this check= ). > I assume this approach has been considered and rejected as an incomplete > mitigation, but I don't have visibility into where/how that discussion > went. > > Thanks, > > Josh > Hi all, > > this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see > https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 > > Please let us know by Feb 9th whether you accept / object to the > adoption of this document as a starting point for work in the OAuth > working group. > > Note: This call is related to the announcement made on the list earlier > this month, see > http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More > time for analysis is provided due to the complexity of the topic. > > Ciao > Hannes & Derek > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a113a99d02aff980529d9140d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Josh,=C2=A0

It is similar but slight= ly different IMHO.=C2=A0

Section 4.6.4 of the RFC6= 819 is the access token phishing by a counterfeit resource server.=C2=A0
The mix-up attack described here is the code phishing by a counterf= eit token endpoint.=C2=A0

In my view, both can be = mitigated by the server returning the next step: i.e., authorization endpoi= nt returning the legitimate token endpoint uri, and token endpoint returnin= g legitimate resource endpoint uris. This involves no discovery endpoint, w= hich is good.=C2=A0

Your way also works. It is jus= t the reverse of my proposal. The difference being that my proposal does no= t need any coding on the server but just configuration, and it can return m= ore metadata if needed.=C2=A0

Cheers,=C2=A0
<= div>
Nat

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel &l= t;jmandel@gmail.com>:
=

Apologies if this is the wron= g forum for my comment (and please direct me to the appropriate place in th= at case), but I have two questions about the propose mitigation (and the th= inking behind it) that I think the write-up could address:

1. Could the writeup clarify whether/how the primary "m= ixup" threat differs from what RFC6819 identifies as in section 4.6.4?=

2. Has the workgroup considered a mitigation that puts more = responsibility on the authorization server, and less on the client? For exa= mple, if would be helpful for the writeup to clarify why having the client = send an "audience field" (in the terminology of RFC6819) to the a= uthorization endpoint would not mitigate the threat. (In that scenario, the= authorization server can recognize that the audience does not correspond t= o a resource server it knows, rather than asking clients to make this check= ). I assume this approach has been considered and rejected as an incomplete= mitigation, but I don't have visibility into where/how that discussion= went.

Thanks,

Josh

https://tools.ietf.org/html/draft-= jones-oauth-mix-up-mitigation-00

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

Note: This call is related to the announcement made on the list earlier
this month, see
http://www.ietf.org/mail-archive/web= /oauth/current/msg15336.html. More
time for analysis is provided due to the complexity of the topic.

Ciao
Hannes & Derek


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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a113a99d02aff980529d9140d-- From nobody Thu Jan 21 06:41:38 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059661A88AD for ; Thu, 21 Jan 2016 06:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHFbO3q4W_sR for ; Thu, 21 Jan 2016 06:41:34 -0800 (PST) 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 498871A88A3 for ; Thu, 21 Jan 2016 06:41:34 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id o6so16509977qkc.2 for ; Thu, 21 Jan 2016 06:41:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=QCnfN5+JAowzmtPt+4I6IrxdCc02rZTyraX+BkOq0Eo=; b=jw4OkfCwwYc6rdDNABS8abmLoqiNKNMHIWqUY04KrZ5tkfck6JwIeZm7z5r/PH05DY oxISz/wzVDVLMoAeXZROStrqjvjrcp/dQ81gYTpewMepR+3ySI1LeobEhaRskkG8fJ5u 6tO6+QWcwjsXizUmxEfIWG+C7ObInxBedmaHJ9HfHlevkXs/Jch9rOvj85yiduS8in6x EwWsXCL2WPQwiq5peZuC2K694hHyENvFgOreGSK4CpeoWS4ayPee9RyjnkaFMOWG+0dw gGxAZHCAsSiOBUCNwVvsq1stpQysncac/q5xGEaxwQeijImwVB/YyOQ1c6K/iHPVmnGJ NsLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=QCnfN5+JAowzmtPt+4I6IrxdCc02rZTyraX+BkOq0Eo=; b=DAdIjQIX340ZWujef3AwIrQYbJ1x1GtpXraG7Camw72VQzw4tgO2Ud8L9vZ0xxCxcL k6u6JNaDH0TtUrAuCoJ5t8g1xdYQF8HkHMGN9JpZab+OnqiHvEC61jZZHxPRFuase+gN jwmmXekqIFhZe6ZjjcnwwNYbiI9b5nCe0kBt90YpzjmVQldPtVhZNqesqtEvAW/V/tVc XZ9pwvtT3VotADWEkUBO5fKMALn0oLQtACoEylI0an/MmXtn0guSS9KK029Y/qcRnIzj cf1a6Haqv/yos2zDlEv786/DC4x0wAXs9SUNBYrBsp5xDLm2XOxroAQGmbWcbcL+34nR lXhg== X-Gm-Message-State: ALoCoQn8lIEBDSI7WFUNpZCeTEEuAPZmqBgEq0l+ADiudAMXbLAxScCXwZpYUWMIdGEqrtUUn6IpJdpILOdbEooGjQ2iCZQLWg== X-Received: by 10.55.78.70 with SMTP id c67mr51799775qkb.37.1453387293403; Thu, 21 Jan 2016 06:41:33 -0800 (PST) Received: from [192.168.8.100] ([181.202.73.168]) by smtp.gmail.com with ESMTPSA id e34sm650345qga.4.2016.01.21.06.41.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 06:41:32 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_9510D4B7-5ACB-445D-A508-54762E9A76D4"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Thu, 21 Jan 2016 11:41:31 -0300 Message-Id: References: To: Michael Jones X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:41:37 -0000 --Apple-Mail=_9510D4B7-5ACB-445D-A508-54762E9A76D4 Content-Type: multipart/alternative; boundary="Apple-Mail=_6DA1AD91-F2BE-4823-9B67-9017DB5CEC1D" --Apple-Mail=_6DA1AD91-F2BE-4823-9B67-9017DB5CEC1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We merged the state verification in with this rather than forcing people = to also look at the JWT encoded State draft. = https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state. =20 While JWT encoded state is how I would do state in a client and at-least = one client I know of uses it, it is not the only way to manage state, = and I am hesitant that developers might be scared away by thinking they = need to encode state as a JWT. I decided that cross referencing them is better. This made sending = much simpler to describe. =20 I also removed the hashing from state. That cut the text by about 2/3 = by not having to describe character set normalization so that both the = client and the AS could calculate the same hash. That also achieved the goal of not requiring a simple OAuth client doing = the code flow to add a crypto library to support SHA256. Once we make a algorithm mandatory, we need to defend why we don=E2=80=99t= have crypto agility eg support for SHA3 etc. We would be forced by the = IESG to add another parameter to the request to specify the hash alg if = we went that direction. Given that we assume state to be public info in the request that an = attacker can see, hashing state provides not much value for a lot of = complexity that people may get wrong or not implement. I appreciate why from a theory point of view hashing it would have been = better. If people really want it I can add it back. John B. > On Jan 21, 2016, at 3:28 AM, Mike Jones = wrote: >=20 > John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up = Mitigation draft. Changes were: > =C2=B7 Simplified by no longer specifying the signed JWT method = for returning the mitigation information. > =C2=B7 Simplified by no longer depending upon publication of a = discovery metadata document. > =C2=B7 Added the =E2=80=9Cstate=E2=80=9D token request = parameter. > =C2=B7 Added examples. > =C2=B7 Added John Bradley as an editor. > =20 > The specification is available at: > =C2=B7 = http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 = > =20 > An HTML-formatted version is also available at: > =C2=B7 = http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html = = > =20 > -- Mike > =20 > P.S. This note was also posted at http://self-issued.info/?p=3D1526 = and as @selfissued = . > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_6DA1AD91-F2BE-4823-9B67-9017DB5CEC1D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We merged the state verification in with this rather than = forcing people to also look at the JWT encoded State draft.  https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-sta= te.  

While = JWT encoded state is how I would do state in a client and at-least one = client I know of uses it, it is not the only way to manage state, and I = am hesitant that developers might be scared away by thinking they need = to encode state as a JWT.

I decided that cross referencing them is better.   This = made sending much simpler to describe.   

I also removed the = hashing from state.   That cut the text by about 2/3 by not having = to describe character set normalization so that both the client and the = AS could calculate the same hash.
That also = achieved the goal of not requiring a simple OAuth client doing the code = flow to add a crypto library to support SHA256.

Once we make a algorithm mandatory, we = need to defend why we don=E2=80=99t have crypto agility eg support for = SHA3 etc.  We would be forced by the IESG to add another parameter = to the request to specify the hash alg if we went that = direction.

Given= that we assume state to be public info in the request that an attacker = can see, hashing state provides not much value for a lot of complexity = that people may get wrong or not implement.

I appreciate why from a theory point of = view hashing it would have been better.

If people really want it I can add it = back.

John = B.

On Jan 21, 2016, at 3:28 AM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

John Bradley and I collaborated to = create the second OAuth 2.0 Mix-Up Mitigation draft.  Changes = were:
=C2=B7       Simplifi= ed by no longer specifying the signed JWT method for returning the = mitigation information.
=C2=B7       Simplifi= ed by no longer depending upon publication of a discovery metadata = document.
=C2=B7       Added = the =E2=80=9Cstate=E2=80=9D token request parameter.
=C2=B7       Added = examples.
=C2=B7       Added = John Bradley as an editor.
 
The specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-= 01
 
An HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigatio= n-01.html
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;          -- Mike
 
P.S.  = This note was also posted at http://self-issued.info/?p=3D1526 and as @selfissued.
 
_______________________________________________
OAuth mailing = list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_6DA1AD91-F2BE-4823-9B67-9017DB5CEC1D-- --Apple-Mail=_9510D4B7-5ACB-445D-A508-54762E9A76D4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMjExNDQxMzFaMCMGCSqGSIb3DQEJBDEWBBRQdg/e91+Nauiwnv3I1QmZ qGQf9zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQB+zu2ysGujd+5E1jglX6w8sf7obGOPYNbV9KTpIKjps+bnDLF3zqj0 YboO23R7bnwOtBmgh2H1GBtWbCcaVBraq8wkpYKgGH9ZHx0EgP+t6HnRc96fmHkakExZZQ9JwpbV IF+lm4TllVwfcBNuAdNDYflhkXSEBl84pCBLYRryywQnsIqyunycovcMHsClVGpzU+1qGEfEUxov wC4mlXjwDK/3Rhc72BlmrAdXKZZYilJ030G+iYjamXvuK3iO1wbbCiKVvEkQZAQ3Xw5vbgBe2Zso xzZkBhI7zeeJsf5xhkqEUF1vuhd1MiVYwL+fM6Ix8va3SJohLSLpkusod3LBAAAAAAAA --Apple-Mail=_9510D4B7-5ACB-445D-A508-54762E9A76D4-- From nobody Thu Jan 21 06:48:47 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BD81A88DC for ; Thu, 21 Jan 2016 06:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTk-anvv-BUK for ; Thu, 21 Jan 2016 06:48:44 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D451A894E for ; Thu, 21 Jan 2016 06:48:44 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id x1so16585592qkc.1 for ; Thu, 21 Jan 2016 06:48:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=l269zwqleGchwlXK+m+FQk3Wros9f08F06oH1wHRD4A=; b=H22heENZgdZNyNcxRPunZ5BGSEySOR2mILbzpJHvvhol4L+K/cxb4Og/3/mUQ2CbwT p8IU9apAvVfq0jS1uhG2HMiGIoh0/qmyXMmuHvafcpMT7Y2dvqCv1UAGe11tVTBUP1I/ pgdpp4jk5V6dvbQVDS6OHWx6uH3QrGL+M+EZl4rkSxCKI060NTRqV1eZSKldx7/3XwqF r0cDtCHSEJcVzpo+CE3ypB5f2mE6Eg2v2uNsvMNU850hn3K6JhxZZgHrv3x+UzjyZZvj YCAWsrrIN6UnSf8uiAGPElsbkFmXeGXpP7/ZzNjz+eJsL5dAyaSEH9iHovxeIKejxEqN JtHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=l269zwqleGchwlXK+m+FQk3Wros9f08F06oH1wHRD4A=; b=PQq4yTQw7fxtdG625pRXHyfJ/a+ABbfBOGRnSjh8I3xyN6RncMUZfsINRH8KsXEk12 ZDJuRA4VldyUxFrwe1MC2z1mZI1ZF7e1KE/Bb5vl7bRgjQmPaxma0+9O4Kz6z4THHyGE eK8k+phBIGAcchl+kJv+X2HFydN54gGnLd47vsCYW8gAfcRYJ7aVcNC8Ridnh7KIY4CG +cSuC8GYtZu8sxA/9f8HBRC98K7Mp4Gq2ujBNGdWS/H4OCMirolv6LSqBZ4YKO21vKE1 QUwn4MrbkgaC55XYlbve588nF4tBNSgwWtPQVjdayGGfeA42Fdf/MqJ1v7MmXKY9Bd1O 1tWQ== X-Gm-Message-State: ALoCoQnlajcjysIrCmEzPThIpYkvdhPaSrm+7CadN36cmLEfeORU/lTxxCOGyLvL/iMfqAPC35ZDqJ1bYouEdB1zMFddLO+PZA== X-Received: by 10.55.78.198 with SMTP id c189mr53041070qkb.95.1453387723188; Thu, 21 Jan 2016 06:48:43 -0800 (PST) Received: from [192.168.8.100] ([181.202.73.168]) by smtp.gmail.com with ESMTPSA id t103sm647724qgd.37.2016.01.21.06.48.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 06:48:42 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_F8A28447-8640-404C-8C67-A28B24577210"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: John Bradley In-Reply-To: Date: Thu, 21 Jan 2016 11:48:41 -0300 Message-Id: <28F1D605-CE87-4E74-8037-740EEB6129C7@ve7jtb.com> References: <569E2260.4080904@gmx.net> To: Nat Sakimura X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:48:46 -0000 --Apple-Mail=_F8A28447-8640-404C-8C67-A28B24577210 Content-Type: multipart/alternative; boundary="Apple-Mail=_172076A6-CEC4-4180-8303-E21B387AE546" --Apple-Mail=_172076A6-CEC4-4180-8303-E21B387AE546 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes we did discuss changing the title as part of adopting it. > On Jan 21, 2016, at 11:28 AM, Nat Sakimura wrote: >=20 > +1 apart from the title... It sounds like the spec is implementing = OAuth Open Redirector...=20 > Something like "preventing OAuth open redirector" or so might be more = descriptive.=20 >=20 > Nat >=20 > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:08 John Bradley = >: > +1 for adoption >=20 >> On Jan 21, 2016, at 3:18 AM, William Denniss > wrote: >>=20 >> +1 for adoption. >>=20 >> On Tue, Jan 19, 2016 at 7:47 PM, Hannes Tschofenig = > wrote: >> Hi all, >>=20 >> this is the call for adoption of OAuth 2.0 Security: OAuth Open >> Redirector, see >> https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02 = >>=20 >> Please let us know by Feb 2nd whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >>=20 >> Note: At the IETF Yokohama we asked for generic feedback about doing >> security work in the OAuth working group and there was very positive >> feedback. However, for the adoption call we need to ask for = individual >> documents. Hence, you need to state your view again. >>=20 >> Ciao >> Hannes & Derek >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth = --Apple-Mail=_172076A6-CEC4-4180-8303-E21B387AE546 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes we did discuss changing the title as part of adopting = it.

On Jan 21, 2016, at 11:28 AM, Nat Sakimura = <sakimura@gmail.com> wrote:

+1 apart from the title... It sounds like the spec is = implementing OAuth Open Redirector... 
Something like "preventing OAuth open redirector" or so might = be more descriptive. 

Nat

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) = 23:08 John Bradley <ve7jtb@ve7jtb.com>:
+1 = for adoption

On Jan 21, 2016, at 3:18 AM, William Denniss = <wdenniss@google.com> wrote:

+1 for adoption.

On Tue, = Jan 19, 2016 at 7:47 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> = wrote:
Hi all,

this is the call for adoption of OAuth 2.0 Security: OAuth Open
Redirector, see
https://tools.ietf.org/html/draft-bradley-oauth-open-redirector= -02

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

Note: At the IETF Yokohama we asked for generic feedback about doing
security work in the OAuth working group and there was very positive
feedback. However, for the adoption call we need to ask for = individual
documents. Hence, you need to state your view again.

Ciao
Hannes & Derek





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


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

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

= --Apple-Mail=_172076A6-CEC4-4180-8303-E21B387AE546-- --Apple-Mail=_F8A28447-8640-404C-8C67-A28B24577210 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNjAxMjExNDQ4NDFaMCMGCSqGSIb3DQEJBDEWBBSaRAAGhRFW3tSmlRVql1+G aWHFPDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQCUJfxIAcp6h+uM1VrjIWghOuoaMCO67M5eBDpBmpfbwdhkLTI22dVe s+9nEKNJPsllqxxH8fa/wVLImBA+Ck+hnYk+QFPt1Wlq1h61HNLxIPXEbDF8olgvz7LVF2d3/CKI khK5jTD1CD0J732VTpNMOEgqLRsw4CaJW1WeZDnuwj7tHynoBeRMSOPy16h4hQQAC38vPQ7NaooT F7dCGdXu0k05UQrh0nfWj67XDywXlucstosW2y+b0y3hyIUS6eiDuhAFaWo0W+aTIW/MRJAwtBhN g7jRpXiu7FmvYCaav6HMBwcBfhtVrORdOaNrTwLGedvgrCWaRC1qGbTDkbtBAAAAAAAA --Apple-Mail=_F8A28447-8640-404C-8C67-A28B24577210-- From nobody Thu Jan 21 06:50:43 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EA61A70FD for ; Thu, 21 Jan 2016 06:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NX73zqG3ssiP for ; Thu, 21 Jan 2016 06:50:40 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::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 D4C1A1A7D84 for ; Thu, 21 Jan 2016 06:50:39 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id v14so50426035ykd.3 for ; Thu, 21 Jan 2016 06:50:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JlsI1VrGHf4meSFWlfiP+i3gQnmpMe3xf88sLA/IHWY=; b=XL+xMjiJzlYs0lcG+k1vLK10/V9wozhmlz+Om9Kx2L4hQ/OOST1tc69hZR0pA1cYmt 92957FfZGc8j08l0wM1wDjtCtjNtitiJzNSNMHIVw/oYsbT1eX5lqRVQwhripdp1n978 RykUXjJHOGbmvrzAj51SzYVyv/SBxi5d00GiQ9ZLJ4AY8mzib5XadzRlysq3lu3LHVLl XkTrf+MwhH4CoSbVKxA+L05k+0vxgbj+tzxAJq1Z5/E1FgQn8WKm7hL/0I08sf9pLVb0 0+AliuSVfonsMWxCJMT+e/OO36RLOMiIQgYmSe+52r+pwmJThPYjmQPEEPp+7RanD5f3 LEKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JlsI1VrGHf4meSFWlfiP+i3gQnmpMe3xf88sLA/IHWY=; b=EW+y8csv2D6BQrL6FuTPM0JmuhBFQbYnKeSX+6gZa0HyTOiyZmsWNcJCrq91BODI+2 BRdN62IU55IplzCgCM0DbwZqNQabVAnTkL6kI1Sk3fsf55v8nfe8387xt03cH6tbtOaW ff4Tgc8QRG+Ba9Tv6nQ91JGPJ38oyFjn7BeeoAA7cApkHwqFTgvjybU+7SNxCXixh4vk M/7cOVNBW8bCc1vMC2yE2VHzxnRpEpbPFJfKPcs6NIwqyvnYSdbYv0Go9uNf40bL0FtU LFQD8E7s5FxLvz/KTcL9AwpfwUVVYoUuKTkMh0VD4S07+dyopnzg7wRfyPX2QcPM6zZV MIIw== X-Gm-Message-State: ALoCoQm6Zk4q1y3Nujev1R5rJrp3mMVWatsLBkl/M22JKZCT0mLh0kD7+6Lq7wDxnvbIYQQ+JGKq0CzR6U/8BAcDOUv4xvB8Lg== MIME-Version: 1.0 X-Received: by 10.37.231.135 with SMTP id e129mr13538528ybh.145.1453387839174; Thu, 21 Jan 2016 06:50:39 -0800 (PST) Received: by 10.37.224.84 with HTTP; Thu, 21 Jan 2016 06:50:39 -0800 (PST) Received: by 10.37.224.84 with HTTP; Thu, 21 Jan 2016 06:50:39 -0800 (PST) In-Reply-To: References: <569E22E1.5010402@gmx.net> Date: Thu, 21 Jan 2016 09:50:39 -0500 Message-ID: From: Josh Mandel To: Nat Sakimura Content-Type: multipart/alternative; boundary=94eb2c0b0faae0060a0529d9393a Archived-At: Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 14:50:43 -0000 --94eb2c0b0faae0060a0529d9393a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Nat - that's helpful. If both mitigations *can* work effectively, then I would like to see this group consider the decision between them carefully (if that hasn't happened yet). Again, don't hesitate to let me know if this is the wrong place/time for such discussion. At a high level, I would rather ask server developers to do some "coding", for two reasons: 1. Most OAuth servers talk to many, many clients. So consolidating the security critical work in one place (server) is a net savings of work (rather than asking each client to implement these checks. 2. OAuth server developers are typically more sophisticated than client developers, and therefore more likely to understand the implications and more likely to get these critical details correct. Asking each client developer to do something right is likely to result in heterogenius implementation and persistent security holes. But if the server does the heavy lifting, and clients just have to pass along an extra parameter, this is more likely to see consistent implementation (for example, clients will fail to work if misconfigured, which will prompt developers to fix them). On Jan 21, 2016 09:40, "Nat Sakimura" wrote: > Hi Josh, > > It is similar but slightly different IMHO. > > Section 4.6.4 of the RFC6819 is the access token phishing by a counterfei= t > resource server. > The mix-up attack described here is the code phishing by a counterfeit > token endpoint. > > In my view, both can be mitigated by the server returning the next step: > i.e., authorization endpoint returning the legitimate token endpoint uri, > and token endpoint returning legitimate resource endpoint uris. This > involves no discovery endpoint, which is good. > > Your way also works. It is just the reverse of my proposal. The differenc= e > being that my proposal does not need any coding on the server but just > configuration, and it can return more metadata if needed. > > Cheers, > > Nat > > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel : > >> Apologies if this is the wrong forum for my comment (and please direct m= e >> to the appropriate place in that case), but I have two questions about t= he >> propose mitigation (and the thinking behind it) that I think the write-u= p >> could address: >> >> 1. Could the writeup clarify whether/how the primary "mixup" threat >> differs from what RFC6819 identifies as in section 4.6.4? >> >> 2. Has the workgroup considered a mitigation that puts more >> responsibility on the authorization server, and less on the client? For >> example, if would be helpful for the writeup to clarify why having the >> client send an "audience field" (in the terminology of RFC6819) to the >> authorization endpoint would not mitigate the threat. (In that scenario, >> the authorization server can recognize that the audience does not >> correspond to a resource server it knows, rather than asking clients to >> make this check). I assume this approach has been considered and rejecte= d >> as an incomplete mitigation, but I don't have visibility into where/how >> that discussion went. >> >> Thanks, >> >> Josh >> Hi all, >> >> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see >> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 >> >> Please let us know by Feb 9th whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >> >> Note: This call is related to the announcement made on the list earlier >> this month, see >> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More >> time for analysis is provided due to the complexity of the topic. >> >> Ciao >> Hannes & Derek >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > --94eb2c0b0faae0060a0529d9393a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks Nat - that's helpful. If both mitigations *can* w= ork effectively, then I would like to see this group consider the decision = between them carefully (if that hasn't happened yet). Again, don't = hesitate to let me know if this is the wrong place/time for such discussion= .

At a high level, I would rather ask server developers to do = some "coding", for two reasons:

1. Most OAuth servers talk to many, many clients. So consoli= dating the security critical work in one place (server) is a net savings of= work (rather than asking each client to implement these checks.

2. OAuth server developers are typically more sophisticated = than client developers, and therefore more likely to understand the implica= tions and more likely to get these critical details correct. Asking each cl= ient developer to do something right is likely to result in heterogenius im= plementation and persistent security holes. But if the server does the heav= y lifting, and clients just have to pass along an extra parameter, this is = more likely to see consistent implementation (for example, clients will fai= l to work if misconfigured, which will prompt developers to fix them).

On Jan 21, 2016 09:40, "Nat Sakimura" = <sakimura@gmail.com> wrote:=
Hi= Josh,=C2=A0

It is similar but slightly different IMHO.= =C2=A0

Section 4.6.4 of the RFC6819 is the access = token phishing by a counterfeit resource server.=C2=A0
The mix-up= attack described here is the code phishing by a counterfeit token endpoint= .=C2=A0

In my view, both can be mitigated by the s= erver returning the next step: i.e., authorization endpoint returning the l= egitimate token endpoint uri, and token endpoint returning legitimate resou= rce endpoint uris. This involves no discovery endpoint, which is good.=C2= =A0

Your way also works. It is just the reverse of= my proposal. The difference being that my proposal does not need any codin= g on the server but just configuration, and it can return more metadata if = needed.=C2=A0

Cheers,=C2=A0

Nat

2016=E5= =B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel <jmandel@gmail.com>:

Apologies if this is the wr= ong forum for my comment (and please direct me to the appropriate place in = that case), but I have two questions about the propose mitigation (and the = thinking behind it) that I think the write-up could address:

1. Could the writeup clarify whether/how the primary "m= ixup" threat differs from what RFC6819 identifies as in section 4.6.4?=

2. Has the workgroup considered a mitigation that puts more = responsibility on the authorization server, and less on the client? For exa= mple, if would be helpful for the writeup to clarify why having the client = send an "audience field" (in the terminology of RFC6819) to the a= uthorization endpoint would not mitigate the threat. (In that scenario, the= authorization server can recognize that the audience does not correspond t= o a resource server it knows, rather than asking clients to make this check= ). I assume this approach has been considered and rejected as an incomplete= mitigation, but I don't have visibility into where/how that discussion= went.

Thanks,

Josh

https://tools.ietf.org/html/draft-= jones-oauth-mix-up-mitigation-00

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

Note: This call is related to the announcement made on the list earlier
this month, see
http://www.ietf.org/mail-archive/web= /oauth/current/msg15336.html. More
time for analysis is provided due to the complexity of the topic.

Ciao
Hannes & Derek


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

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--94eb2c0b0faae0060a0529d9393a-- From nobody Thu Jan 21 09:35:19 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E5D1B3365 for ; Thu, 21 Jan 2016 09:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XXV-tinwWAk for ; Thu, 21 Jan 2016 09:35:13 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4784C1B3364 for ; Thu, 21 Jan 2016 09:35:13 -0800 (PST) Received: by mail-ig0-x236.google.com with SMTP id z14so128964337igp.0 for ; Thu, 21 Jan 2016 09:35:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=HIbIw67E6BQPEtAa5DsHCzeg2ll3B52h4oQrKPnwnBw=; b=DLNPHfj8WA+IUWtjTV6YOMMZE7Y6CInc//ZRxdI4Iq52TgJvTytg+1uBT4FL8HBSku qvIjGNahkBJERJoTy7HlzAMwLFJK0rG33iAZwbxGf0k2LLY+7WoswWSW97Q+mHQtrv0f +Ckh5gb6V1WwBMJKCKv7c4vEk669yJbnXJK0A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HIbIw67E6BQPEtAa5DsHCzeg2ll3B52h4oQrKPnwnBw=; b=ZndkepZGy1nLfhraQd7S/FhN9Ul7m29wM7D5igxUerlkJztZfr9CcL0/ceStttXd9e P9MNYAazgxNWtxVDlS9/9xbBKYRwAsMHRv5c3aw/Uf9o1J8a+DIWmUVFnCFz5FODdGRI oMmBnVMufW3JNiI5Rd/3TnthaaaW+aMaWzrpj+ObK7TH3WE/z9qOKIWAhPkG9LVerx2R s3xRCwQPfM+i+sAC5tJqWiYYSmJjh1B1Iouz+Pq47yffP7E+hWRt7yR1oVxT0a/O3xaN mbIAqdqsee2TaLGJi1jK7ClSNiOeosEuDGGmmZhAPP0Wx19+8xH4ROKe8io4qEE4R/fq 8F4w== X-Gm-Message-State: AG10YOT4QzS7mcbu9nkwKisM1iVytj8NGewAkcPU67Lg31Bdh8mvy6dcQrfuhTVzwFg5//2O1oCCw34CK1MOm4U3 X-Received: by 10.50.13.102 with SMTP id g6mr11287674igc.77.1453397712461; Thu, 21 Jan 2016 09:35:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.212.69 with HTTP; Thu, 21 Jan 2016 09:34:42 -0800 (PST) In-Reply-To: <28F1D605-CE87-4E74-8037-740EEB6129C7@ve7jtb.com> References: <569E2260.4080904@gmx.net> <28F1D605-CE87-4E74-8037-740EEB6129C7@ve7jtb.com> From: Brian Campbell Date: Thu, 21 Jan 2016 10:34:42 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=089e013c66d65e78970529db864a Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 17:35:15 -0000 --089e013c66d65e78970529db864a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Thu, Jan 21, 2016 at 7:48 AM, John Bradley wrote: > Yes we did discuss changing the title as part of adopting it. > > On Jan 21, 2016, at 11:28 AM, Nat Sakimura wrote: > > +1 apart from the title... It sounds like the spec is implementing OAuth > Open Redirector... > Something like "preventing OAuth open redirector" or so might be more > descriptive. > > Nat > > 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:08 John Bradley : > >> +1 for adoption >> >> On Jan 21, 2016, at 3:18 AM, William Denniss wrote= : >> >> +1 for adoption. >> >> On Tue, Jan 19, 2016 at 7:47 PM, Hannes Tschofenig < >> hannes.tschofenig@gmx.net> wrote: >> >>> Hi all, >>> >>> this is the call for adoption of OAuth 2.0 Security: OAuth Open >>> Redirector, see >>> https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02 >>> >>> Please let us know by Feb 2nd whether you accept / object to the >>> adoption of this document as a starting point for work in the OAuth >>> working group. >>> >>> Note: At the IETF Yokohama we asked for generic feedback about doing >>> security work in the OAuth working group and there was very positive >>> feedback. However, for the adoption call we need to ask for individual >>> documents. Hence, you need to state your view again. >>> >>> Ciao >>> Hannes & Derek >>> >>> >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --089e013c66d65e78970529db864a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Thu, Jan 21, 2016 at 7:48 AM, John Bradley <ve7jtb@ve7jtb.c= om> wrote:
Yes we did discuss changing the title as part of adopti= ng it.

O= n Jan 21, 2016, at 11:28 AM, Nat Sakimura <sakimura@gmail.com> wrote:

=
+1 apart from the title... It sounds like the spec is impl= ementing OAuth Open Redirector...=C2=A0
Something like "preven= ting OAuth open redirector" or so might be more descriptive.=C2=A0

Nat

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:08 John Bradley = <ve7jtb@ve7jtb.co= m>:
+1 for adoption
<= br>
On Jan 21, 2016, at 3:18 AM, William= Denniss <wdenn= iss@google.com> wrote:

+1 for adoptio= n.

On Tue, J= an 19, 2016 at 7:47 PM, Hannes Tschofenig <hannes.tschofenig@gmx.n= et> wrote:
Hi all,

this is the call for adoption of OAuth 2.0 Security: OAuth Open
Redirector, see
https://tools.ietf.org/html/draft-= bradley-oauth-open-redirector-02

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

Note: At the IETF Yokohama we asked for generic feedback about doing
security work in the OAuth working group and there was very positive
feedback. However, for the adoption call we need to ask for individual
documents. Hence, you need to state your view again.

Ciao
Hannes & Derek





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


_______________________________________________
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


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


--089e013c66d65e78970529db864a-- From nobody Thu Jan 21 10:14:48 2016 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA271A893F for ; Thu, 21 Jan 2016 10:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8OLAuxaEc2O for ; Thu, 21 Jan 2016 10:14:43 -0800 (PST) Received: from omr-m008e.mx.aol.com (omr-m008e.mx.aol.com [204.29.186.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78221A8953 for ; Thu, 21 Jan 2016 10:14:42 -0800 (PST) Received: from mtaout-maa01.mx.aol.com (mtaout-maa01.mx.aol.com [172.26.222.141]) by omr-m008e.mx.aol.com (Outbound Mail Relay) with ESMTP id 654B5380031D; Thu, 21 Jan 2016 13:14:41 -0500 (EST) Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-maa01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id DBED2380000B4; Thu, 21 Jan 2016 13:14:40 -0500 (EST) To: Roland Hedberg , William Denniss References: <569E2231.1010107@gmx.net> <6ADAA1B5-7EF9-49EA-A3D9-6EFC57275EB9@ve7jtb.com> <9062E913-39FB-4610-80FE-70796CBDEAC1@ve7jtb.com> From: George Fletcher Organization: AOL LLC Message-ID: <56A12010.6090700@aol.com> Date: Thu, 21 Jan 2016 13:14:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000702080106090103010307" x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453400081; bh=mwYiQJjga1b0c3Bb8tR/GME2jlchNdA6tqRP+bKZJek=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=kWutyK74JElzEbi7FsOh8v6enGk4QsfMlhvSXAtmhVFp8fIqvwjktP9+LHoQzdFfA apTFpfmV2Dw3IHzIpj8udQMm+xlndjjgFPeleVGSiX5naZu52GnhqyZ38jCh321zf3 1/V6zHlF69rHi3QXSfbTvYHFLIbOAXH5dL1yOJ0I= x-aol-sid: 3039ac1ade8d56a12010369b X-AOL-IP: 10.172.102.124 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2016 18:14:47 -0000 This is a multi-part message in MIME format. --------------000702080106090103010307 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit I'm also +1 for adoption On 1/21/16 2:56 AM, Roland Hedberg wrote: > +1 for adoption > >> 21 jan 2016 kl. 07:11 skrev William Denniss : >> >> I believe this is important work. >> >> The original OAuth 2 spec left the topic of native apps largely undefined which is fair enough, the mobile-first revolution had yet to really take hold and people didn't have much implementation experience for OAuth on mobile. But we've come a long way since then, we have the experience now and I think there is a need for leadership in this space, and that it makes sense for the OAUTH-WG to continue our work and provide that leadership. >> >> The risk of not defining a best practice for native apps is dilution of the open standards – if everyone implements OAuth differently for native apps, and RPs have to write IDP-specific code then what is the point of having OAuth as a standard in the first place? Security is a major concern as well, there are a lot of ways to mess this up and the security situation for OAuth in many native apps is not nearly as good as it could be. >> >> By providing leadership in the form of a working group document, we can present community advice with the hope that IDPs and RPs alike will follow our recommendations, resulting in more interoperability, better usability and higher security. >> >> The best part about this spec is that it's pure OAuth! Just wrapped with some native app specific recommendations for both RPs and IDPs, to achieve the desired levels of usability and security on mobile. >> >> I will point out that we have rough consensus and running code. The rough consensus can be seen from the WG votes, and the sentiment on this thread (your dissenting opinion notwithstanding). Regarding running code, my team is in the process of open sourcing libraries that will implement this best practice to the letter (and the code's already running, I assure you). The proprietary Google Sign-in and Facebook Sign-in SDKs are also using in-app browser tabs for OAuth flows in production today, which I think is further evidence that this is a viable pattern. >> >> This document and proposal was never part of the OpenID working group that you refer to below. >> >> I'm not saying the document is perfect, and it is definitely in need of an update! But I'm committed to listening to the community and taking it forward. Now that the dependencies have launched, and our library implementations are done, I plan to update the doc with the feedback from this community, and the lessons we and others have learnt from our implementations. >> >> I hope the working group will consider adopting this document. >> >> Kind Regards, >> William >> >> >> On Thu, Jan 21, 2016 at 12:33 PM, Anthony Nadalin wrote: >> This work had many issues in the OpenID WG where it failed why should this be a WG item here ? The does meet the requirements for experimental, there is a fine line between informational and experimental, I would be OK with either but prefer experimental, I don’t think that this should become a standard. >> >> >> >> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley >> Sent: Wednesday, January 20, 2016 12:11 PM >> To: Nat Sakimura >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps >> >> >> >> PS as you probably suspected I am in favour of moving this forward. >> >> >> >> >> >> On Jan 20, 2016, at 5:08 PM, Nat Sakimura wrote: >> >> >> >> +1 for moving this forward. >> >> 2016å¹´1月21日木曜日ã€John Bradleyã•ã‚“ã¯æ›¸ãã¾ã—ãŸ: >> >> Yes more is needed. It was theoretical at that point. Now we have implementation experience. >> >> >> >> On Jan 20, 2016, at 3:38 PM, Brian Campbell wrote: >> >> >> >> There is https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#appendix-A which has some mention of SFSafariViewController and Chrome Custom Tabs. >> >> Maybe more is needed? >> >> >> >> On Wed, Jan 20, 2016 at 10:45 AM, John Bradley wrote: >> >> Yes, in July we recommended using the system browser rather than WebViews. >> >> >> >> About that time Apple announced Safari view controller and Google Chrome custom tabs. The code in the OS is now stable and we have done a fair amount of testing. >> >> >> >> The OIDF will shortly be publishing reference libraries for iOS and Android to how how to best use View Controllers, and PKCE in native apps on those platforms. >> >> >> >> We do need to update this doc to reflect what we have learned in the last 6 months. >> >> >> >> One problem we do still have is not having someone with Win 10 mobile experience to help document the best practices for that platform. >> >> I don’t understand that platform well enough yet to include anything. >> >> >> >> John B. >> >> >> >> On Jan 20, 2016, at 12:40 PM, Aaron Parecki wrote: >> >> >> >> The section on embedded web views doesn't mention the new iOS 9 SFSafariViewController which allows apps to display a system browser within the application. The new API doesn't give the calling application access to anything inside the browser, so it is acceptable for using with OAuth flows. I think it's important to mention this new capability for apps to leverage since it leads to a better user experience. >> >> >> >> I'm sure that can be addressed in the coming months if this document is just the starting point. >> >> >> >> I definitely agree that a document about native apps is necessary since the core leaves a lot of guessing room for an implementation. >> >> >> >> For reference, https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_26 >> >> >> >> And see the attached screenshot for an example of what it looks like. >> >> >> >> >> >> >> >> ---- >> >> Aaron Parecki >> >> aaronparecki.com >> >> @aaronpk >> >> >> >> >> >> On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig wrote: >> >> Hi all, >> >> this is the call for adoption of OAuth 2.0 for Native Apps, see >> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ >> >> Please let us know by Feb 2nd whether you accept / object to the >> adoption of this document as a starting point for work in the OAuth >> working group. >> >> Note: If you already stated your opinion at the IETF meeting in Yokohama >> then you don't need to re-state your opinion, if you want. >> >> The feedback at the Yokohama IETF meeting was the following: 16 persons >> for doing the work / 0 persons against / 2 persons need more info >> >> Ciao >> Hannes & Derek >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> >> >> >> -- >> Nat Sakimura (=nat) >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en >> >> >> >> >> >> >> _______________________________________________ >> 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 -- Chief Architect Identity Services Engineering Work: george.fletcher@teamaol.com AOL Inc. AIM: gffletch Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch Office: +1-703-265-2544 Photos: http://georgefletcher.photography --------------000702080106090103010307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I'm also +1 for adoption

On 1/21/16 2:56 AM, Roland Hedberg wrote:
+1 for adoption


21 jan 2016 kl. 07:11 skrev William Denniss <wdenniss@google.com>:

I believe this is important work.

The original OAuth 2 spec left the topic of native apps largely undefined which is fair enough, the mobile-first revolution had yet to really take hold and people didn't have much implementation experience for OAuth on mobile. But we've come a long way since then, we have the experience now and I think there is a need for leadership in this space, and that it makes sense for the OAUTH-WG to continue our work and provide that leadership.

The risk of not defining a best practice for native apps is dilution of the open standards – if everyone implements OAuth differently for native apps, and RPs have to write IDP-specific code then what is the point of having OAuth as a standard in the first place? Security is a major concern as well, there are a lot of ways to mess this up and the security situation for OAuth in many native apps is not nearly as good as it could be.

By providing leadership in the form of a working group document, we can present community advice with the hope that IDPs and RPs alike will follow our recommendations, resulting in more interoperability, better usability and higher security.

The best part about this spec is that it's pure OAuth! Just wrapped with some native app specific recommendations for both RPs and IDPs, to achieve the desired levels of usability and security on mobile.

I will point out that we have rough consensus and running code. The rough consensus can be seen from the WG votes, and the sentiment on this thread (your dissenting opinion notwithstanding). Regarding running code, my team is in the process of open sourcing libraries that will implement this best practice to the letter (and the code's already running, I assure you). The proprietary Google Sign-in and Facebook Sign-in SDKs are also using in-app browser tabs for OAuth flows in production today, which I think is further evidence that this is a viable pattern.

This document and proposal was never part of the OpenID working group that you refer to below.

I'm not saying the document is perfect, and it is definitely in need of an update! But I'm committed to listening to the community and taking it forward. Now that the dependencies have launched, and our library implementations are done, I plan to update the doc with the feedback from this community, and the lessons we and others have learnt from our implementations.

I hope the working group will consider adopting this document.

Kind Regards,
William


On Thu, Jan 21, 2016 at 12:33 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
This work had many issues in the OpenID WG where it failed why should this be a WG item here ? The does meet the requirements for experimental, there is a fine line between informational and experimental, I would be OK with either but prefer experimental, I don’t think that this should become a standard.



From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, January 20, 2016 12:11 PM
To: Nat Sakimura <sakimura@gmail.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps



PS as you probably suspected I am in favour of moving this forward.





On Jan 20, 2016, at 5:08 PM, Nat Sakimura <sakimura@gmail.com> wrote:



+1 for moving this forward.

2016å¹´1月21日木曜日ã€John Bradley<ve7jtb@ve7jtb.com>ã•ã‚“ã¯æ›¸ãã¾ã—ãŸ:

Yes more is needed.   It was theoretical at that point.  Now we have implementation experience.



On Jan 20, 2016, at 3:38 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:



There is https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#appendix-A which has some mention of SFSafariViewController and Chrome Custom Tabs.

Maybe more is needed?



On Wed, Jan 20, 2016 at 10:45 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, in July we recommended using the system browser rather than WebViews.



About that time Apple announced Safari view controller and Google Chrome custom tabs.   The code in the OS is now stable and we have done a fair amount of testing.



The OIDF will shortly be publishing reference libraries for iOS and Android to how how to best use View Controllers, and PKCE in native apps on those platforms.



We do need to update this doc to reflect what we have learned in the last 6 months.



One problem we do still have is not having someone with Win 10 mobile experience to help document the best practices for that platform.

I don’t understand that platform well enough yet to include anything.



John B.



On Jan 20, 2016, at 12:40 PM, Aaron Parecki <aaron@parecki.com> wrote:



The section on embedded web views doesn't mention the new iOS 9 SFSafariViewController which allows apps to display a system browser within the application. The new API doesn't give the calling application access to anything inside the browser, so it is acceptable for using with OAuth flows. I think it's important to mention this new capability for apps to leverage since it leads to a better user experience.



I'm sure that can be addressed in the coming months if this document is just the starting point.



I definitely agree that a document about native apps is necessary since the core leaves a lot of guessing room for an implementation.



For reference, https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_26



And see the attached screenshot for an example of what it looks like.



<embedded-oauth-view.png>



----

Aaron Parecki

aaronparecki.com

@aaronpk





On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see
http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/

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

Note: If you already stated your opinion at the IETF meeting in Yokohama
then you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 16 persons
for doing the work / 0 persons against / 2 persons need more info

Ciao
Hannes & Derek


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



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




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







--
Nat Sakimura (=nat)

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






_______________________________________________
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


    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------000702080106090103010307--


From nobody Thu Jan 21 10:30:17 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CE81A898B for ; Thu, 21 Jan 2016 10:30:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuKYbyw2lrIa for ; Thu, 21 Jan 2016 10:30:15 -0800 (PST)
Received: from omr-m019e.mx.aol.com (omr-m019e.mx.aol.com [204.29.186.18]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7951A896C for ; Thu, 21 Jan 2016 10:30:15 -0800 (PST)
Received: from mtaout-aab01.mx.aol.com (mtaout-aab01.mx.aol.com [172.26.126.205]) by omr-m019e.mx.aol.com (Outbound Mail Relay) with ESMTP id 2978838000B2; Thu, 21 Jan 2016 13:30:14 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aab01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 2B6353800009E; Thu, 21 Jan 2016 13:30:12 -0500 (EST)
References: <569E22E1.5010402@gmx.net> <3663C301-FE1B-465C-B8FF-3BBF2F4C0A43@adobe.com> <303991D4-7ED8-46A6-982A-B41C9DD573FB@adm.umu.se>
To: "oauth@ietf.org" 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56A123B3.8050608@aol.com>
Date: Thu, 21 Jan 2016 13:30:11 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <303991D4-7ED8-46A6-982A-B41C9DD573FB@adm.umu.se>
Content-Type: multipart/alternative; boundary="------------070305080906020200020900"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453401014; bh=i9X7KCCyOBQmkKOphFA5X/aHOp9q2ulxNQHKlECKXC8=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=VYO1K+nz8murgRmY9yO77NLrWDfxr4xnBnihGvxh63O6ZXMTfG0GZy93qAiBgZbCz EsU+6G4uVuvV3oPoF6FmIRJ2Nbd4Gj6Qbby0zne1mEbPOWoQ3mGpvKwsOWQ4iVKqyX i6yoNmGUexwPwLyb8nNHcsbh9CyaV16RKbL7CdPM=
x-aol-sid: 3039ac1a7ecd56a123b4594b
X-AOL-IP: 10.172.102.124
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 18:30:16 -0000

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

+1 for adoption

On 1/21/16 2:53 AM, Roland Hedberg wrote:
> +1 for adoption
>
>> 21 jan 2016 kl. 07:14 skrev Antonio Sanso :
>>
>> +1 for adoption
>> On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig  wrote:
>>
>>> Hi all,
>>>
>>> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
>>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>>>
>>> Please let us know by Feb 9th whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth
>>> working group.
>>>
>>> Note: This call is related to the announcement made on the list earlier
>>> this month, see
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
>>> time for analysis is provided due to the complexity of the topic.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


--------------070305080906020200020900
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1 for adoption

    

    
On 1/21/16 2:53 AM, Roland Hedberg
      wrote:

    

    

      
+1 for adoption



      

        
21 jan 2016 kl. 07:14 skrev Antonio Sanso <asanso@adobe.com>:

+1 for adoption
On Jan 19, 2016, at 12:49 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:



        

          
Hi all,

this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00

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

Note: This call is related to the announcement made on the list earlier
this month, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
time for analysis is provided due to the complexity of the topic.

Ciao
Hannes & Derek

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


        

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


      

      

      

      

      

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


    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------070305080906020200020900--


From nobody Thu Jan 21 10:34:43 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423E81A8999 for ; Thu, 21 Jan 2016 10:34:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrHPToC6ImJ6 for ; Thu, 21 Jan 2016 10:34:40 -0800 (PST)
Received: from omr-m014e.mx.aol.com (omr-m014e.mx.aol.com [204.29.186.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05DD71A8986 for ; Thu, 21 Jan 2016 10:34:40 -0800 (PST)
Received: from mtaout-aag02.mx.aol.com (mtaout-aag02.mx.aol.com [172.26.126.78]) by omr-m014e.mx.aol.com (Outbound Mail Relay) with ESMTP id 3D3B538000BE; Thu, 21 Jan 2016 13:34:39 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aag02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B1A9138000096; Thu, 21 Jan 2016 13:34:38 -0500 (EST)
To: John Bradley 
References: <569E2260.4080904@gmx.net>    <28F1D605-CE87-4E74-8037-740EEB6129C7@ve7jtb.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56A124BC.9050106@aol.com>
Date: Thu, 21 Jan 2016 13:34:36 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040802050801030301060207"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453401279; bh=GHH4SWIDqVHsbnj68aJ5+PusBUHhGRdi+H6mFYqllLM=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=zzcwGCXAVOhOZGMbJXaupSfUU9/HQh008FcNoUNKptjNIkT6HwfO9hBJhrPVZfT9d kmMbtP/fyrFsvPHNMYIwuCUrYXLGx/axC3cq0wIrS8hpPU/JBIj9gpxK0rtIt7w/H8 KxDP76dtBO/pyZ+VUBXJKW+U+O0vRbQG0awzP2Mw=
x-aol-sid: 3039ac1a7e4e56a124be73da
X-AOL-IP: 10.172.102.124
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 18:34:42 -0000

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

+1

On 1/21/16 12:34 PM, Brian Campbell wrote:
> +1
>
> On Thu, Jan 21, 2016 at 7:48 AM, John Bradley  > wrote:
>
>     Yes we did discuss changing the title as part of adopting it.
>
>>     On Jan 21, 2016, at 11:28 AM, Nat Sakimura >     > wrote:
>>
>>     +1 apart from the title... It sounds like the spec is
>>     implementing OAuth Open Redirector...
>>     Something like "preventing OAuth open redirector" or so might be
>>     more descriptive.
>>
>>     Nat
>>
>>     2016年1月21日(木) 23:08 John Bradley >     >:
>>
>>         +1 for adoption
>>
>>>         On Jan 21, 2016, at 3:18 AM, William Denniss
>>>         > wrote:
>>>
>>>         +1 for adoption.
>>>
>>>         On Tue, Jan 19, 2016 at 7:47 PM, Hannes Tschofenig
>>>         >>         > wrote:
>>>
>>>             Hi all,
>>>
>>>             this is the call for adoption of OAuth 2.0 Security:
>>>             OAuth Open
>>>             Redirector, see
>>>             https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02
>>>
>>>             Please let us know by Feb 2nd whether you accept /
>>>             object to the
>>>             adoption of this document as a starting point for work
>>>             in the OAuth
>>>             working group.
>>>
>>>             Note: At the IETF Yokohama we asked for generic feedback
>>>             about doing
>>>             security work in the OAuth working group and there was
>>>             very positive
>>>             feedback. However, for the adoption call we need to ask
>>>             for individual
>>>             documents. Hence, you need to state your view again.
>>>
>>>             Ciao
>>>             Hannes & Derek
>>>
>>>
>>>
>>>
>>>
>>>             _______________________________________________
>>>             OAuth mailing list
>>>             OAuth@ietf.org 
>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         OAuth@ietf.org 
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>>         _______________________________________________
>>         OAuth mailing list
>>         OAuth@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


--------------040802050801030301060207
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    +1

    

    
On 1/21/16 12:34 PM, Brian Campbell
      wrote:

    

    

      
+1

      

      


        
On Thu, Jan 21, 2016 at 7:48 AM, John
          Bradley <ve7jtb@ve7jtb.com>
          wrote:

          

            
Yes we did discuss
              changing the title as part of adopting it.
              

                

                  


                    

                      

                        
On Jan 21, 2016, at 11:28 AM, Nat Sakimura
                          <sakimura@gmail.com>
                          wrote:

                        

                        

                          
+1 apart from the title... It
                            sounds like the spec is implementing OAuth
                            Open Redirector... 

                            
Something like "preventing OAuth open
                              redirector" or so might be more
                              descriptive. 

                            


                            

                            
Nat

                          

                          

                          

                            
2016年1月21日(木) 23:08 John
                              Bradley <ve7jtb@ve7jtb.com>:

                            

                            

                              
+1 for
                                adoption

                              

                                


                                  

                                    

                                      
On Jan 21, 2016, at 3:18 AM,
                                        William Denniss <wdenniss@google.com>
                                        wrote:

                                      

                                      

                                        
+1 for adoption.

                                        


                                          
On
                                            Tue, Jan 19, 2016 at 7:47
                                            PM, Hannes Tschofenig <hannes.tschofenig@gmx.net>
                                            wrote:

                                            
Hi
                                              all,

                                              

                                              this is the call for
                                              adoption of OAuth 2.0
                                              Security: OAuth Open

                                              Redirector, see

                                              https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02

                                              

                                              Please let us know by Feb
                                              2nd whether you accept /
                                              object to the

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

                                              working group.

                                              

                                              Note: At the IETF Yokohama
                                              we asked for generic
                                              feedback about doing

                                              security work in the OAuth
                                              working group and there
                                              was very positive

                                              feedback. However, for the
                                              adoption call we need to
                                              ask for individual

                                              documents. Hence, you need
                                              to state your view again.

                                              

                                              Ciao

                                              Hannes & Derek

                                              

                                              

                                              

                                              

                                              

_______________________________________________

                                              OAuth mailing list

                                              OAuth@ietf.org

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

                                              

                                            

                                          

                                          

                                        

_______________________________________________

                                        OAuth mailing list

                                        OAuth@ietf.org

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

                                      

                                    

                                  

                                  

                                

                              

_______________________________________________

                              OAuth mailing list

                              OAuth@ietf.org

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

                            

                          

                        

                      

                    

                    

                  

                

              

            

            

            _______________________________________________

            OAuth mailing list

            OAuth@ietf.org

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

            

          

        

        

      

      

      

      

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


    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------040802050801030301060207--


From nobody Thu Jan 21 10:49:33 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86571A8A29 for ; Thu, 21 Jan 2016 10:49:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I36DhQU03S8b for ; Thu, 21 Jan 2016 10:49:30 -0800 (PST)
Received: from omr-m011e.mx.aol.com (omr-m011e.mx.aol.com [204.29.186.11]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B52A1A8A1D for ; Thu, 21 Jan 2016 10:49:30 -0800 (PST)
Received: from mtaout-maa01.mx.aol.com (mtaout-maa01.mx.aol.com [172.26.222.141]) by omr-m011e.mx.aol.com (Outbound Mail Relay) with ESMTP id 7634438000A7; Thu, 21 Jan 2016 13:49:29 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-maa01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id D953838000093; Thu, 21 Jan 2016 13:49:28 -0500 (EST)
To: Hannes Tschofenig , "oauth@ietf.org" 
References: <569E228B.1010309@gmx.net>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56A12838.7010901@aol.com>
Date: Thu, 21 Jan 2016 13:49:28 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <569E228B.1010309@gmx.net>
Content-Type: multipart/alternative; boundary="------------010802050905010207040508"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453402169; bh=LaAoscWvgbizl/wan5wSB5hHUAsTxo1F28iTrqczAGs=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=trPvwNnTdl0FchvtZyWmB24MNWPhP/yjBOvApuso7URY+ZHOoruq/7nsbiN9phvM1 iPqPyTMTIR8aNzM6dGFixoAR68P8PmhBp9CSHCqt4zr9gUe1arkuWFdtzve7gSJCot +Y478b/+SwYOC6gdaLpztAWj23fB9JPMLRFCwsSk=
x-aol-sid: 3039ac1ade8d56a128386b5f
X-AOL-IP: 10.172.102.124
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Device Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 18:49:32 -0000

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

+1 for adoption

On 1/19/16 6:48 AM, Hannes Tschofenig wrote:
> Hi all,
>
> this is the call for adoption of OAuth 2.0 Device Flow, see
> https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00
>
> Please let us know by Feb 2nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Note: If you already stated your opinion at the IETF meeting in Yokohama
> then you don't need to re-state your opinion, if you want.
>
> The feedback at the Yokohama IETF meeting was the following: 16 persons
> for doing the work / 0 persons against / 2 persons need more info
>
> Ciao
> Hannes & Derek
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


--------------010802050905010207040508
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    +1 for adoption

    

    
On 1/19/16 6:48 AM, Hannes Tschofenig
      wrote:

    

    

      
Hi all,

this is the call for adoption of OAuth 2.0 Device Flow, see
https://tools.ietf.org/html/draft-denniss-oauth-device-flow-00

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

Note: If you already stated your opinion at the IETF meeting in Yokohama
then you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 16 persons
for doing the work / 0 persons against / 2 persons need more info

Ciao
Hannes & Derek



      

      

      

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


    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------010802050905010207040508--


From nobody Thu Jan 21 10:59:03 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE3D1A8A7B for ; Thu, 21 Jan 2016 10:58:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZMafgSNCSoh for ; Thu, 21 Jan 2016 10:58:54 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445FA1A8A87 for ; Thu, 21 Jan 2016 10:58:54 -0800 (PST)
X-AuditID: 1209190d-f79306d000006b70-5e-56a12a6c357c
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 58.16.27504.C6A21A65; Thu, 21 Jan 2016 13:58:52 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u0LIwplJ018321; Thu, 21 Jan 2016 13:58:52 -0500
Received: from [192.168.128.48] (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 u0LIwnLu020232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jan 2016 13:58:51 -0500
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_CDB249BA-C31A-45A9-A9B6-0BCE988BE97C"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5.2
From: Justin Richer 
In-Reply-To: 
Date: Thu, 21 Jan 2016 13:58:49 -0500
Message-Id: 
References:  
To: John Bradley 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMKsWRmVeSWpSXmKPExsUixCmqrJujtTDMYMd3XYu90z6xWJx8+4rN YvXdv2wOzB5Llvxk8mjd8Zfd4/btjSwBzFFcNimpOZllqUX6dglcGe27WxkLfi1irFi//RxL A+PSPsYuRk4OCQETiWM/NkDZYhIX7q1n62Lk4hASWMwk8ezrWmYIZyOjxPNPl6Cc20wSDzbe BWsRFnCQmHrhPhuIzSugJ/Hq1mVWkCJmgSmMEuc6moASHEBzpSRm7BcAqWETUJWYvqaFCcTm FLCTmNPWxApiswDFr0w7A2YzC0RJdO/+yQ4x00piQddcdojFPYwSvy9uBVsmIqAisW/fI6i7 ZSV2/37ENIFRcBaSO2Yhu2MW2OAkiWerzjFB2NoSyxa+ZoawNSX2dy9nwRTXkOj8NpEVwpaX 2P52DlTcUmLxzBtQ9bYSt/oWQM20k3g0bRHrAkbuVYyyKblVurmJmTnFqcm6xcmJeXmpRbpG ermZJXqpKaWbGMHxKcm7g/HdQaVDjAIcjEo8vDeuzQ8TYk0sK67MPcQoycGkJMqrJL4wTIgv KT+lMiOxOCO+qDQntfgQowrQrkcbVl9glGLJy89LVRLhTVECquNNSaysSi3KhymT5mBREufd 1TE3TEggPbEkNTs1tSC1CCYrw8GhJMEboAnUKFiUmp5akZaZU4KQZuLgPMQowcEDNLwIpIa3 uCAxtzgzHSJ/ilFRSpw3DiQhAJLIKM2D6wWl1YS3h01fMYoDvSXMOxmkigeYkuG6XwENZgIa vNdsPsjgkkSElFQDo+CLGMF8Qbcsvzt2Hg5q3xxcyyc8Z21pbFqUartmgqiCvqSmdZXrH/dl S7UkekLkLWs35+tH8O/kc1tzq7maibf58sSvNtFLJgkl3I57x3FvYlnW45LnvxcxBYb8fzbh zMmV/1dejpuWaJrvw/aj73rXAm8ug1cmWi37Yh7t3DWzTCugtkpLiaU4I9FQi7moOBEAhuyM pYYDAAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 18:58:59 -0000

--Apple-Mail=_CDB249BA-C31A-45A9-A9B6-0BCE988BE97C
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CC66639E-4D16-4813-88BD-F557483AB7AA"


--Apple-Mail=_CC66639E-4D16-4813-88BD-F557483AB7AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thank you for removing state hashing and please don=E2=80=99t add it =
back. It=E2=80=99s security theater, and that=E2=80=99s giving it the =
benefit of the doubt. Remember, this is being sent in a  request where =
other parameters (code, client_id, client_secret, redirect_uri) are all =
sent plain over TLS as well. Either come up with a general mechanism to =
hash everything or don=E2=80=99t hash anything. The latter is more =
likely to win, and it=E2=80=99s the only thing that makes sense =
currently.

Also, keep in mind that if the client hashes the state on the second =
request, then the server can=E2=80=99t store the state parameter using =
its own hash methods (for data-at-rest protection) and still be able to =
do the comparison. Having the client send it over plain is really better =
all around in terms of simplicity and adoptability.

Now if we really wanted to have message-level protection of HTTP =
requests, I can think of a good way to do that=E2=80=A6

 =E2=80=94 Justin


> On Jan 21, 2016, at 9:41 AM, John Bradley  wrote:
>=20
> We merged the state verification in with this rather than forcing =
people to also look at the JWT encoded State draft.  =
https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state =
.
>=20
> While JWT encoded state is how I would do state in a client and =
at-least one client I know of uses it, it is not the only way to manage =
state, and I am hesitant that developers might be scared away by =
thinking they need to encode state as a JWT.
>=20
> I decided that cross referencing them is better.   This made sending =
much simpler to describe.
>=20
> I also removed the hashing from state.   That cut the text by about =
2/3 by not having to describe character set normalization so that both =
the client and the AS could calculate the same hash.
> That also achieved the goal of not requiring a simple OAuth client =
doing the code flow to add a crypto library to support SHA256.
>=20
> Once we make a algorithm mandatory, we need to defend why we don=E2=80=99=
t have crypto agility eg support for SHA3 etc.  We would be forced by =
the IESG to add another parameter to the request to specify the hash alg =
if we went that direction.
>=20
> Given that we assume state to be public info in the request that an =
attacker can see, hashing state provides not much value for a lot of =
complexity that people may get wrong or not implement.
>=20
> I appreciate why from a theory point of view hashing it would have =
been better.
>=20
> If people really want it I can add it back.
>=20
> John B.
>=20
>> On Jan 21, 2016, at 3:28 AM, Mike Jones > wrote:
>>=20
>> John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up =
Mitigation draft.  Changes were:
>> =C2=B7       Simplified by no longer specifying the signed JWT method =
for returning the mitigation information.
>> =C2=B7       Simplified by no longer depending upon publication of a =
discovery metadata document.
>> =C2=B7       Added the =E2=80=9Cstate=E2=80=9D token request =
parameter.
>> =C2=B7       Added examples.
>> =C2=B7       Added John Bradley as an editor.
>>=20
>> The specification is available at:
>> =C2=B7       =
http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 =

>>=20
>> An HTML-formatted version is also available at:
>> =C2=B7       =
http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html =
=

>>=20
>>                                                           -- Mike
>>=20
>> P.S.  This note was also posted at http://self-issued.info/?p=3D1526 =
 and as @selfissued =
.
>>=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=_CC66639E-4D16-4813-88BD-F557483AB7AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Thank you for removing state hashing and please don=E2=80=99t =
add it back. It=E2=80=99s security theater, and that=E2=80=99s giving it =
the benefit of the doubt. Remember, this is being sent in a =
 request where other parameters (code, client_id, client_secret, =
redirect_uri) are all sent plain over TLS as well. Either come up with a =
general mechanism to hash everything or don=E2=80=99t hash anything. The =
latter is more likely to win, and it=E2=80=99s the only thing that makes =
sense currently. 

Also, keep in mind that if the client hashes the state on the =
second request, then the server can=E2=80=99t store the state parameter =
using its own hash methods (for data-at-rest protection) and still be =
able to do the comparison. Having the client send it over plain is =
really better all around in terms of simplicity and adoptability.

Now if =
we really wanted to have message-level protection of HTTP requests, I =
can think of a good way to do that=E2=80=A6

 =E2=80=94 Justin


On =
Jan 21, 2016, at 9:41 AM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

We merged the =
state verification in with this rather than forcing people to also look =
at the JWT encoded State draft.  https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-sta=
te.  

While =
JWT encoded state is how I would do state in a client and at-least one =
client I know of uses it, it is not the only way to manage state, and I =
am hesitant that developers might be scared away by thinking they need =
to encode state as a JWT.

I decided that cross referencing them is better.   This =
made sending much simpler to describe.   

I also removed the =
hashing from state.   That cut the text by about 2/3 by not having =
to describe character set normalization so that both the client and the =
AS could calculate the same hash.
That also =
achieved the goal of not requiring a simple OAuth client doing the code =
flow to add a crypto library to support SHA256.

Once we make a algorithm mandatory, we =
need to defend why we don=E2=80=99t have crypto agility eg support for =
SHA3 etc.  We would be forced by the IESG to add another parameter =
to the request to specify the hash alg if we went that =
direction.

Given=
 that we assume state to be public info in the request that an attacker =
can see, hashing state provides not much value for a lot of complexity =
that people may get wrong or not implement.

I appreciate why from a theory point of =
view hashing it would have been better.

If people really want it I can add it =
back.

John =
B.

On Jan 21, 2016, at 3:28 AM, =
Mike Jones <Michael.Jones@microsoft.com> wrote:

John Bradley and I collaborated to =
create the second OAuth 2.0 Mix-Up Mitigation draft.  Changes =
were:
=C2=B7       Simplifi=
ed by no longer specifying the signed JWT method for returning the =
mitigation information.
=C2=B7       Simplifi=
ed by no longer depending upon publication of a discovery metadata =
document.
=C2=B7       Added =
the =E2=80=9Cstate=E2=80=9D token request parameter.
=C2=B7       Added =
examples.
=C2=B7       Added =
John Bradley as an editor.
 
The specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-=
01
 
An HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigatio=
n-01.html
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
 
P.S.  =
This note was also posted at http://self-issued.info/?p=3D1526 and as @selfissued.
 
_______________________________________________
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=_CC66639E-4D16-4813-88BD-F557483AB7AA--

--Apple-Mail=_CDB249BA-C31A-45A9-A9B6-0BCE988BE97C
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJWoSppAAoJEDPAngkbd+w97mUH/169s19lleUnBgwVCHCEb2bl
lk6R7YF8gxrtfSh6Dyqo/WLe1weqmJ7acmQpLaBiUuDr4glKlwu+0pw5y5J223jR
LeCSlkq/pGPLJIqINz8QrYweLhYpAxwYGT5k5n93dtn30tSAX9TaBh/3ajoHrxas
2UQ9He+MMdCRCrSYx7qo0adVkLWySUpCvol5Egt6fPhDV3hnGK2bZedM94bb7NPX
tLP8hh+TtnBEvQWlPhBacVf9nsJEIUlcbZC5V2HemQvu3ohxXY3oTmQ9AOBJm9Zi
av9F1sd4q0Ia2tGEbnzCKFacDvUk0j600+vWDN3HL10/HCJiA/oS7s8WvoaEgG0=
=BXgw
-----END PGP SIGNATURE-----

--Apple-Mail=_CDB249BA-C31A-45A9-A9B6-0BCE988BE97C--


From nobody Thu Jan 21 11:15:46 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764701A8AF1 for ; Thu, 21 Jan 2016 11:15:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyob84GVlnzX for ; Thu, 21 Jan 2016 11:15:41 -0800 (PST)
Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 4468E1A8AD2 for ; Thu, 21 Jan 2016 11:15:41 -0800 (PST)
Received: by mail-qg0-x22e.google.com with SMTP id e32so40128825qgf.3 for ; Thu, 21 Jan 2016 11:15:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=uoH2HTZVwXa3LuhSY1hPm7SLdyb5cTLDezBfTGjq0Ac=; b=no6XcxUMuw0r3IhJm5KMt8DKHdj34nP/DKCIfD8K2GzS9oNlhs1/WDnBRC6x1fIGfF UpPcfb59OMR5xQPO5d1fPrGyqSuW77TQAaINH3qZ8kzPcpWnNwqDVCVomv17RGCb/cFY BNzyehOU903TG6Mpux23qV605t8/xoKyvjsOFBx92duNFncGrxd41zDf1wFQ6o55StQ3 dovbkQtYzWWURBJVf5/J+ZwwOPTNCA4N+ekzhUcjCOTpenED6pNF8dxFGqFNNBpunqaa 86bu5yGgoO8rChof3YTaQSajpiPNM58YVlry3SljMlTkkoaejJpEQuZqLguso8EuinHf ep9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=uoH2HTZVwXa3LuhSY1hPm7SLdyb5cTLDezBfTGjq0Ac=; b=C5l23RpjJ6OATDp2Bfo6u9ckpaNupiEOSE0kdKArdJrnYYSCUGtu7/sFwdTZWEuarl VehG2dzcdkwJ4aeH43JP7BUXjOAUzlXRa+LOq1RQHy7E7UDPDXX3dxn+35B3BIKSjIRB 5uIMIk2rTtMRdzpGO7VXSA8Jt1Q/zhXUFeWyHd/K6Xo8ZLjBFlTVKb4rvIdDrtDgerla Ql8MurE5Ve1G7E/rUtUXYtxqcguoOT+VSwsRVDvSvL3WqoAcC6P4rXOvF/x5jCqkgjWH WkZnPz9SFoao2i5uRTAHZrPLuJ7K9eW/DBKJyX5YOfaQKQzt7Lp2i4cbT9cS14awFRzy lVMw==
X-Gm-Message-State: ALoCoQkAe9/mavADnjOaZadeN/HiFw2Q83lY0+n3YKAAaZ0a9psc8nG9O48fjbGoprPciHA03L/Ks6LrQNPtpQqA8BpZyIUH6Q==
X-Received: by 10.140.94.20 with SMTP id f20mr53724134qge.95.1453403740307; Thu, 21 Jan 2016 11:15:40 -0800 (PST)
Received: from [192.168.8.101] ([181.202.192.227]) by smtp.gmail.com with ESMTPSA id a69sm1153818qgf.21.2016.01.21.11.15.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 11:15:38 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_19A4E949-1FC6-4605-A4BE-6A4E7A745150"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 21 Jan 2016 16:15:34 -0300
Message-Id: <9EC932C9-6B31-4A3E-85C8-46DBFF9E3B9B@ve7jtb.com>
References:   
To: Justin Richer 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 19:15:44 -0000

--Apple-Mail=_19A4E949-1FC6-4605-A4BE-6A4E7A745150
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F6F9DBD2-5490-4A2C-B857-7A61226938AD"


--Apple-Mail=_F6F9DBD2-5490-4A2C-B857-7A61226938AD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The server could hash the state using the same algorithm the client uses =
if the client passed that as well.

I see lots of things being fragile about that.

The draft allows the server to use whatever hash it wants to internally =
to compare them.  Given that we are detecting tamping and don=E2=80=99t =
need to worry about collisions as the state should have it=E2=80=99s own =
integrity protection you could probably get away with MD5 on the server. =
 Though I don=E2=80=99t think saying that in a spec would be a good =
idea:)

I am being sensitive, because I am changing a decision that was agreed =
to by the group in Germany.   I want people to know it was changed, so =
they can provide feedback if they feel strongly.

John B.

> On Jan 21, 2016, at 3:58 PM, Justin Richer  wrote:
>=20
> Thank you for removing state hashing and please don=E2=80=99t add it =
back. It=E2=80=99s security theater, and that=E2=80=99s giving it the =
benefit of the doubt. Remember, this is being sent in a  request where =
other parameters (code, client_id, client_secret, redirect_uri) are all =
sent plain over TLS as well. Either come up with a general mechanism to =
hash everything or don=E2=80=99t hash anything. The latter is more =
likely to win, and it=E2=80=99s the only thing that makes sense =
currently.=20
>=20
> Also, keep in mind that if the client hashes the state on the second =
request, then the server can=E2=80=99t store the state parameter using =
its own hash methods (for data-at-rest protection) and still be able to =
do the comparison. Having the client send it over plain is really better =
all around in terms of simplicity and adoptability.
>=20
> Now if we really wanted to have message-level protection of HTTP =
requests, I can think of a good way to do that=E2=80=A6
>=20
>  =E2=80=94 Justin
>=20
>=20
>> On Jan 21, 2016, at 9:41 AM, John Bradley > wrote:
>>=20
>> We merged the state verification in with this rather than forcing =
people to also look at the JWT encoded State draft.  =
https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state =
. =20
>>=20
>> While JWT encoded state is how I would do state in a client and =
at-least one client I know of uses it, it is not the only way to manage =
state, and I am hesitant that developers might be scared away by =
thinking they need to encode state as a JWT.
>>=20
>> I decided that cross referencing them is better.   This made sending =
much simpler to describe.  =20
>>=20
>> I also removed the hashing from state.   That cut the text by about =
2/3 by not having to describe character set normalization so that both =
the client and the AS could calculate the same hash.
>> That also achieved the goal of not requiring a simple OAuth client =
doing the code flow to add a crypto library to support SHA256.
>>=20
>> Once we make a algorithm mandatory, we need to defend why we don=E2=80=99=
t have crypto agility eg support for SHA3 etc.  We would be forced by =
the IESG to add another parameter to the request to specify the hash alg =
if we went that direction.
>>=20
>> Given that we assume state to be public info in the request that an =
attacker can see, hashing state provides not much value for a lot of =
complexity that people may get wrong or not implement.
>>=20
>> I appreciate why from a theory point of view hashing it would have =
been better.
>>=20
>> If people really want it I can add it back.
>>=20
>> John B.
>>=20
>>> On Jan 21, 2016, at 3:28 AM, Mike Jones > wrote:
>>>=20
>>> John Bradley and I collaborated to create the second OAuth 2.0 =
Mix-Up Mitigation draft.  Changes were:
>>> =C2=B7       Simplified by no longer specifying the signed JWT =
method for returning the mitigation information.
>>> =C2=B7       Simplified by no longer depending upon publication of a =
discovery metadata document.
>>> =C2=B7       Added the =E2=80=9Cstate=E2=80=9D token request =
parameter.
>>> =C2=B7       Added examples.
>>> =C2=B7       Added John Bradley as an editor.
>>> =20
>>> The specification is available at:
>>> =C2=B7       =
http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 =

>>> =20
>>> An HTML-formatted version is also available at:
>>> =C2=B7       =
http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html =
=

>>> =20
>>>                                                           -- Mike
>>> =20
>>> P.S.  This note was also posted at http://self-issued.info/?p=3D1526 =
 and as @selfissued =
.
>>> =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
>=20


--Apple-Mail=_F6F9DBD2-5490-4A2C-B857-7A61226938AD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The server could hash the state using the same algorithm the =
client uses if the client passed that as well.

I see lots of things being fragile =
about that.

The =
draft allows the server to use whatever hash it wants to internally to =
compare them.  Given that we are detecting tamping and don=E2=80=99t =
need to worry about collisions as the state should have it=E2=80=99s own =
integrity protection you could probably get away with MD5 on the server. =
 Though I don=E2=80=99t think saying that in a spec would be a good =
idea:)

I am =
being sensitive, because I am changing a decision that was agreed to by =
the group in Germany.   I want people to know it was changed, so =
they can provide feedback if they feel strongly.

John B.

On =
Jan 21, 2016, at 3:58 PM, Justin Richer <jricher@MIT.EDU> =
wrote:

Thank you for =
removing state hashing and please don=E2=80=99t add it back. It=E2=80=99s =
security theater, and that=E2=80=99s giving it the benefit of the doubt. =
Remember, this is being sent in a  request where other parameters =
(code, client_id, client_secret, redirect_uri) are all sent plain over =
TLS as well. Either come up with a general mechanism to hash everything =
or don=E2=80=99t hash anything. The latter is more likely to win, and =
it=E2=80=99s the only thing that makes sense currently. 

Also, keep in mind that =
if the client hashes the state on the second request, then the server =
can=E2=80=99t store the state parameter using its own hash methods (for =
data-at-rest protection) and still be able to do the comparison. Having =
the client send it over plain is really better all around in terms of =
simplicity and adoptability.

Now if we really wanted to have =
message-level protection of HTTP requests, I can think of a good way to =
do that=E2=80=A6

 =E2=80=94 Justin


On Jan =
21, 2016, at 9:41 AM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

We merged the =
state verification in with this rather than forcing people to also look =
at the JWT encoded State draft.  https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-sta=
te.  

While =
JWT encoded state is how I would do state in a client and at-least one =
client I know of uses it, it is not the only way to manage state, and I =
am hesitant that developers might be scared away by thinking they need =
to encode state as a JWT.

I decided that cross referencing them is better.   This =
made sending much simpler to describe.   

I also removed the =
hashing from state.   That cut the text by about 2/3 by not having =
to describe character set normalization so that both the client and the =
AS could calculate the same hash.
That also =
achieved the goal of not requiring a simple OAuth client doing the code =
flow to add a crypto library to support SHA256.

Once we make a algorithm mandatory, we =
need to defend why we don=E2=80=99t have crypto agility eg support for =
SHA3 etc.  We would be forced by the IESG to add another parameter =
to the request to specify the hash alg if we went that =
direction.

Given=
 that we assume state to be public info in the request that an attacker =
can see, hashing state provides not much value for a lot of complexity =
that people may get wrong or not implement.

I appreciate why from a theory point of =
view hashing it would have been better.

If people really want it I can add it =
back.

John =
B.

On Jan 21, 2016, at 3:28 AM, =
Mike Jones <Michael.Jones@microsoft.com> wrote:

John Bradley and I collaborated to =
create the second OAuth 2.0 Mix-Up Mitigation draft.  Changes =
were:
=C2=B7       Simplifi=
ed by no longer specifying the signed JWT method for returning the =
mitigation information.
=C2=B7       Simplifi=
ed by no longer depending upon publication of a discovery metadata =
document.
=C2=B7       Added =
the =E2=80=9Cstate=E2=80=9D token request parameter.
=C2=B7       Added =
examples.
=C2=B7       Added =
John Bradley as an editor.
 
The specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-=
01
 
An HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigatio=
n-01.html
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
 
P.S.  =
This note was also posted at http://self-issued.info/?p=3D1526 and as @selfissued.
 
_______________________________________________
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=_F6F9DBD2-5490-4A2C-B857-7A61226938AD--

--Apple-Mail=_19A4E949-1FC6-4605-A4BE-6A4E7A745150
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjExOTE1MzVaMCMGCSqGSIb3DQEJBDEWBBQ+l6F/z9kc47JkPO9htAJb
ylkjejCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCZvZtjCJfci1DcnOMzJVnV6Fn66mCx2FipHHiBOGY2cdLpUjuXWcJr
t/hsiB6bN70fXGHITljC0lZdsf1R+QlnHPqxiRWNyYIZHQZ4VDs8gitS2dOLQFmkVQh1Ltaxr27p
fJrMrgVornWTy4TnCQhfTycCUqd7FUExjkP+ckWEzWDXNpFzUR7LN4dur+ahVLUluDDje9i7r9ql
yDQdGw4u6LgfDQ1AepQ4CwJ9ECJkeY4c0HkN7V7zPspCa2B6xeoUnYDYXn/K5hJrBymrWRl+8o2F
ZaVkK1fnzLcA8vvfvcxqLIuCSpq/VK++47ksgmgnJXkgomzXA1SPW874PH0LAAAAAAAA
--Apple-Mail=_19A4E949-1FC6-4605-A4BE-6A4E7A745150--


From nobody Thu Jan 21 11:19:02 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C181A8AF4 for ; Thu, 21 Jan 2016 11:18:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD4dqKJrB6OZ for ; Thu, 21 Jan 2016 11:18:56 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5831A8AF6 for ; Thu, 21 Jan 2016 11:18:52 -0800 (PST)
X-AuditID: 12074424-f79216d00000156e-95-56a12f1a840e
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id D1.32.05486.B1F21A65; Thu, 21 Jan 2016 14:18:51 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u0LJIocB016225; Thu, 21 Jan 2016 14:18:50 -0500
Received: from [192.168.128.48] (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 u0LJImIn027711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jan 2016 14:18:49 -0500
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Content-Type: multipart/signed; boundary="Apple-Mail=_60419531-FA28-415C-8D31-3FDFE7B70EF4"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.5.2
From: Justin Richer 
In-Reply-To: <9EC932C9-6B31-4A3E-85C8-46DBFF9E3B9B@ve7jtb.com>
Date: Thu, 21 Jan 2016 14:18:47 -0500
Message-Id: <27A7E81B-0E45-4D81-9F02-107E740E82AF@mit.edu>
References:    <9EC932C9-6B31-4A3E-85C8-46DBFF9E3B9B@ve7jtb.com>
To: John Bradley 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHKsWRmVeSWpSXmKPExsUixG6nriutvzDMYP9Jdou90z6xWJx8+4rN YvXdv2wOzB5Llvxk8mjd8Zfd4/btjSwBzFFcNimpOZllqUX6dglcGfeO/2Ep2H2QseLojtQG xk0rGLsYOTkkBEwkbpw+wgRhi0lcuLeeDcQWEljMJHHuaG4XIxeQvZFR4sH5e4wQzm0miQen prKAVAkLOEhMvXAfrINXQE/i1a3LrCA2s8AURond88W7GDmApkpJzNgvABJmE1CVmL6mBWwZ p4CdxPoFe8FsFqD4xYWn2SBaoyS6d/9khxhpJbFg0SJmiIPeMkps6LMBsUUEVCT27XsE9YCs xO7fj5gmMArOQnLFLCRXQNhJEv/vb2SGsLUlli18DWVrSuzvXs6CKa4h0fltItQceYntb+dA xS0lFs+8AVVvK3GrbwEThG0n8WjaItYFjNyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdM31cjNL 9FJTSjcxgqPSRWUHY/MhpUOMAhyMSjy8HLoLw4RYE8uKK3MPMUpyMCmJ8n7VAQrxJeWnVGYk FmfEF5XmpBYfYlQB2vVow+oLjFIsefl5qUoivClKQHW8KYmVValF+TBl0hwsSuK8uzrmhgkJ pCeWpGanphakFsFkZTg4lCR4i/SAGgWLUtNTK9Iyc0oQ0kwcnIcYJTh4gIavArmLt7ggMbc4 Mx0if4pRUUqcdy5IQgAkkVGaB9cLSqYJbw+bvmIUB3pLmPciSBUPMBHDdb8CGswENHiv2XyQ wSWJCCmpBka9haZHih/pzu2LeePIc93QiPHlM68Ep3PPL6RtVSkrVPdiPfHzoeOxlc0lvCee FUWzG/xjMd7wwlJlgpswc59MYbrjrb3/azcKT+9x1X6/x1V6mhGrVMvDjlkejy26V15dEjZx drlpRNqun01X7sTVa7Yz9lg8kXN5q/Fw3yy7tw29ooJ5RkosxRmJhlrMRcWJAL6jK8SBAwAA
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 19:18:59 -0000

--Apple-Mail=_60419531-FA28-415C-8D31-3FDFE7B70EF4
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_DE21A037-CA6F-4BA9-9619-CC822D77FA56"


--Apple-Mail=_DE21A037-CA6F-4BA9-9619-CC822D77FA56
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Just because there=E2=80=99s a potential workaround doesn=E2=80=99t mean =
this is a good idea, especially when you can easily avoid the need for =
workarounds in the first place. :)

 =E2=80=94 Justin

> On Jan 21, 2016, at 2:15 PM, John Bradley  wrote:
>=20
> The server could hash the state using the same algorithm the client =
uses if the client passed that as well.
>=20
> I see lots of things being fragile about that.
>=20
> The draft allows the server to use whatever hash it wants to =
internally to compare them.  Given that we are detecting tamping and =
don=E2=80=99t need to worry about collisions as the state should have =
it=E2=80=99s own integrity protection you could probably get away with =
MD5 on the server.  Though I don=E2=80=99t think saying that in a spec =
would be a good idea:)
>=20
> I am being sensitive, because I am changing a decision that was agreed =
to by the group in Germany.   I want people to know it was changed, so =
they can provide feedback if they feel strongly.
>=20
> John B.
>=20
>> On Jan 21, 2016, at 3:58 PM, Justin Richer > wrote:
>>=20
>> Thank you for removing state hashing and please don=E2=80=99t add it =
back. It=E2=80=99s security theater, and that=E2=80=99s giving it the =
benefit of the doubt. Remember, this is being sent in a  request where =
other parameters (code, client_id, client_secret, redirect_uri) are all =
sent plain over TLS as well. Either come up with a general mechanism to =
hash everything or don=E2=80=99t hash anything. The latter is more =
likely to win, and it=E2=80=99s the only thing that makes sense =
currently.
>>=20
>> Also, keep in mind that if the client hashes the state on the second =
request, then the server can=E2=80=99t store the state parameter using =
its own hash methods (for data-at-rest protection) and still be able to =
do the comparison. Having the client send it over plain is really better =
all around in terms of simplicity and adoptability.
>>=20
>> Now if we really wanted to have message-level protection of HTTP =
requests, I can think of a good way to do that=E2=80=A6
>>=20
>>  =E2=80=94 Justin
>>=20
>>=20
>>> On Jan 21, 2016, at 9:41 AM, John Bradley > wrote:
>>>=20
>>> We merged the state verification in with this rather than forcing =
people to also look at the JWT encoded State draft.  =
https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state =
.
>>>=20
>>> While JWT encoded state is how I would do state in a client and =
at-least one client I know of uses it, it is not the only way to manage =
state, and I am hesitant that developers might be scared away by =
thinking they need to encode state as a JWT.
>>>=20
>>> I decided that cross referencing them is better.   This made sending =
much simpler to describe.
>>>=20
>>> I also removed the hashing from state.   That cut the text by about =
2/3 by not having to describe character set normalization so that both =
the client and the AS could calculate the same hash.
>>> That also achieved the goal of not requiring a simple OAuth client =
doing the code flow to add a crypto library to support SHA256.
>>>=20
>>> Once we make a algorithm mandatory, we need to defend why we don=E2=80=
=99t have crypto agility eg support for SHA3 etc.  We would be forced by =
the IESG to add another parameter to the request to specify the hash alg =
if we went that direction.
>>>=20
>>> Given that we assume state to be public info in the request that an =
attacker can see, hashing state provides not much value for a lot of =
complexity that people may get wrong or not implement.
>>>=20
>>> I appreciate why from a theory point of view hashing it would have =
been better.
>>>=20
>>> If people really want it I can add it back.
>>>=20
>>> John B.
>>>=20
>>>> On Jan 21, 2016, at 3:28 AM, Mike Jones =
> =
wrote:
>>>>=20
>>>> John Bradley and I collaborated to create the second OAuth 2.0 =
Mix-Up Mitigation draft.  Changes were:
>>>> =C2=B7       Simplified by no longer specifying the signed JWT =
method for returning the mitigation information.
>>>> =C2=B7       Simplified by no longer depending upon publication of =
a discovery metadata document.
>>>> =C2=B7       Added the =E2=80=9Cstate=E2=80=9D token request =
parameter.
>>>> =C2=B7       Added examples.
>>>> =C2=B7       Added John Bradley as an editor.
>>>>=20
>>>> The specification is available at:
>>>> =C2=B7       =
http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 =

>>>>=20
>>>> An HTML-formatted version is also available at:
>>>> =C2=B7       =
http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html =
=

>>>>=20
>>>>                                                           -- Mike
>>>>=20
>>>> P.S.  This note was also posted at http://self-issued.info/?p=3D1526 =
 and as @selfissued =
.
>>>>=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 =

>>=20
>=20


--Apple-Mail=_DE21A037-CA6F-4BA9-9619-CC822D77FA56
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Just because there=E2=80=99s a potential workaround doesn=E2=80=
=99t mean this is a good idea, especially when you can easily avoid the =
need for workarounds in the first place. :)

 =E2=80=94 Justin

On Jan 21, 2016, at 2:15 PM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

The server =
could hash the state using the same algorithm the client uses if the =
client passed that as well.

I see lots of things being fragile about that.

The draft allows the =
server to use whatever hash it wants to internally to compare them. =
 Given that we are detecting tamping and don=E2=80=99t need to =
worry about collisions as the state should have it=E2=80=99s own =
integrity protection you could probably get away with MD5 on the server. =
 Though I don=E2=80=99t think saying that in a spec would be a good =
idea:)

I am =
being sensitive, because I am changing a decision that was agreed to by =
the group in Germany.   I want people to know it was changed, so =
they can provide feedback if they feel strongly.

John B.

On Jan 21, 2016, at 3:58 PM, Justin Richer <jricher@MIT.EDU> =
wrote:

Thank you for =
removing state hashing and please don=E2=80=99t add it back. It=E2=80=99s =
security theater, and that=E2=80=99s giving it the benefit of the doubt. =
Remember, this is being sent in a  request where other parameters =
(code, client_id, client_secret, redirect_uri) are all sent plain over =
TLS as well. Either come up with a general mechanism to hash everything =
or don=E2=80=99t hash anything. The latter is more likely to win, and =
it=E2=80=99s the only thing that makes sense currently. 

Also, keep in mind that =
if the client hashes the state on the second request, then the server =
can=E2=80=99t store the state parameter using its own hash methods (for =
data-at-rest protection) and still be able to do the comparison. Having =
the client send it over plain is really better all around in terms of =
simplicity and adoptability.

Now if we really wanted to have =
message-level protection of HTTP requests, I can think of a good way to =
do that=E2=80=A6

 =E2=80=94 Justin


On Jan =
21, 2016, at 9:41 AM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

We merged the =
state verification in with this rather than forcing people to also look =
at the JWT encoded State draft.  https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-sta=
te.  

While =
JWT encoded state is how I would do state in a client and at-least one =
client I know of uses it, it is not the only way to manage state, and I =
am hesitant that developers might be scared away by thinking they need =
to encode state as a JWT.

I decided that cross referencing them is better.   This =
made sending much simpler to describe.   

I also removed the =
hashing from state.   That cut the text by about 2/3 by not having =
to describe character set normalization so that both the client and the =
AS could calculate the same hash.
That also =
achieved the goal of not requiring a simple OAuth client doing the code =
flow to add a crypto library to support SHA256.

Once we make a algorithm mandatory, we =
need to defend why we don=E2=80=99t have crypto agility eg support for =
SHA3 etc.  We would be forced by the IESG to add another parameter =
to the request to specify the hash alg if we went that =
direction.

Given=
 that we assume state to be public info in the request that an attacker =
can see, hashing state provides not much value for a lot of complexity =
that people may get wrong or not implement.

I appreciate why from a theory point of =
view hashing it would have been better.

If people really want it I can add it =
back.

John =
B.

On Jan 21, 2016, at 3:28 AM, =
Mike Jones <Michael.Jones@microsoft.com> wrote:

John Bradley and I collaborated to =
create the second OAuth 2.0 Mix-Up Mitigation draft.  Changes =
were:
=C2=B7       Simplifi=
ed by no longer specifying the signed JWT method for returning the =
mitigation information.
=C2=B7       Simplifi=
ed by no longer depending upon publication of a discovery metadata =
document.
=C2=B7       Added =
the =E2=80=9Cstate=E2=80=9D token request parameter.
=C2=B7       Added =
examples.
=C2=B7       Added =
John Bradley as an editor.
 
The specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-=
01
 
An HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigatio=
n-01.html
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
 
P.S.  =
This note was also posted at http://self-issued.info/?p=3D1526 and as @selfissued.
 
_______________________________________________
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=_DE21A037-CA6F-4BA9-9619-CC822D77FA56--

--Apple-Mail=_60419531-FA28-415C-8D31-3FDFE7B70EF4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJWoS8YAAoJEDPAngkbd+w98aIH/0ct8dotAsAvHt55zHAwJnXR
suxAUVrObrS7GntaCCEJtZ+w6SclwxMKxWvMDBaxutjbo74syX+Tmy+JZlyGw/E5
GPpS8uKqRDTWTXTZ2C717KMI2PNCb4UavQamqdI7vJYqLLLQnW6XueFK6q9QOsdO
f5by92q0jsiYDti+fHkOwmbTUoZVCIYN0PGtkURWdCitac+3LIa5MB2lfaAFMdno
IuiCkumf2JT+VnCoCFap8eB2Qf39kRmTsEqsibrjwuqcRq/I2IvMu7C97OdZVEtT
exiC9UJHjTJqZx3BRfEKC4eaxcAED99nj50GaixsM/azZ9aszBc3/xU1unyqFbU=
=MAH8
-----END PGP SIGNATURE-----

--Apple-Mail=_60419531-FA28-415C-8D31-3FDFE7B70EF4--


From nobody Thu Jan 21 11:25:03 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D7B1A8AFB for ; Thu, 21 Jan 2016 11:25:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94tKMzLGAJiv for ; Thu, 21 Jan 2016 11:24:59 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7441A8AF9 for ; Thu, 21 Jan 2016 11:24:59 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id l65so233327253wmf.1 for ; Thu, 21 Jan 2016 11:24:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=4ntgol5iiSJ5eeyUGZ8jKmk+flBNc94C/IyP4AnuCfU=; b=MsnyOOFUhj250YlxTqpHlShCCKagP05XPzO4wF+JrViUaWnib8MGRAUxR0UYIhhS5x 6/lOEHepbh22eOrfgXdGmr2ayCH/0ApBXqrFNHqonJ9iaEbI/1fm0bEMMC4ZrrGnkbX5 /q9MPrx+5Gj71NqahyJrpwsz7T/1Blt/+d4rs=
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-type :content-transfer-encoding; bh=4ntgol5iiSJ5eeyUGZ8jKmk+flBNc94C/IyP4AnuCfU=; b=hWRfjyd3w8TuUP5/OSWeAKiV86Humn1EjneIrdW1qdFl1utE4CFFzQFAppqWRnnm2V I4Pubw2AGQ68tP7F8LiLeT/nKWW+UHwUjaCvhe3jKSK4RT1tVVgy2wTlBtMg5pQFSK9w AD3aULTI/xQA0vVh0dSWftvRvRcBFCga0UESxskyU9zSQdON2qzyE1o2hJ/lfumxHb43 iboMw5rUXqegfWNIkbR+eMcsNwBaD6T9ClX6VA3DWqVYSRrSATyM9KJIx7eZ2pRmQOOo dDy/M5nPDrESAjv5M0G8MsleT4p964x3pV3C1bHyQtMCvBF7TGNyr+6X15AMeFbNNaiX gREA==
X-Gm-Message-State: AG10YOTGZ77JTmPUnZhNMKvkSxToxEX8VoTT0EklgWXckm5ijJDCpCI9HGUWFZqi5IiOCMJ9
X-Received: by 10.28.225.8 with SMTP id y8mr12524486wmg.98.1453404297879; Thu, 21 Jan 2016 11:24:57 -0800 (PST)
Received: from [192.168.10.222] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by smtp.gmail.com with ESMTPSA id w73sm4192461wmw.21.2016.01.21.11.24.56 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 11:24:57 -0800 (PST)
To: Justin Richer , John Bradley 
References:   
From: Hans Zandbelt 
Message-ID: <56A13088.2000508@pingidentity.com>
Date: Thu, 21 Jan 2016 20:24:56 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 19:25:01 -0000

Note that the argument was not about message-level protection: it was 
about not disclosing the state value verbatim over the token endpoint.

I don't feel strongly about it either; it was just what was agreed at 
first. Since no-one actually came up with even a hypothetical attack I 
guess it makes sense to revert that decision.

Hans.

On 1/21/16 7:58 PM, Justin Richer wrote:
> Thank you for removing state hashing and please don’t add it back. It’s
> security theater, and that’s giving it the benefit of the doubt.
> Remember, this is being sent in a  request where other parameters (code,
> client_id, client_secret, redirect_uri) are all sent plain over TLS as
> well. Either come up with a general mechanism to hash everything or
> don’t hash anything. The latter is more likely to win, and it’s the only
> thing that makes sense currently.
>
> Also, keep in mind that if the client hashes the state on the second
> request, then the server can’t store the state parameter using its own
> hash methods (for data-at-rest protection) and still be able to do the
> comparison. Having the client send it over plain is really better all
> around in terms of simplicity and adoptability.
>
> Now if we really wanted to have message-level protection of HTTP
> requests, I can think of a good way to do that…
>
>   — Justin
>
>
>> On Jan 21, 2016, at 9:41 AM, John Bradley > > wrote:
>>
>> We merged the state verification in with this rather than forcing
>> people to also look at the JWT encoded State draft.
>> https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state.
>>
>> While JWT encoded state is how I would do state in a client and
>> at-least one client I know of uses it, it is not the only way to
>> manage state, and I am hesitant that developers might be scared away
>> by thinking they need to encode state as a JWT.
>>
>> I decided that cross referencing them is better.   This made sending
>> much simpler to describe.
>>
>> I also removed the hashing from state.   That cut the text by about
>> 2/3 by not having to describe character set normalization so that both
>> the client and the AS could calculate the same hash.
>> That also achieved the goal of not requiring a simple OAuth client
>> doing the code flow to add a crypto library to support SHA256.
>>
>> Once we make a algorithm mandatory, we need to defend why we don’t
>> have crypto agility eg support for SHA3 etc.  We would be forced by
>> the IESG to add another parameter to the request to specify the hash
>> alg if we went that direction.
>>
>> Given that we assume state to be public info in the request that an
>> attacker can see, hashing state provides not much value for a lot of
>> complexity that people may get wrong or not implement.
>>
>> I appreciate why from a theory point of view hashing it would have
>> been better.
>>
>> If people really want it I can add it back.
>>
>> John B.
>>
>>> On Jan 21, 2016, at 3:28 AM, Mike Jones >> > wrote:
>>>
>>> John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up
>>> Mitigation draft.  Changes were:
>>> ·Simplified by no longer specifying the signed JWT method for
>>> returning the mitigation information.
>>> ·Simplified by no longer depending upon publication of a discovery
>>> metadata document.
>>> ·Added the “state” token request parameter.
>>> ·Added examples.
>>> ·Added John Bradley as an editor.
>>> The specification is available at:
>>> ·http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01
>>> An HTML-formatted version is also available at:
>>> ·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html
>>>                                                           -- Mike
>>> P.S.  This note was also posted
>>> athttp://self-issued.info/?p=1526andas@selfissued
>>> .
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


From nobody Thu Jan 21 11:42:11 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7023B1A8FD2 for ; Thu, 21 Jan 2016 11:42:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVfFfHmIZMGv for ; Thu, 21 Jan 2016 11:42:07 -0800 (PST)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251ED1A8F51 for ; Thu, 21 Jan 2016 11:42:05 -0800 (PST)
X-AuditID: 1209190c-f79c96d00000038e-58-56a1348c6b43
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 2A.D1.00910.C8431A65; Thu, 21 Jan 2016 14:42:04 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u0LJg319022457; Thu, 21 Jan 2016 14:42:03 -0500
Received: from [192.168.128.48] (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 u0LJg1OJ003973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 21 Jan 2016 14:42:02 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_3A9D313F-46BC-4946-AC8B-2CA2D3645500"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: <56A13088.2000508@pingidentity.com>
Date: Thu, 21 Jan 2016 14:42:01 -0500
Message-Id: 
References:    <56A13088.2000508@pingidentity.com>
To: Hans Zandbelt 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUixCmqrdtjsjDMYOtfMYutf/cyW5x8+4rN YvXdv2wOzB5Llvxk8rh79CKLx+3bG1kCmKO4bFJSczLLUov07RK4Mj5vKi7YXVDxr2EaUwPj pIQuRk4OCQETiRnPnjJC2GISF+6tZ+ti5OIQEljMJNH/4DkzhLORUWLOhwaozG0miXt/X7OB tDALJEi0fLwDZvMK6Em8unWZFcQWFnCQmHrhPlicTUBVYvqaFiYQm1PAQGLOumPMIDYLUHzO lS0sEHM8JfY8u8AIMcdK4sGjSywQy+4zSlx41QBWJAK0YO+lhUwQt8pK7P79iGkCo8AsJHfM QnIHRFxbYtnC18wQtoHE085XWMT1Jd68m8O0gJFtFaNsSm6Vbm5iZk5xarJucXJiXl5qka6h Xm5miV5qSukmRnAcSPLsYHxzUOkQowAHoxIPL4fuwjAh1sSy4srcQ4ySHExKorxfdYBCfEn5 KZUZicUZ8UWlOanFhxglOJiVRHhTlIByvCmJlVWpRfkwKWkOFiVx3l0dc8OEBNITS1KzU1ML UotgsjIcHEoSvI+MgRoFi1LTUyvSMnNKENJMHJwgw3mAhp8CqeEtLkjMLc5Mh8ifYlSUEud1 AkkIgCQySvPgekFpKuHtYdNXjOJArwjzloJU8QBTHFz3K6DBTECD95rNBxlckoiQkmpgLGIv sd2VJbYs8q00p6m26ZLvK1///HhDeVK20N0IuSmOfxtkqjTrmhaXO794PnvaYuOTlzz8ZVN2 X+Nee2Ozq75Z65laifhGBpbFWdteGy3wjZUJK/ikVzVpd9pjtbfHjYwYhO7rxiS0in0xcbcQ 4AvQ3MiY+0rsn0vOadZT7UqT0mqC36cqsRRnJBpqMRcVJwIAEeivZi4DAAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 19:42:10 -0000

--Apple-Mail=_3A9D313F-46BC-4946-AC8B-2CA2D3645500
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hans,

Thanks; while I see the argument, my counter argument was to ask for a =
situation where you=92d want to protect the state value but not code, =
client_secret, redirect_uri, and everything else in the request. If you =
actually want to protect all of that, it=92s better to have a =
message-level protection mechanism instead of a piecemeal solution.

 =97 Justin

> On Jan 21, 2016, at 2:24 PM, Hans Zandbelt =
 wrote:
>=20
> Note that the argument was not about message-level protection: it was =
about not disclosing the state value verbatim over the token endpoint.
>=20
> I don't feel strongly about it either; it was just what was agreed at =
first. Since no-one actually came up with even a hypothetical attack I =
guess it makes sense to revert that decision.
>=20
> Hans.
>=20
> On 1/21/16 7:58 PM, Justin Richer wrote:
>> Thank you for removing state hashing and please don=92t add it back. =
It=92s
>> security theater, and that=92s giving it the benefit of the doubt.
>> Remember, this is being sent in a  request where other parameters =
(code,
>> client_id, client_secret, redirect_uri) are all sent plain over TLS =
as
>> well. Either come up with a general mechanism to hash everything or
>> don=92t hash anything. The latter is more likely to win, and it=92s =
the only
>> thing that makes sense currently.
>>=20
>> Also, keep in mind that if the client hashes the state on the second
>> request, then the server can=92t store the state parameter using its =
own
>> hash methods (for data-at-rest protection) and still be able to do =
the
>> comparison. Having the client send it over plain is really better all
>> around in terms of simplicity and adoptability.
>>=20
>> Now if we really wanted to have message-level protection of HTTP
>> requests, I can think of a good way to do that=85
>>=20
>>  =97 Justin
>>=20
>>=20
>>> On Jan 21, 2016, at 9:41 AM, John Bradley >> > wrote:
>>>=20
>>> We merged the state verification in with this rather than forcing
>>> people to also look at the JWT encoded State draft.
>>> https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state.
>>>=20
>>> While JWT encoded state is how I would do state in a client and
>>> at-least one client I know of uses it, it is not the only way to
>>> manage state, and I am hesitant that developers might be scared away
>>> by thinking they need to encode state as a JWT.
>>>=20
>>> I decided that cross referencing them is better.   This made sending
>>> much simpler to describe.
>>>=20
>>> I also removed the hashing from state.   That cut the text by about
>>> 2/3 by not having to describe character set normalization so that =
both
>>> the client and the AS could calculate the same hash.
>>> That also achieved the goal of not requiring a simple OAuth client
>>> doing the code flow to add a crypto library to support SHA256.
>>>=20
>>> Once we make a algorithm mandatory, we need to defend why we don=92t
>>> have crypto agility eg support for SHA3 etc.  We would be forced by
>>> the IESG to add another parameter to the request to specify the hash
>>> alg if we went that direction.
>>>=20
>>> Given that we assume state to be public info in the request that an
>>> attacker can see, hashing state provides not much value for a lot of
>>> complexity that people may get wrong or not implement.
>>>=20
>>> I appreciate why from a theory point of view hashing it would have
>>> been better.
>>>=20
>>> If people really want it I can add it back.
>>>=20
>>> John B.
>>>=20
>>>> On Jan 21, 2016, at 3:28 AM, Mike Jones =
>>> > wrote:
>>>>=20
>>>> John Bradley and I collaborated to create the second OAuth 2.0 =
Mix-Up
>>>> Mitigation draft.  Changes were:
>>>> =B7Simplified by no longer specifying the signed JWT method for
>>>> returning the mitigation information.
>>>> =B7Simplified by no longer depending upon publication of a =
discovery
>>>> metadata document.
>>>> =B7Added the =93state=94 token request parameter.
>>>> =B7Added examples.
>>>> =B7Added John Bradley as an editor.
>>>> The specification is available at:
>>>> =B7http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01
>>>> An HTML-formatted version is also available at:
>>>> =
=B7http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.htm=
l
>>>>                                                          -- Mike
>>>> P.S.  This note was also posted
>>>> athttp://self-issued.info/?p=3D1526andas@selfissued
>>>> .
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>=20
> --=20
> Hans Zandbelt              | Sr. Technical Architect
> hzandbelt@pingidentity.com | Ping Identity


--Apple-Mail=_3A9D313F-46BC-4946-AC8B-2CA2D3645500
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Hans,

Thanks; while I see the argument, my counter argument was to =
ask for a situation where you=92d want to protect the state value but not code, =
client_secret, redirect_uri, and everything else in the request. If you =
actually want to protect all of that, it=92s better to have a =
message-level protection mechanism instead of a piecemeal =
solution.

 =97 Justin

On =
Jan 21, 2016, at 2:24 PM, Hans Zandbelt <hzandbelt@pingidentity.com> wrote:

Note that the =
argument was not about message-level protection: it was about not =
disclosing the state value verbatim over the token endpoint.

I don't feel strongly about it either; it was =
just what was agreed at first. Since no-one actually came up with even a =
hypothetical attack I guess it makes sense to revert that decision.

Hans.

On 1/21/16 =
7:58 PM, Justin Richer wrote:
Thank you for removing state hashing and please don=92t add =
it back. It=92s
security theater, and that=92s giving it =
the benefit of the doubt.
Remember, this is being sent in =
a  request where other parameters (code,
client_id, =
client_secret, redirect_uri) are all sent plain over TLS as
well. Either come up with a general mechanism to hash =
everything or
don=92t hash anything. The latter is more =
likely to win, and it=92s the only
thing that makes sense =
currently.

Also, keep in mind that if the =
client hashes the state on the second
request, then the =
server can=92t store the state parameter using its own
hash =
methods (for data-at-rest protection) and still be able to do the
comparison. Having the client send it over plain is really =
better all
around in terms of simplicity and =
adoptability.

Now if we really wanted to =
have message-level protection of HTTP
requests, I can =
think of a good way to do that=85

  =97 =
Justin


On Jan 21, 2016, at 9:41 AM, John Bradley =
<ve7jtb@ve7jtb.com
<mailto:ve7jtb@ve7jtb.com>> wrote:

We merged the state verification in with this rather than =
forcing
people to also look at the JWT encoded State =
draft.
https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-sta=
te.

While JWT encoded state is how I =
would do state in a client and
at-least one client I know =
of uses it, it is not the only way to
manage state, and I =
am hesitant that developers might be scared away
by =
thinking they need to encode state as a JWT.

I decided that cross referencing them is better. =
  This made sending
much simpler to describe.

I also removed the hashing from state. =
  That cut the text by about
2/3 by not having =
to describe character set normalization so that both
the =
client and the AS could calculate the same hash.
That also =
achieved the goal of not requiring a simple OAuth client
doing the code flow to add a crypto library to support =
SHA256.

Once we make a algorithm mandatory, =
we need to defend why we don=92t
have crypto agility eg =
support for SHA3 etc.  We would be forced by
the IESG =
to add another parameter to the request to specify the hash
alg if we went that direction.

Given that we assume state to be public info in the request =
that an
attacker can see, hashing state provides not much =
value for a lot of
complexity that people may get wrong or =
not implement.

I appreciate why from a =
theory point of view hashing it would have
been better.

If people really want it I can add it back.

John B.

On Jan 21, 2016, at 3:28 AM, Mike Jones <Michael.Jones@microsoft.com
<mailto:Michael.Jones@microsoft.com>> wrote:

John Bradley and I collaborated to create the =
second OAuth 2.0 Mix-Up
Mitigation draft.  Changes =
were:
=B7Simplified by no longer specifying the signed JWT =
method for
returning the mitigation information.
=B7Simplified by no longer depending upon publication of a =
discovery
metadata document.
=B7Added the =
=93state=94 token request parameter.
=B7Added examples.
=B7Added John Bradley as an editor.
The =
specification is available at:
=B7http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-=
01
An HTML-formatted version is also available at:
=B7http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigatio=
n-01.html
 =
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;       -- Mike
P.S. =
 This note was also posted
athttp://self-issued.info/?p=3D1526andas@selfissued
<https://twitter.com/selfissued>.
_______________________________________________
OAuth mailing list
OAuth@ietf.org =
<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

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



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


-- 
Hans Zandbelt =
            &n=
bsp;| Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity

=

--Apple-Mail=_3A9D313F-46BC-4946-AC8B-2CA2D3645500--


From nobody Thu Jan 21 11:48:53 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B57A01A9025 for ; Thu, 21 Jan 2016 11:48:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_FAIL=0.001, SPF_HELO_FAIL=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_SBlP95zEfd for ; Thu, 21 Jan 2016 11:48:50 -0800 (PST)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5DB1A9023 for ; Thu, 21 Jan 2016 11:48:50 -0800 (PST)
Received: from home.alkaline-solutions.com (c-50-155-144-64.hsd1.co.comcast.net [50.155.144.64]) by alkaline-solutions.com (Postfix) with ESMTPSA id 77C2D315B1; Thu, 21 Jan 2016 19:48:48 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5DD52378-F312-40AF-A9A2-36389B35960D"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: David Waite 
In-Reply-To: 
Date: Thu, 21 Jan 2016 12:48:47 -0700
Message-Id: <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com>
References: 
To: Mike Jones 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 19:48:51 -0000

--Apple-Mail=_5DD52378-F312-40AF-A9A2-36389B35960D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Question:=20

I understand how =E2=80=9Ciss" helps mitigate this attack (client knows =
response was from the appropriate issuer and not an attack where the =
request was answered by another issuer).=20

However, how does passing =E2=80=9Cstate=E2=80=9D on the =
authorization_code grant token request help once you have the above in =
place? Is this against some alternate flow of this attack I don=E2=80=99t =
see, or is it meant to mitigate some entirely separate attack?

If one is attempting to work statelessly (e.g. your =E2=80=9Cstate=E2=80=9D=
 parameter is actual state and not just a randomly generated value), a =
client would have always needed some way to differentiate which issuer =
the authorization_code grant token request would be sent to.

However, if an AS was treating =E2=80=9Ccode=E2=80=9D as a token (for =
instance, encoding: client, user, consent time and approved scopes), the =
AS now has to include the client=E2=80=99s state as well. This would =
effectively double (likely more with encoding) the state sent in the =
authorization response back to the client redirect URL, adding more =
pressure against maximum URL sizes.

-DW

> On Jan 20, 2016, at 11:28 PM, Mike Jones  =
wrote:
>=20
> John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up =
Mitigation draft.  Changes were:
> =C2=B7       Simplified by no longer specifying the signed JWT method =
for returning the mitigation information.
> =C2=B7       Simplified by no longer depending upon publication of a =
discovery metadata document.
> =C2=B7       Added the =E2=80=9Cstate=E2=80=9D token request =
parameter.
> =C2=B7       Added examples.
> =C2=B7       Added John Bradley as an editor.
> =20
> The specification is available at:
> =C2=B7       =
http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 =

> =20
> An HTML-formatted version is also available at:
> =C2=B7       =
http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html =
=

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


--Apple-Mail=_5DD52378-F312-40AF-A9A2-36389B35960D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Question: 

I understand how =E2=80=9Ciss" helps mitigate this attack =
(client knows response was from the appropriate issuer and not an attack =
where the request was answered by another issuer). 

However, how does =
passing =E2=80=9Cstate=E2=80=9D on the authorization_code grant token =
request help once you have the above in place? Is this against some =
alternate flow of this attack I don=E2=80=99t see, or is it meant to =
mitigate some entirely separate attack?

If one is attempting to work =
statelessly (e.g. your =E2=80=9Cstate=E2=80=9D parameter is actual state =
and not just a randomly generated value), a client would have always =
needed some way to differentiate which issuer the authorization_code =
grant token request would be sent to.

However, if an AS was treating =
=E2=80=9Ccode=E2=80=9D as a token (for instance, encoding: client, user, =
consent time and approved scopes), the AS now has to include the =
client=E2=80=99s state as well. This would effectively double (likely =
more with encoding) the state sent in the authorization response back to =
the client redirect URL, adding more pressure against maximum URL =
sizes.

-DW

On =
Jan 20, 2016, at 11:28 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

John Bradley and I collaborated to =
create the second OAuth 2.0 Mix-Up Mitigation draft.  Changes =
were:
=C2=B7       Simplifi=
ed by no longer specifying the signed JWT method for returning the =
mitigation information.
=C2=B7       Simplifi=
ed by no longer depending upon publication of a discovery metadata =
document.
=C2=B7       Added =
the =E2=80=9Cstate=E2=80=9D token request parameter.
=C2=B7       Added =
examples.
=C2=B7       Added =
John Bradley as an editor.
 
The specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-=
01
 
An HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigatio=
n-01.html
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
 
P.S.  =
This note was also posted at http://self-issued.info/?p=3D1526 and as @selfissued.
 
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_5DD52378-F312-40AF-A9A2-36389B35960D--


From nobody Thu Jan 21 13:50:39 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1381B31B3 for ; Thu, 21 Jan 2016 13:50:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60wWnrheFRsV for ; Thu, 21 Jan 2016 13:50:33 -0800 (PST)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 256551B33B1 for ; Thu, 21 Jan 2016 13:50:32 -0800 (PST)
Received: by mail-qg0-x232.google.com with SMTP id 6so43345881qgy.1 for ; Thu, 21 Jan 2016 13:50:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Qi0fTNOpJy2SUhYbqObFCxIqzp12kdEkLPkDSiQtUCI=; b=f5LHoXW3++7mhNViIFOEazzErugGAyJ1FfiyZ41BhIiH3tbYjRlqTsXJRL9cZ63NRj c5G0NQ6hnMiAH6aBffN8i+KeAZrAyScov70n6ok/6OhL0FZ2oY3JNlcC7dwP43/fPvap mr98VNR1rCfX3gn8EKa6GUfReV4A//yWMAltQmHrKtpluvA+xynKU3I3rVt4Q4ozMGwT z/PRdeeKtSyZgeJ3pPMjRQM0PAY9jTFsZgqajG8Reqlw/2tNnlbT/w5gDGEfxSpyqgrx eqND4iVF9TKoWxZe3BASNmL3Op+trtPkiP1LhfxyOIOsB6QUZCR2uWFuwXbTCxGQdPvD VPBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Qi0fTNOpJy2SUhYbqObFCxIqzp12kdEkLPkDSiQtUCI=; b=FbGrMKTJ95Rbe07ExIwzsA6uB/7tZoUZNQIRHHrvaisGwsJYi0KUg8ZGh3yH9Cxvac ckzycncvpoHZGQmHFHYCAfWyr27+2NbJIr4aAiK5gaE9yt2bG714MX8QK85R36rbVIT5 edXyAOHkkwWqLCsJBhmCnslbovkTVSS05YFOXqwdmNZfDH0wc2lTO0SgIbTtecKuD+lL GkeyfAhkLM5t4OF59C8j8lLxGXUlEzkD9FhAnixL09A1BGFOBD32ZUn9JROCOHOw13f0 MB1m4RGvznWYBu2j6oz/pzIvKsoTDYa5Nlqgdjwca1nI3Kpl2y96xInQ3wxYjaetUYFV 0sJQ==
X-Gm-Message-State: ALoCoQkafs9xE4nOjZA5YgVGm5U/4zKp9ELBFzGpLWSphvIsdbhYuDyJDQF5ytgr5x9ZhBxfmU3jaEOpBBZu+GumkPvxuFLjHA==
X-Received: by 10.140.19.231 with SMTP id 94mr56052615qgh.32.1453413031927; Thu, 21 Jan 2016 13:50:31 -0800 (PST)
Received: from [192.168.8.101] ([181.202.192.227]) by smtp.gmail.com with ESMTPSA id t187sm1417116qht.39.2016.01.21.13.50.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 13:50:30 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_92483AD3-CECA-42F0-8C40-89C7AA4285C0"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com>
Date: Thu, 21 Jan 2016 18:50:27 -0300
Message-Id: 
References:  <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com>
To: David Waite 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 21:50:38 -0000

--Apple-Mail=_92483AD3-CECA-42F0-8C40-89C7AA4285C0
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_F5271568-D7EA-4B98-8AA3-57C4B1967F88"


--Apple-Mail=_F5271568-D7EA-4B98-8AA3-57C4B1967F88
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes if the AS is encoding state + redirect_uri and grants in the code =
then it could get big. =20
In that case you probably would put a hash of the state in the code to =
manage size.  The alg would be up to the AS, as long as it used the same =
hash both places it would work.

Sending the state to the token endpoint is like having nonce and c_hash =
in the id_token, it binds the issued code to the browser instance.

This protects against codes that leak via redirect uri pattern matching. =
failures etc.  It prevents an attacker from being able to replay a code =
from a different browser.

If the client implements the other mitigations on the authorization =
endpoint, then it wouldn't be leaking the code via the token endpoint.=20=


The two mitigations are for different attacks, however some of the =
attacks combined both vulnerabilities.

Sending the iss and client_id is enough to stop the confused client =
attacks, but sending state on its own would not have stopped all of =
them.

We discussed having them in separate drafts, and may still do that.   =
However for discussion having them in one document is I think better in =
the short run.

John B.

> On Jan 21, 2016, at 4:48 PM, David Waite =
 wrote:
>=20
> Question:=20
>=20
> I understand how =E2=80=9Ciss" helps mitigate this attack (client =
knows response was from the appropriate issuer and not an attack where =
the request was answered by another issuer).=20
>=20
> However, how does passing =E2=80=9Cstate=E2=80=9D on the =
authorization_code grant token request help once you have the above in =
place? Is this against some alternate flow of this attack I don=E2=80=99t =
see, or is it meant to mitigate some entirely separate attack?
>=20
> If one is attempting to work statelessly (e.g. your =E2=80=9Cstate=E2=80=
=9D parameter is actual state and not just a randomly generated value), =
a client would have always needed some way to differentiate which issuer =
the authorization_code grant token request would be sent to.
>=20
> However, if an AS was treating =E2=80=9Ccode=E2=80=9D as a token (for =
instance, encoding: client, user, consent time and approved scopes), the =
AS now has to include the client=E2=80=99s state as well. This would =
effectively double (likely more with encoding) the state sent in the =
authorization response back to the client redirect URL, adding more =
pressure against maximum URL sizes.
>=20
> -DW
>=20
>> On Jan 20, 2016, at 11:28 PM, Mike Jones > wrote:
>>=20
>> John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up =
Mitigation draft.  Changes were:
>> =C2=B7       Simplified by no longer specifying the signed JWT method =
for returning the mitigation information.
>> =C2=B7       Simplified by no longer depending upon publication of a =
discovery metadata document.
>> =C2=B7       Added the =E2=80=9Cstate=E2=80=9D token request =
parameter.
>> =C2=B7       Added examples.
>> =C2=B7       Added John Bradley as an editor.
>> =20
>> The specification is available at:
>> =C2=B7       =
http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 =

>> =20
>> An HTML-formatted version is also available at:
>> =C2=B7       =
http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html =
=

>> =20
>>                                                           -- Mike
>> =20
>> P.S.  This note was also posted at http://self-issued.info/?p=3D1526 =
 and as @selfissued =
.
>> =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=_F5271568-D7EA-4B98-8AA3-57C4B1967F88
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes if the AS is encoding state + redirect_uri and grants in =
the code then it could get big.  
In that case you =
probably would put a hash of the state in the code to manage size. =
 The alg would be up to the AS, as long as it used the same hash =
both places it would work.

Sending the state to the token endpoint is like having nonce =
and c_hash in the id_token, it binds the issued code to the browser =
instance.

This =
protects against codes that leak via redirect uri pattern matching. =
failures etc.  It prevents an attacker from being able to replay a =
code from a different browser.

If the client implements the other =
mitigations on the authorization endpoint, then it wouldn't be leaking =
the code via the token endpoint. 

The two mitigations are for different =
attacks, however some of the attacks combined both =
vulnerabilities.

Sending the iss and client_id is enough to stop the confused =
client attacks, but sending state on its own would not have stopped all =
of them.

We =
discussed having them in separate drafts, and may still do that.   =
However for discussion having them in one document is I think better in =
the short run.

John B.

On =
Jan 21, 2016, at 4:48 PM, David Waite <david@alkaline-solutions.com> wrote:

Question: 

I understand how =E2=80=9Ciss" helps mitigate this attack =
(client knows response was from the appropriate issuer and not an attack =
where the request was answered by another issuer). 

However, how does =
passing =E2=80=9Cstate=E2=80=9D on the authorization_code grant token =
request help once you have the above in place? Is this against some =
alternate flow of this attack I don=E2=80=99t see, or is it meant to =
mitigate some entirely separate attack?

If one is attempting to work =
statelessly (e.g. your =E2=80=9Cstate=E2=80=9D parameter is actual state =
and not just a randomly generated value), a client would have always =
needed some way to differentiate which issuer the authorization_code =
grant token request would be sent to.

However, if an AS was treating =
=E2=80=9Ccode=E2=80=9D as a token (for instance, encoding: client, user, =
consent time and approved scopes), the AS now has to include the =
client=E2=80=99s state as well. This would effectively double (likely =
more with encoding) the state sent in the authorization response back to =
the client redirect URL, adding more pressure against maximum URL =
sizes.

-DW

On Jan =
20, 2016, at 11:28 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

John Bradley and I collaborated to =
create the second OAuth 2.0 Mix-Up Mitigation draft.  Changes =
were:
=C2=B7       Simplifi=
ed by no longer specifying the signed JWT method for returning the =
mitigation information.
=C2=B7       Simplifi=
ed by no longer depending upon publication of a discovery metadata =
document.
=C2=B7       Added =
the =E2=80=9Cstate=E2=80=9D token request parameter.
=C2=B7       Added =
examples.
=C2=B7       Added =
John Bradley as an editor.
 
The specification is available at:
=C2=B7       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-=
01
 
An HTML-formatted version is also available at:
=C2=B7       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigatio=
n-01.html
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
 
P.S.  =
This note was also posted at http://self-issued.info/?p=3D1526 and as @selfissued.
 
_______________________________________________
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=_F5271568-D7EA-4B98-8AA3-57C4B1967F88--

--Apple-Mail=_92483AD3-CECA-42F0-8C40-89C7AA4285C0
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjEyMTUwMjhaMCMGCSqGSIb3DQEJBDEWBBSYxfnrmmSeyZWNZJNosTlp
nu/kCDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBfueVGRmhpLjSx4Zx4y0GCsgTwG3n4CDvk/wkTNv1iqx5vFCwM0Ya5
npbGztEY6GM4txXDgj3wSTKHgrWoV3pbmHQV2ZqtMMy79W114xgzwQoeiFdpryYv3F1EaOb6knic
O6ZSUuUc5s6hixqth5P1wGcMldWXp1+9k8OUgLHKusJt4V+RBz2VPTB55X15j67nsRE+yQfepkhK
yXvtS0VGLdGnGPWLPwiEO1ceCYtdfoEbpxycLIQaEmm1xDYxDhxUDH5pEip8Vz0m9yvzzyuP6hNX
1YsCS+P+vzC6bf1uEgjYODP+fL4wh+kkvk6v359DPfDMgWKI+eSJTG1ue1sUAAAAAAAA
--Apple-Mail=_92483AD3-CECA-42F0-8C40-89C7AA4285C0--


From nobody Thu Jan 21 14:59:54 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7771B3462 for ; Thu, 21 Jan 2016 14:59:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m2so_T73ifF for ; Thu, 21 Jan 2016 14:59:48 -0800 (PST)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 4AAE01B345C for ; Thu, 21 Jan 2016 14:59:48 -0800 (PST)
Received: by mail-qg0-x22a.google.com with SMTP id 6so44629872qgy.1 for ; Thu, 21 Jan 2016 14:59:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=hhK+IbGH5eXpW8VYEDWYFBmQix48Dt1q/Mnd1wCEkoU=; b=IvToQyZrrqsU/1k8oJarP+NvF8gYNkcR831nQkppXloN0/nH0zjvFwT6OQZoWAKzmI eRwUAR2VfFr5QhAWDv1xFV46ysSUg8Fv7d5FwFJ2C6ZYzxndQkGHXw4mxQisujScMJlu upAbm7zsMYASBO7gM6ff4YSpOoqSzuzvhk5jvmmGmMFfw6lFVjVi1P9q3iOpSXmcnlkj gxI20KwIe9naT/urzZkWGBtN3PMWaNMidE8glsYxVGDmrHvjXW0itETuaCD6nE+Te//m Cewikzp1xzOr9xm0svgYwTCOf1KDXwLdvvFA8/h+2hdcStEtZe4drTfMwq9Lg9GG8Zug qdug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hhK+IbGH5eXpW8VYEDWYFBmQix48Dt1q/Mnd1wCEkoU=; b=mb5MJvbcfpC4QovFAOiCT4U2TnhhIs5mVRf1Hq6pQMrjzaWdF//I+Vt9Af2poVQxpW sJyETb8cOATofXxmJVZpDRWpMIPC9AiUw11kat/piF+vy8oOEBkn8qIOwoFBDXKW/BZY 0QlHFG3KUL1waCT3cbhxMWcgz5HGXRDU1NxKIdCdD5dAFKfux1kLrf6BFz31ZE8xhlov PanTj627tI9o+kuQHB5ZuPXfoOPE93m2yK9Hw4gNHNK6VrvRKo/UoyY13i2qyKCvxpL0 rjUzZQt753leZRwOSEM9016DYde7G1QvYLXtlsVOcWvqV1ziw/tEHnedxQQqEl2vAspN Josg==
X-Gm-Message-State: ALoCoQkrGbvpc4E0Ql3Cl1vb+ItpmqU+ZmU5F/Bu6P5YGv3cfPWsoTR37YiNARnta2jwea4pzXuMS2R03zihPBmcFiE1ylHxDA==
X-Received: by 10.140.152.18 with SMTP id 18mr57145585qhy.16.1453417187318; Thu, 21 Jan 2016 14:59:47 -0800 (PST)
Received: from [192.168.8.101] ([181.202.192.227]) by smtp.gmail.com with ESMTPSA id y200sm1537293qka.48.2016.01.21.14.59.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 14:59:46 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_F067AF4D-F2D7-44FB-A7C6-EE5D864359B5"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 21 Jan 2016 19:59:42 -0300
Message-Id: <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>
References: <569E22E1.5010402@gmx.net>   
To: Josh Mandel 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Jan 2016 22:59:52 -0000

--Apple-Mail=_F067AF4D-F2D7-44FB-A7C6-EE5D864359B5
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B0680197-073E-48A4-B741-C1DAAC58C31A"


--Apple-Mail=_B0680197-073E-48A4-B741-C1DAAC58C31A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

There have been a lot of discussions. I think Hannes posted some minutes =
of the F2F meeting we had with the security researchers.

The problem can=E2=80=99t be mitigated without some action on the client =
side.  It boils down to the client making a request to AS1 (=46rom =
it=E2=80=99s perspective) and getting back a response from AS 2 (that it =
thinks is AS1)

This can be done if AS1 is a good AS but has it=E2=80=99s logs =
compromised so that an attacker can read them. Hans Zandbelt built a =
proof of concept for the attack.=20

In some cases the attacker gets the code and the credential to use it at =
the good AS token endpoint and in others it just gets the code and can =
replay that at the client to extract information from the API through =
the client by binding the api access to a new account.

PKCE unfortunately mitigates a different attack, where the client is =
impersonated and trys to replay a intercepted code.  It however assumes =
the token endpoint is good, and is no help in the case of a compromised =
token endpoint.

The client in these attacks is vulnerable because it relies on some =
local state, or the value of the state parameter to know who the =
response is coming from.  This allows a authorization request that is =
intercepted to be used to create a new request in that browser to a =
different AS, or trick the client into using a Authorization endpoint =
for a different authorization server.

One problem is that OAuth doesn=E2=80=99t really have a unified concept =
of what a AS is.  Traditionally it is a Authorization endpoint URI, =
token end point URI and resource server URI that some one gives the =
client in some documentation.  =20

As ling as a client only talks to one AS then there is no problem.   =
However once a client is configured to talk to more than one AS, we have =
problems if one of those AS lies about it=E2=80=99s endpoints, or is =
compromised and used to attack another AS.   As a design goal you =
don=E2=80=99t want the overall  security to be limited by the weakest =
system.

One approach as Nat promotes is to have the authorization endpoint =
return the next hop, token endpoint for code or RS URI for token. The =
token endpoint must also return the RS URI or the client must push the =
RS URI to the token endpoint or the attacker just replaces the RS URI in =
the config and captures the token that way.=20

The other way is to provide a name for each AS as part of registration =
and the client not allow duplicate registrations with the same name.  =
When the response comes back the client checks the name against the one =
it made the request to.  If the name dereferences to a discovery =
document then the client can check that name at registration or runtime =
to validate the net hops.

I think the two approaches mitigate the attack in similar ways.  Nat=E2=80=
=99s is more REST friendly and returns the next hop as a parameter of =
header. =20

The one Mike and I wrote up based on the meeting in Germany provides =
identifiers (iss and client_id) that can be checked for validity in the =
simple case and be dereferenced via .well-known to get the information =
Nat=E2=80=99s proposal is providing.

Perhaps the main difference is Nat is using the token endpoint as the =
identifier for the AS and Mike=E2=80=99s is using location for a =
discovery document as the identifier.

I don=E2=80=99t recall the reasons using the token endpoint as the =
identifier was rejected at the meeting.  Perhaps others can post the =
reasons.

We need to close on this quickly, otherwise if we are indecisive fixes =
will not go into products for another year or so until this is a RFC.

That is my main concern.

John B.





> On Jan 21, 2016, at 11:50 AM, Josh Mandel  wrote:
>=20
> Thanks Nat - that's helpful. If both mitigations *can* work =
effectively, then I would like to see this group consider the decision =
between them carefully (if that hasn't happened yet). Again, don't =
hesitate to let me know if this is the wrong place/time for such =
discussion.
>=20
> At a high level, I would rather ask server developers to do some =
"coding", for two reasons:
>=20
> 1. Most OAuth servers talk to many, many clients. So consolidating the =
security critical work in one place (server) is a net savings of work =
(rather than asking each client to implement these checks.
>=20
> 2. OAuth server developers are typically more sophisticated than =
client developers, and therefore more likely to understand the =
implications and more likely to get these critical details correct. =
Asking each client developer to do something right is likely to result =
in heterogenius implementation and persistent security holes. But if the =
server does the heavy lifting, and clients just have to pass along an =
extra parameter, this is more likely to see consistent implementation =
(for example, clients will fail to work if misconfigured, which will =
prompt developers to fix them).
>=20
> On Jan 21, 2016 09:40, "Nat Sakimura" > wrote:
> Hi Josh,=20
>=20
> It is similar but slightly different IMHO.=20
>=20
> Section 4.6.4 of the RFC6819 is the access token phishing by a =
counterfeit resource server.=20
> The mix-up attack described here is the code phishing by a counterfeit =
token endpoint.=20
>=20
> In my view, both can be mitigated by the server returning the next =
step: i.e., authorization endpoint returning the legitimate token =
endpoint uri, and token endpoint returning legitimate resource endpoint =
uris. This involves no discovery endpoint, which is good.=20
>=20
> Your way also works. It is just the reverse of my proposal. The =
difference being that my proposal does not need any coding on the server =
but just configuration, and it can return more metadata if needed.=20
>=20
> Cheers,=20
>=20
> Nat
>=20
> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel =
>:
> Apologies if this is the wrong forum for my comment (and please direct =
me to the appropriate place in that case), but I have two questions =
about the propose mitigation (and the thinking behind it) that I think =
the write-up could address:
>=20
> 1. Could the writeup clarify whether/how the primary "mixup" threat =
differs from what RFC6819 identifies as in section 4.6.4?
>=20
> 2. Has the workgroup considered a mitigation that puts more =
responsibility on the authorization server, and less on the client? For =
example, if would be helpful for the writeup to clarify why having the =
client send an "audience field" (in the terminology of RFC6819) to the =
authorization endpoint would not mitigate the threat. (In that scenario, =
the authorization server can recognize that the audience does not =
correspond to a resource server it knows, rather than asking clients to =
make this check). I assume this approach has been considered and =
rejected as an incomplete mitigation, but I don't have visibility into =
where/how that discussion went.
>=20
> Thanks,
>=20
> Josh=20
> Hi all,
>=20
> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 =

>=20
> Please let us know by Feb 9th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>=20
> Note: This call is related to the announcement made on the list =
earlier
> this month, see
> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html =
. More
> time for analysis is provided due to the complexity of the topic.
>=20
> Ciao
> Hannes & Derek
>=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=_B0680197-073E-48A4-B741-C1DAAC58C31A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

There have been a lot of discussions. I think Hannes posted =
some minutes of the F2F meeting we had with the security =
researchers.

The =
problem can=E2=80=99t be mitigated without some action on the client =
side.  It boils down to the client making a request to AS1 (=46rom =
it=E2=80=99s perspective) and getting back a response from AS 2 (that it =
thinks is AS1)

This can be done if AS1 is a good AS but has it=E2=80=99s =
logs compromised so that an attacker can read them. Hans Zandbelt built =
a proof of concept for the attack. 

In some cases the attacker gets the =
code and the credential to use it at the good AS token endpoint and in =
others it just gets the code and can replay that at the client to =
extract information from the API through the client by binding the api =
access to a new account.

PKCE unfortunately mitigates a different attack, where the =
client is impersonated and trys to replay a intercepted code.  It =
however assumes the token endpoint is good, and is no help in the case =
of a compromised token endpoint.

The client in these attacks is =
vulnerable because it relies on some local state, or the value of the =
state parameter to know who the response is coming from.  This =
allows a authorization request that is intercepted to be used to create =
a new request in that browser to a different AS, or trick the client =
into using a Authorization endpoint for a different authorization =
server.

One =
problem is that OAuth doesn=E2=80=99t really have a unified concept of =
what a AS is.  Traditionally it is a Authorization endpoint URI, =
token end point URI and resource server URI that some one gives the =
client in some documentation.   

As ling as a client only talks to one =
AS then there is no problem.   However once a client is configured =
to talk to more than one AS, we have problems if one of those AS lies =
about it=E2=80=99s endpoints, or is compromised and used to attack =
another AS.   As a design goal you don=E2=80=99t want the overall =
 security to be limited by the weakest system.

One approach as Nat =
promotes is to have the authorization endpoint return the next hop, =
token endpoint for code or RS URI for token. The token endpoint must =
also return the RS URI or the client must push the RS URI to the token =
endpoint or the attacker just replaces the RS URI in the config and =
captures the token that way. 

The other way is to provide a name for =
each AS as part of registration and the client not allow duplicate =
registrations with the same name.  When the response comes back the =
client checks the name against the one it made the request to.  If =
the name dereferences to a discovery document then the client can check =
that name at registration or runtime to validate the net hops.

I think the two =
approaches mitigate the attack in similar ways.  Nat=E2=80=99s is =
more REST friendly and returns the next hop as a parameter of header. =
 

The one =
Mike and I wrote up based on the meeting in Germany provides identifiers =
(iss and client_id) that can be checked for validity in the simple case =
and be dereferenced via .well-known to get the information Nat=E2=80=99s =
proposal is providing.

Perhaps the main difference is Nat is using the token =
endpoint as the identifier for the AS and Mike=E2=80=99s is using =
location for a discovery document as the identifier.

I don=E2=80=99t recall =
the reasons using the token endpoint as the identifier was rejected at =
the meeting.  Perhaps others can post the reasons.

We need to close on this =
quickly, otherwise if we are indecisive fixes will not go into products =
for another year or so until this is a RFC.

That is my main concern.

John B.





On Jan 21, 2016, at 11:50 AM, Josh Mandel <jmandel@gmail.com> =
wrote:

Thanks Nat - that's helpful. If both mitigations =
*can* work effectively, then I would like to see this group consider the =
decision between them carefully (if that hasn't happened yet). Again, =
don't hesitate to let me know if this is the wrong place/time for such =
discussion. 
At a high level, I would =
rather ask server developers to do some "coding", for two reasons:
1. Most OAuth servers talk to many, many clients. =
So consolidating the security critical work in one place (server) is a =
net savings of work (rather than asking each client to implement these =
checks. 
2. OAuth server developers are =
typically more sophisticated than client developers, and therefore more =
likely to understand the implications and more likely to get these =
critical details correct. Asking each client developer to do something =
right is likely to result in heterogenius implementation and persistent =
security holes. But if the server does the heavy lifting, and clients =
just have to pass along an extra parameter, this is more likely to see =
consistent implementation (for example, clients will fail to work if =
misconfigured, which will prompt developers to fix them). 


On Jan 21, 2016 09:40, "Nat Sakimura" <sakimura@gmail.com> =
wrote:
Hi Josh, 

It is similar but =
slightly different IMHO. 

Section 4.6.4 of the RFC6819 is the =
access token phishing by a counterfeit resource server. 
The mix-up attack described here is the code phishing by a =
counterfeit token endpoint. 

In my view, both can be mitigated by =
the server returning the next step: i.e., authorization endpoint =
returning the legitimate token endpoint uri, and token endpoint =
returning legitimate resource endpoint uris. This involves no discovery =
endpoint, which is good. 

Your way also works. It is just the =
reverse of my proposal. The difference being that my proposal does not =
need any coding on the server but just configuration, and it can return =
more metadata if needed. 

Cheers, 

Nat

2016=E5=B9=B41=E6=9C=882=
1=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel <jmandel@gmail.com>:
Apologies if this is =
the wrong forum for my comment (and please direct me to the appropriate =
place in that case), but I have two questions about the propose =
mitigation (and the thinking behind it) that I think the write-up could =
address:
1. Could the writeup clarify =
whether/how the primary "mixup" threat differs from what RFC6819 =
identifies as in section 4.6.4? 
2. Has the =
workgroup considered a mitigation that puts more responsibility on the =
authorization server, and less on the client? For example, if would be =
helpful for the writeup to clarify why having the client send an =
"audience field" (in the terminology of RFC6819) to the authorization =
endpoint would not mitigate the threat. (In that scenario, the =
authorization server can recognize that the audience does not correspond =
to a resource server it knows, rather than asking clients to make this =
check). I assume this approach has been considered and rejected as an =
incomplete mitigation, but I don't have visibility into where/how that =
discussion went. 
Thanks, 
Josh 




Hi all,



this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see

https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation=
-00



Please let us know by Feb 9th whether you accept / object to the

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

working group.



Note: This call is related to the announcement made on the list =
earlier

this month, see

http://www.ietf.org/mail-archive/web/oauth/current/msg15336.htm=
l. More

time for analysis is provided due to the complexity of the topic.



Ciao

Hannes & Derek




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





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

=

--Apple-Mail=_B0680197-073E-48A4-B741-C1DAAC58C31A--

--Apple-Mail=_F067AF4D-F2D7-44FB-A7C6-EE5D864359B5
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjEyMjU5NDJaMCMGCSqGSIb3DQEJBDEWBBSirjjBB+Y56EUQh/dZ1BYo
VmY8xjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQB6EnkiBo1t+EFKaip+izhQqOCFfYwaKWoKCW6ZkRsjX6wv/F04+DuN
46HmRxBDMftLE/RFsnY6Q3UicoOsggOxyHbnh48Oi9YdAGCrEQmM60y64v4OIX9C5QJT58dnZYKA
iEov7I8AEw/VYrZqcgCMTIOQ4qixUwAQXMQzaUDn5P8Y/L6iwsb95dNu4Ahw+Ojq7DcDCSn58IfL
8pGdfEZ1qVJd7BJZEY+RlbF9QYyzYvUH/WGS0+I7V8MbTXje9xm8gTgOFmxfwSxbp+79clIcSQLN
bKXRE/mZGWppCfLrAmM2KbOqvXY0GTvWdqhzcvh28rDg0UAABGoSe/QzkTl4AAAAAAAA
--Apple-Mail=_F067AF4D-F2D7-44FB-A7C6-EE5D864359B5--


From nobody Thu Jan 21 16:38:27 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196B61B357E for ; Thu, 21 Jan 2016 16:38:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0osq7o1zQl2 for ; Thu, 21 Jan 2016 16:38:22 -0800 (PST)
Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7941B357D for ; Thu, 21 Jan 2016 16:38:21 -0800 (PST)
Received: by mail-qg0-x22b.google.com with SMTP id e32so46540506qgf.3 for ; Thu, 21 Jan 2016 16:38:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=RleK2Bz+oCnkqrBuluXkPsvhb3HR1MCK6CUS5mUIjHM=; b=0t/QzW5xnTB6+ScCDGCmIZcSR2CScW3zHSf8rYbAQ87hwX3E8FBci6qEx3rkQKwHmS O0VypJCc79fDHWO0Eh9+mwzUq2bqpR3PpIOcgxFdh2ghAsnHpnJlsm0KBExITmZBw/sD DoZuTnBUI1ocWcN4k9yPk7b0Nsvmfc/ebS8okEX/Z4iDucWHG2bRPgX/qQI236rDyrVe 6o8ODJWLyk/80MGTurWYkj59cErcnFB0B+q8BA6QBKpvD4v2eHO5rsL5Tu8T5xXyVYW1 Rv+qwqvgVkWJKXStLnD7TTXsbbJrozhK+H6EWWXpIP63v1qehkK5JFJk7CvHrUs7kH2q E9fA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=RleK2Bz+oCnkqrBuluXkPsvhb3HR1MCK6CUS5mUIjHM=; b=O+u6mzqdSABjNzYE6gi4WIhoU56pdZuJTQcvi3h35LOrq23YM2DZrwMIyYUNuZ9TTO QpclTHqB5UokL3bXJCpqerftH5hZOf+VAI9j/VCsTuF8pi2Kn/1CTElrC1f2wqaPxfWA 9WCaYDTd6+GG55Y9y4pkDS2/EznPNPUZrC8FmN/D18ubg435wIvWu3fCairU0eA3odRB RL4lLOuvBNEuciFqtaK4DzK4AOc3fIEe/lD6xTPfrnxwEpbrqpRju/o+OJDTxFzAsOfj 2yFMN2d+lVvuYk6f/wyomb/Mc3gwefjIutBw6GfZ3L4J2upJ2i22yL9NMlmdCqIpMNPx ZFsw==
X-Gm-Message-State: AG10YOSIOuIyvVu58o7YKCAfBdkntCUrBe97XIkEiSEdW4cWpfm9gWswHHlJ+ETl2hJqVQsxvBBWgww7PZ0acQ==
X-Received: by 10.140.144.16 with SMTP id 16mr239673qhq.81.1453423101111; Thu, 21 Jan 2016 16:38:21 -0800 (PST)
MIME-Version: 1.0
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>
In-Reply-To: <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>
From: Nat Sakimura 
Date: Fri, 22 Jan 2016 00:38:10 +0000
Message-ID: 
To: John Bradley , Josh Mandel 
Content-Type: multipart/alternative; boundary=001a11355ee2a6a0b20529e16fc7
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 00:38:26 -0000

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

Still doing the analysis. We spent 1.5 hours today with John, George, nov
and me on the OpenID Connect WG call on this issue. John explained the
mitigation, but none of us was convinced that it works.

Then, after the call, I and nov went on with various scenarios. The interim
conclusion is that:

   - client_id response parameter does not help. There are legitimate cases
   that client_id duplicates out there and we cannot ban that.
   - iss response parameter does not help unless the discovery is performed
   and the value of iss is checked against the value of OAuth issuer inside
   the document. (<- Discovery becomes mandatory. From our experience on RP
   discovery step in OpenID 2.0, chance of this being done properly seems t=
o
   be rather slim.)
   - sending the state to the token endpoint helps in the case code was
   stollen, but code should not be stolen to start with.

Cheers,

Nat


2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John Bradley :

> There have been a lot of discussions. I think Hannes posted some minutes
> of the F2F meeting we had with the security researchers.
>
> The problem can=E2=80=99t be mitigated without some action on the client =
side.  It
> boils down to the client making a request to AS1 (From it=E2=80=99s persp=
ective)
> and getting back a response from AS 2 (that it thinks is AS1)
>
> This can be done if AS1 is a good AS but has it=E2=80=99s logs compromise=
d so that
> an attacker can read them. Hans Zandbelt built a proof of concept for the
> attack.
>
> In some cases the attacker gets the code and the credential to use it at
> the good AS token endpoint and in others it just gets the code and can
> replay that at the client to extract information from the API through the
> client by binding the api access to a new account.
>
> PKCE unfortunately mitigates a different attack, where the client is
> impersonated and trys to replay a intercepted code.  It however assumes t=
he
> token endpoint is good, and is no help in the case of a compromised token
> endpoint.
>
> The client in these attacks is vulnerable because it relies on some local
> state, or the value of the state parameter to know who the response is
> coming from.  This allows a authorization request that is intercepted to =
be
> used to create a new request in that browser to a different AS, or trick
> the client into using a Authorization endpoint for a different
> authorization server.
>
> One problem is that OAuth doesn=E2=80=99t really have a unified concept o=
f what a
> AS is.  Traditionally it is a Authorization endpoint URI, token end point
> URI and resource server URI that some one gives the client in some
> documentation.
>
> As ling as a client only talks to one AS then there is no problem.
> However once a client is configured to talk to more than one AS, we have
> problems if one of those AS lies about it=E2=80=99s endpoints, or is comp=
romised
> and used to attack another AS.   As a design goal you don=E2=80=99t want =
the
> overall  security to be limited by the weakest system.
>
> One approach as Nat promotes is to have the authorization endpoint return
> the next hop, token endpoint for code or RS URI for token. The token
> endpoint must also return the RS URI or the client must push the RS URI t=
o
> the token endpoint or the attacker just replaces the RS URI in the config
> and captures the token that way.
>
> The other way is to provide a name for each AS as part of registration an=
d
> the client not allow duplicate registrations with the same name.  When th=
e
> response comes back the client checks the name against the one it made th=
e
> request to.  If the name dereferences to a discovery document then the
> client can check that name at registration or runtime to validate the net
> hops.
>
> I think the two approaches mitigate the attack in similar ways.  Nat=E2=
=80=99s is
> more REST friendly and returns the next hop as a parameter of header.
>
> The one Mike and I wrote up based on the meeting in Germany provides
> identifiers (iss and client_id) that can be checked for validity in the
> simple case and be dereferenced via .well-known to get the information
> Nat=E2=80=99s proposal is providing.
>
> Perhaps the main difference is Nat is using the token endpoint as the
> identifier for the AS and Mike=E2=80=99s is using location for a discover=
y document
> as the identifier.
>
> I don=E2=80=99t recall the reasons using the token endpoint as the identi=
fier was
> rejected at the meeting.  Perhaps others can post the reasons.
>
> We need to close on this quickly, otherwise if we are indecisive fixes
> will not go into products for another year or so until this is a RFC.
>
> That is my main concern.
>
> John B.
>
>
>
>
>
> On Jan 21, 2016, at 11:50 AM, Josh Mandel  wrote:
>
> Thanks Nat - that's helpful. If both mitigations *can* work effectively,
> then I would like to see this group consider the decision between them
> carefully (if that hasn't happened yet). Again, don't hesitate to let me
> know if this is the wrong place/time for such discussion.
>
> At a high level, I would rather ask server developers to do some "coding"=
,
> for two reasons:
>
> 1. Most OAuth servers talk to many, many clients. So consolidating the
> security critical work in one place (server) is a net savings of work
> (rather than asking each client to implement these checks.
>
> 2. OAuth server developers are typically more sophisticated than client
> developers, and therefore more likely to understand the implications and
> more likely to get these critical details correct. Asking each client
> developer to do something right is likely to result in heterogenius
> implementation and persistent security holes. But if the server does the
> heavy lifting, and clients just have to pass along an extra parameter, th=
is
> is more likely to see consistent implementation (for example, clients wil=
l
> fail to work if misconfigured, which will prompt developers to fix them).
> On Jan 21, 2016 09:40, "Nat Sakimura"  wrote:
>
>> Hi Josh,
>>
>> It is similar but slightly different IMHO.
>>
>> Section 4.6.4 of the RFC6819 is the access token phishing by a
>> counterfeit resource server.
>> The mix-up attack described here is the code phishing by a counterfeit
>> token endpoint.
>>
>> In my view, both can be mitigated by the server returning the next step:
>> i.e., authorization endpoint returning the legitimate token endpoint uri=
,
>> and token endpoint returning legitimate resource endpoint uris. This
>> involves no discovery endpoint, which is good.
>>
>> Your way also works. It is just the reverse of my proposal. The
>> difference being that my proposal does not need any coding on the server
>> but just configuration, and it can return more metadata if needed.
>>
>> Cheers,
>>
>> Nat
>>
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel :
>>
>>> Apologies if this is the wrong forum for my comment (and please direct
>>> me to the appropriate place in that case), but I have two questions abo=
ut
>>> the propose mitigation (and the thinking behind it) that I think the
>>> write-up could address:
>>>
>>> 1. Could the writeup clarify whether/how the primary "mixup" threat
>>> differs from what RFC6819 identifies as in section 4.6.4?
>>>
>>> 2. Has the workgroup considered a mitigation that puts more
>>> responsibility on the authorization server, and less on the client? For
>>> example, if would be helpful for the writeup to clarify why having the
>>> client send an "audience field" (in the terminology of RFC6819) to the
>>> authorization endpoint would not mitigate the threat. (In that scenario=
,
>>> the authorization server can recognize that the audience does not
>>> correspond to a resource server it knows, rather than asking clients to
>>> make this check). I assume this approach has been considered and reject=
ed
>>> as an incomplete mitigation, but I don't have visibility into where/how
>>> that discussion went.
>>>
>>> Thanks,
>>>
>>> Josh
>>> Hi all,
>>>
>>> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
>>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>>>
>>> Please let us know by Feb 9th whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth
>>> working group.
>>>
>>> Note: This call is related to the announcement made on the list earlier
>>> this month, see
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
>>> time for analysis is provided due to the complexity of the topic.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

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


Still doing the analysis. We spent 1.5 hours today with Jo=
hn, George, nov and me on the OpenID Connect WG call on this issue. John ex=
plained the mitigation, but none of us was convinced that it works.=C2=A0
Then, after the call, I and nov went on with various scen=
arios. The interim conclusion is that:=C2=A0
  • client_id response parameter does not help.=
 There are legitimate cases that client_id duplicates out there and we cann=
ot ban that. =C2=A0
  • iss response parameter does not help unless=
 the discovery is performed and the value of iss is checked against the val=
ue of OAuth issuer inside the document. (<- Discovery becomes mandatory.=
 From our experience on RP discovery step in OpenID 2.0, chance of this bei=
ng done properly seems to be rather slim.)=C2=A0
  • sending the state =
to the token endpoint helps in the case code was stollen, but code should n=
ot be stolen to start with.=C2=A0
Cheers,=C2=A0

Nat


2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John=
 Bradley <ve7jtb@=
ve7jtb.com>:
There have been a lot=
 of discussions. I think Hannes posted some minutes of the F2F meeting we h=
ad with the security researchers.

The problem can=E2=80=
=99t be mitigated without some action on the client side.=C2=A0 It boils do=
wn to the client making a request to AS1 (From it=E2=80=99s perspective) an=
d getting back a response from AS 2 (that it thinks is AS1)

<=
/div>
This can be done if AS1 is a good AS but has it=E2=80=99s logs co=
mpromised so that an attacker can read them. Hans Zandbelt built a proof of=
 concept for the attack.=C2=A0

In some cases the a=
ttacker gets the code and the credential to use it at the good AS token end=
point and in others it just gets the code and can replay that at the client=
 to extract information from the API through the client by binding the api =
access to a new account.

PKCE unfortunately mitiga=
tes a different attack, where the client is impersonated and trys to replay=
 a intercepted code.=C2=A0 It however assumes the token endpoint is good, a=
nd is no help in the case of a compromised token endpoint.

The client in these attacks is vulnerable because it relies on som=
e local state, or the value of the state parameter to know who the response=
 is coming from.=C2=A0 This allows a authorization request that is intercep=
ted to be used to create a new request in that browser to a different AS, o=
r trick the client into using a Authorization endpoint for a different auth=
orization server.

One problem is that OAuth doesn=
=E2=80=99t really have a unified concept of what a AS is.=C2=A0 Traditional=
ly it is a Authorization endpoint URI, token end point URI and resource ser=
ver URI that some one gives the client in some documentation. =C2=A0=C2=A0<=
/div>

As ling as a client only talks to one AS then ther=
e is no problem. =C2=A0 However once a client is configured to talk to more=
 than one AS, we have problems if one of those AS lies about it=E2=80=99s e=
ndpoints, or is compromised and used to attack another AS. =C2=A0 As a desi=
gn goal you don=E2=80=99t want the overall =C2=A0security to be limited by =
the weakest system.

One approach as Nat promotes i=
s to have the authorization endpoint return the next hop, token endpoint fo=
r code or RS URI for token. The token endpoint must also return the RS URI =
or the client must push the RS URI to the token endpoint or the attacker ju=
st replaces the RS URI in the config and captures the token that way.=C2=A0=


The other way is to provide a name for each AS as=
 part of registration and the client not allow duplicate registrations with=
 the same name.=C2=A0 When the response comes back the client checks the na=
me against the one it made the request to.=C2=A0 If the name dereferences t=
o a discovery document then the client can check that name at registration =
or runtime to validate the net hops.

I think the t=
wo approaches mitigate the attack in similar ways.=C2=A0 Nat=E2=80=99s is m=
ore REST friendly and returns the next hop as a parameter of header. =C2=A0=


The one Mike and I wrote up based on the meeting =
in Germany provides identifiers (iss and client_id) that can be checked for=
 validity in the simple case and be dereferenced via .well-known to get the=
 information Nat=E2=80=99s proposal is providing.

=
Perhaps the main difference is Nat is using the token endpoint as the ident=
ifier for the AS and Mike=E2=80=99s is using location for a discovery docum=
ent as the identifier.

I don=E2=80=99t recall the =
reasons using the token endpoint as the identifier was rejected at the meet=
ing.=C2=A0 Perhaps others can post the reasons.

We=
 need to close on this quickly, otherwise if we are indecisive fixes will n=
ot go into products for another year or so until this is a RFC.
<=
br>
That is my main concern.

John B.


<=
div>


O=
n Jan 21, 2016, at 11:50 AM, Josh Mandel <jmandel@gmail.com> wrote:

Thanks Nat - that's helpful. If both mitigations *can* work=
 effectively, then I would like to see this group consider the decision bet=
ween them carefully (if that hasn't happened yet). Again, don't hes=
itate to let me know if this is the wrong place/time for such discussion. <=
/p>
At a high level, I would rather ask server developers to =
do some "coding", for two reasons:
1. Most OAut=
h servers talk to many, many clients. So consolidating the security critica=
l work in one place (server) is a net savings of work (rather than asking e=
ach client to implement these checks. 
2. OAuth server de=
velopers are typically more sophisticated than client developers, and there=
fore more likely to understand the implications and more likely to get thes=
e critical details correct. Asking each client developer to do something ri=
ght is likely to result in heterogenius implementation and persistent secur=
ity holes. But if the server does the heavy lifting, and clients just have =
to pass along an extra parameter, this is more likely to see consistent imp=
lementation (for example, clients will fail to work if misconfigured, which=
 will prompt developers to fix them). 


On Jan 21, 2016 09:40, "Nat Sakimura" =
<sakimura@gmail.=
com> wrote:
<=
div dir=3D"ltr">Hi Josh,=C2=A0

It is similar but slightl=
y different IMHO.=C2=A0

Section 4.6.4 of the RFC68=
19 is the access token phishing by a counterfeit resource server.=C2=A0
The mix-up attack described here is the code phishing by a counterfe=
it token endpoint.=C2=A0

In my view, both can be m=
itigated by the server returning the next step: i.e., authorization endpoin=
t returning the legitimate token endpoint uri, and token endpoint returning=
 legitimate resource endpoint uris. This involves no discovery endpoint, wh=
ich is good.=C2=A0

Your way also works. It is just=
 the reverse of my proposal. The difference being that my proposal does not=
 need any coding on the server but just configuration, and it can return mo=
re metadata if needed.=C2=A0

Cheers,=C2=A0

Nat

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel <<=
a href=3D"mailto:jmandel@gmail.com" target=3D"_blank">jmandel@gmail.com=
>:
Apologies if t=
his is the wrong forum for my comment (and please direct me to the appropri=
ate place in that case), but I have two questions about the propose mitigat=
ion (and the thinking behind it) that I think the write-up could address:
1. Could the writeup clarify whether/how the primary "=
;mixup" threat differs from what RFC6819 identifies as in section 4.6.=
4? 
2. Has the workgroup considered a mitigation that put=
s more responsibility on the authorization server, and less on the client? =
For example, if would be helpful for the writeup to clarify why having the =
client send an "audience field" (in the terminology of RFC6819) t=
o the authorization endpoint would not mitigate the threat. (In that scenar=
io, the authorization server can recognize that the audience does not corre=
spond to a resource server it knows, rather than asking clients to make thi=
s check). I assume this approach has been considered and rejected as an inc=
omplete mitigation, but I don't have visibility into where/how that dis=
cussion went. 
Thanks, 
Josh 




https://tools.ietf.org/html/draft-=
jones-oauth-mix-up-mitigation-00



Please let us know by Feb 9th whether you accept / object to the

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

working group.



Note: This call is related to the announcement made on the list earlier

this month, see

http://www.ietf.org/mail-archive/web=
/oauth/current/msg15336.html. More

time for analysis is provided due to the complexity of the topic.



Ciao

Hannes & Derek




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





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


--001a11355ee2a6a0b20529e16fc7--


From nobody Thu Jan 21 16:43:47 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FB41B357E for ; Thu, 21 Jan 2016 16:43:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTaFe3MERb7Y for ; Thu, 21 Jan 2016 16:43:40 -0800 (PST)
Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 B4E141B3583 for ; Thu, 21 Jan 2016 16:43:40 -0800 (PST)
Received: by mail-oi0-x22b.google.com with SMTP id o124so37810699oia.3 for ; Thu, 21 Jan 2016 16:43:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NVXC6Dog32ffwul+rjhukobuddvXEcWnbUEpt56L8f0=; b=oOwt1Lr/flBOs0Ltn+MLe470pk5sBD327yNmWq7diqE5JNKnJUMoXkr/7KAQN5qhyZ 6W5cxsrJogJCSaz/RJ0c/pReapsNVevjKK2RiVD9GBZ9Rsf8jc3B9TdDI8Jw3K6N+Bay 0gmWb8hmTTpWuN2P8cMS3C0Y1sXeSk7ER4LVsss5dOUSS1plaX/RmSBz4QiLiFjXpIqZ l+FwLGhr44RhGav70pz2/GvZ9JBiS0KASf8mr0Sy7GsbX1OP/pRG4Q6wFtio7Jll8CvY cwOEwcCSi5ai7AD97AcTrq9Syqb5Q5vbeb0a1LxPtEl6evAb7cl1kSXI8jI8TcoWassr NIqw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=NVXC6Dog32ffwul+rjhukobuddvXEcWnbUEpt56L8f0=; b=Ku0TN31exs9UtlNLeoSwvViaJZMC267Jc+L8xvips7ZGLJjU8BS6PQf4uFsHZAswF0 tgm78bjSjh6HPuexSdU/mt6k8F0d+hqduirw06mVfXq+ITid/lYkoIm+W9yhGMGOHz+e /478Ecn4M4QCuNaKeAAjyd1oohsO1yW0d2ala3KqwzTLX49ZdNL8Y3zH3O4axQOaZjPR lS9V4jBoTeJWDxNdBmdaY/eZTY+ADeAyL7v2bblEUnU7UJ3WzgflLUYbaSQmRQD7Gjzm GwEYWFfdBSQgoyNYWU94+bV4K1y4a4ek8NiaO7h+FUESIjTsXDM6jID0EM/emqvr5HVV MTCA==
X-Gm-Message-State: AG10YOTDREWqFNPvlJ8ngd6YN1Bo8s3QGBZZE20HY5K9fY42ypbZQbg3gaNUPOBAqFQA1IQY7mWAGnxv9EFtNHaa
X-Received: by 10.202.53.86 with SMTP id c83mr159959oia.13.1453423419987; Thu, 21 Jan 2016 16:43:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.227.39 with HTTP; Thu, 21 Jan 2016 16:43:20 -0800 (PST)
In-Reply-To: <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>
From: William Denniss 
Date: Fri, 22 Jan 2016 08:43:20 +0800
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=001a113d45d8a8609c0529e18264
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 00:43:44 -0000

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

When I first heard Nat's proposal in Yokohama I thought it was pretty
elegant. And remember that it was first proposed to add more RESTful
behavior to OAuth and not just as a mix-up mitigation.

For the mix-up topic, I wonder if this comes down to: if you are already
doing OpenID Connect, the issuer/discovery path feels natural, as that's
what you're used to. But if you're pure OAuth, without those concepts then
Nat's solution is more natural?

I do recall some contention in Yokohama around returning the same info
twice (e.g. returning the token endpoint, and returning a discovery
document URL which could potential reference a different token endpoint).

There's something quite nice about the possibility for the AS returning
more detailed configuration like the relevant resource servers where the
token can be used =E2=80=93 something that discovery can't do as it doesn't=
 have
the context of the authorization grant.

On Fri, Jan 22, 2016 at 6:59 AM, John Bradley  wrote:

> There have been a lot of discussions. I think Hannes posted some minutes
> of the F2F meeting we had with the security researchers.
>
> The problem can=E2=80=99t be mitigated without some action on the client =
side.  It
> boils down to the client making a request to AS1 (From it=E2=80=99s persp=
ective)
> and getting back a response from AS 2 (that it thinks is AS1)
>
> This can be done if AS1 is a good AS but has it=E2=80=99s logs compromise=
d so that
> an attacker can read them. Hans Zandbelt built a proof of concept for the
> attack.
>
> In some cases the attacker gets the code and the credential to use it at
> the good AS token endpoint and in others it just gets the code and can
> replay that at the client to extract information from the API through the
> client by binding the api access to a new account.
>
> PKCE unfortunately mitigates a different attack, where the client is
> impersonated and trys to replay a intercepted code.  It however assumes t=
he
> token endpoint is good, and is no help in the case of a compromised token
> endpoint.
>
> The client in these attacks is vulnerable because it relies on some local
> state, or the value of the state parameter to know who the response is
> coming from.  This allows a authorization request that is intercepted to =
be
> used to create a new request in that browser to a different AS, or trick
> the client into using a Authorization endpoint for a different
> authorization server.
>
> One problem is that OAuth doesn=E2=80=99t really have a unified concept o=
f what a
> AS is.  Traditionally it is a Authorization endpoint URI, token end point
> URI and resource server URI that some one gives the client in some
> documentation.
>
> As ling as a client only talks to one AS then there is no problem.
> However once a client is configured to talk to more than one AS, we have
> problems if one of those AS lies about it=E2=80=99s endpoints, or is comp=
romised
> and used to attack another AS.   As a design goal you don=E2=80=99t want =
the
> overall  security to be limited by the weakest system.
>
> One approach as Nat promotes is to have the authorization endpoint return
> the next hop, token endpoint for code or RS URI for token. The token
> endpoint must also return the RS URI or the client must push the RS URI t=
o
> the token endpoint or the attacker just replaces the RS URI in the config
> and captures the token that way.
>
> The other way is to provide a name for each AS as part of registration an=
d
> the client not allow duplicate registrations with the same name.  When th=
e
> response comes back the client checks the name against the one it made th=
e
> request to.  If the name dereferences to a discovery document then the
> client can check that name at registration or runtime to validate the net
> hops.
>
> I think the two approaches mitigate the attack in similar ways.  Nat=E2=
=80=99s is
> more REST friendly and returns the next hop as a parameter of header.
>
> The one Mike and I wrote up based on the meeting in Germany provides
> identifiers (iss and client_id) that can be checked for validity in the
> simple case and be dereferenced via .well-known to get the information
> Nat=E2=80=99s proposal is providing.
>
> Perhaps the main difference is Nat is using the token endpoint as the
> identifier for the AS and Mike=E2=80=99s is using location for a discover=
y document
> as the identifier.
>
> I don=E2=80=99t recall the reasons using the token endpoint as the identi=
fier was
> rejected at the meeting.  Perhaps others can post the reasons.
>
> We need to close on this quickly, otherwise if we are indecisive fixes
> will not go into products for another year or so until this is a RFC.
>
> That is my main concern.
>
> John B.
>
>
>
>
>
> On Jan 21, 2016, at 11:50 AM, Josh Mandel  wrote:
>
> Thanks Nat - that's helpful. If both mitigations *can* work effectively,
> then I would like to see this group consider the decision between them
> carefully (if that hasn't happened yet). Again, don't hesitate to let me
> know if this is the wrong place/time for such discussion.
>
> At a high level, I would rather ask server developers to do some "coding"=
,
> for two reasons:
>
> 1. Most OAuth servers talk to many, many clients. So consolidating the
> security critical work in one place (server) is a net savings of work
> (rather than asking each client to implement these checks.
>
> 2. OAuth server developers are typically more sophisticated than client
> developers, and therefore more likely to understand the implications and
> more likely to get these critical details correct. Asking each client
> developer to do something right is likely to result in heterogenius
> implementation and persistent security holes. But if the server does the
> heavy lifting, and clients just have to pass along an extra parameter, th=
is
> is more likely to see consistent implementation (for example, clients wil=
l
> fail to work if misconfigured, which will prompt developers to fix them).
> On Jan 21, 2016 09:40, "Nat Sakimura"  wrote:
>
>> Hi Josh,
>>
>> It is similar but slightly different IMHO.
>>
>> Section 4.6.4 of the RFC6819 is the access token phishing by a
>> counterfeit resource server.
>> The mix-up attack described here is the code phishing by a counterfeit
>> token endpoint.
>>
>> In my view, both can be mitigated by the server returning the next step:
>> i.e., authorization endpoint returning the legitimate token endpoint uri=
,
>> and token endpoint returning legitimate resource endpoint uris. This
>> involves no discovery endpoint, which is good.
>>
>> Your way also works. It is just the reverse of my proposal. The
>> difference being that my proposal does not need any coding on the server
>> but just configuration, and it can return more metadata if needed.
>>
>> Cheers,
>>
>> Nat
>>
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel :
>>
>>> Apologies if this is the wrong forum for my comment (and please direct
>>> me to the appropriate place in that case), but I have two questions abo=
ut
>>> the propose mitigation (and the thinking behind it) that I think the
>>> write-up could address:
>>>
>>> 1. Could the writeup clarify whether/how the primary "mixup" threat
>>> differs from what RFC6819 identifies as in section 4.6.4?
>>>
>>> 2. Has the workgroup considered a mitigation that puts more
>>> responsibility on the authorization server, and less on the client? For
>>> example, if would be helpful for the writeup to clarify why having the
>>> client send an "audience field" (in the terminology of RFC6819) to the
>>> authorization endpoint would not mitigate the threat. (In that scenario=
,
>>> the authorization server can recognize that the audience does not
>>> correspond to a resource server it knows, rather than asking clients to
>>> make this check). I assume this approach has been considered and reject=
ed
>>> as an incomplete mitigation, but I don't have visibility into where/how
>>> that discussion went.
>>>
>>> Thanks,
>>>
>>> Josh
>>> Hi all,
>>>
>>> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
>>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>>>
>>> Please let us know by Feb 9th whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth
>>> working group.
>>>
>>> Note: This call is related to the announcement made on the list earlier
>>> this month, see
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
>>> time for analysis is provided due to the complexity of the topic.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


When I first heard Nat's proposal in Yokohama I though=
t it was pretty elegant. And remember that it was first proposed to add mor=
e RESTful behavior to OAuth and not just as a mix-up mitigation.

For the mix-up topic, I wonder if this comes down to: if you are a=
lready doing OpenID Connect, the issuer/discovery path feels natural, as th=
at's what you're used to. But if you're pure OAuth, without tho=
se concepts then Nat's solution is more natural?

I d=
o recall some contention in Yokohama around returning the same info twice (=
e.g. returning the token endpoint, and returning a discovery document URL w=
hich could potential reference a different token endpoint).

There's something quite nice about the possibility for =
the AS returning more detailed configuration like the relevant resource ser=
vers where the token can be used =E2=80=93 something that discovery can'=
;t do as it doesn't have the context of the authorization grant.
<=
/div>

On Fri, Jan =
22, 2016 at 6:59 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:=

Ther=
e have been a lot of discussions. I think Hannes posted some minutes of the=
 F2F meeting we had with the security researchers.

The p=
roblem can=E2=80=99t be mitigated without some action on the client side.=
=C2=A0 It boils down to the client making a request to AS1 (From it=E2=80=
=99s perspective) and getting back a response from AS 2 (that it thinks is =
AS1)

This can be done if AS1 is a good AS but has =
it=E2=80=99s logs compromised so that an attacker can read them. Hans Zandb=
elt built a proof of concept for the attack.=C2=A0

In some cases the attacker gets the code and the credential to use it at t=
he good AS token endpoint and in others it just gets the code and can repla=
y that at the client to extract information from the API through the client=
 by binding the api access to a new account.

PKCE =
unfortunately mitigates a different attack, where the client is impersonate=
d and trys to replay a intercepted code.=C2=A0 It however assumes the token=
 endpoint is good, and is no help in the case of a compromised token endpoi=
nt.

The client in these attacks is vulnerable beca=
use it relies on some local state, or the value of the state parameter to k=
now who the response is coming from.=C2=A0 This allows a authorization requ=
est that is intercepted to be used to create a new request in that browser =
to a different AS, or trick the client into using a Authorization endpoint =
for a different authorization server.

One problem =
is that OAuth doesn=E2=80=99t really have a unified concept of what a AS is=
.=C2=A0 Traditionally it is a Authorization endpoint URI, token end point U=
RI and resource server URI that some one gives the client in some documenta=
tion. =C2=A0=C2=A0

As ling as a client only talks =
to one AS then there is no problem. =C2=A0 However once a client is configu=
red to talk to more than one AS, we have problems if one of those AS lies a=
bout it=E2=80=99s endpoints, or is compromised and used to attack another A=
S. =C2=A0 As a design goal you don=E2=80=99t want the overall =C2=A0securit=
y to be limited by the weakest system.

One approac=
h as Nat promotes is to have the authorization endpoint return the next hop=
, token endpoint for code or RS URI for token. The token endpoint must also=
 return the RS URI or the client must push the RS URI to the token endpoint=
 or the attacker just replaces the RS URI in the config and captures the to=
ken that way.=C2=A0

The other way is to provide a =
name for each AS as part of registration and the client not allow duplicate=
 registrations with the same name.=C2=A0 When the response comes back the c=
lient checks the name against the one it made the request to.=C2=A0 If the =
name dereferences to a discovery document then the client can check that na=
me at registration or runtime to validate the net hops.

I think the two approaches mitigate the attack in similar ways.=C2=A0=
 Nat=E2=80=99s is more REST friendly and returns the next hop as a paramete=
r of header. =C2=A0

The one Mike and I wrote up ba=
sed on the meeting in Germany provides identifiers (iss and client_id) that=
 can be checked for validity in the simple case and be dereferenced via .we=
ll-known to get the information Nat=E2=80=99s proposal is providing.
<=
div>
Perhaps the main difference is Nat is using the token en=
dpoint as the identifier for the AS and Mike=E2=80=99s is using location fo=
r a discovery document as the identifier.

I don=E2=
=80=99t recall the reasons using the token endpoint as the identifier was r=
ejected at the meeting.=C2=A0 Perhaps others can post the reasons.

We need to close on this quickly, otherwise if we are inde=
cisive fixes will not go into products for another year or so until this is=
 a RFC.

That is my main concern.

John B.


<=
div>


O=
n Jan 21, 2016, at 11:50 AM, Josh Mandel <jmandel@gmail.com> wrote:

Thanks Nat - that's helpful. If both mitigations *can* work=
 effectively, then I would like to see this group consider the decision bet=
ween them carefully (if that hasn't happened yet). Again, don't hes=
itate to let me know if this is the wrong place/time for such discussion. <=
/p>
At a high level, I would rather ask server developers to =
do some "coding", for two reasons:
1. Most OAut=
h servers talk to many, many clients. So consolidating the security critica=
l work in one place (server) is a net savings of work (rather than asking e=
ach client to implement these checks. 
2. OAuth server de=
velopers are typically more sophisticated than client developers, and there=
fore more likely to understand the implications and more likely to get thes=
e critical details correct. Asking each client developer to do something ri=
ght is likely to result in heterogenius implementation and persistent secur=
ity holes. But if the server does the heavy lifting, and clients just have =
to pass along an extra parameter, this is more likely to see consistent imp=
lementation (for example, clients will fail to work if misconfigured, which=
 will prompt developers to fix them). 


On Jan 21, 2016 09:40, "Nat Sakimura" =
<sakimura@gmail.=
com> wrote:
<=
div dir=3D"ltr">Hi Josh,=C2=A0

It is similar but slightl=
y different IMHO.=C2=A0

Section 4.6.4 of the RFC68=
19 is the access token phishing by a counterfeit resource server.=C2=A0
The mix-up attack described here is the code phishing by a counterfe=
it token endpoint.=C2=A0

In my view, both can be m=
itigated by the server returning the next step: i.e., authorization endpoin=
t returning the legitimate token endpoint uri, and token endpoint returning=
 legitimate resource endpoint uris. This involves no discovery endpoint, wh=
ich is good.=C2=A0

Your way also works. It is just=
 the reverse of my proposal. The difference being that my proposal does not=
 need any coding on the server but just configuration, and it can return mo=
re metadata if needed.=C2=A0

Cheers,=C2=A0

Nat

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel <<=
a href=3D"mailto:jmandel@gmail.com" target=3D"_blank">jmandel@gmail.com=
>:
Apologies if t=
his is the wrong forum for my comment (and please direct me to the appropri=
ate place in that case), but I have two questions about the propose mitigat=
ion (and the thinking behind it) that I think the write-up could address:
1. Could the writeup clarify whether/how the primary "=
;mixup" threat differs from what RFC6819 identifies as in section 4.6.=
4? 
2. Has the workgroup considered a mitigation that put=
s more responsibility on the authorization server, and less on the client? =
For example, if would be helpful for the writeup to clarify why having the =
client send an "audience field" (in the terminology of RFC6819) t=
o the authorization endpoint would not mitigate the threat. (In that scenar=
io, the authorization server can recognize that the audience does not corre=
spond to a resource server it knows, rather than asking clients to make thi=
s check). I assume this approach has been considered and rejected as an inc=
omplete mitigation, but I don't have visibility into where/how that dis=
cussion went. 
Thanks, 
Josh 




https://tools.ietf.org/html/draft-=
jones-oauth-mix-up-mitigation-00



Please let us know by Feb 9th whether you accept / object to the

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

working group.



Note: This call is related to the announcement made on the list earlier

this month, see

http://www.ietf.org/mail-archive/web=
/oauth/current/msg15336.html. More

time for analysis is provided due to the complexity of the topic.



Ciao

Hannes & Derek




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





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

______________________________________________=
_

OAuth mailing list

OAuth@ietf.org

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





--001a113d45d8a8609c0529e18264--


From nobody Thu Jan 21 16:48:06 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04B21B3591 for ; Thu, 21 Jan 2016 16:48:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uf1UBnMlL6Cr for ; Thu, 21 Jan 2016 16:48:00 -0800 (PST)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 55E221B358F for ; Thu, 21 Jan 2016 16:48:00 -0800 (PST)
Received: by mail-qg0-x22f.google.com with SMTP id o11so46328431qge.2 for ; Thu, 21 Jan 2016 16:48:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ToGJZ/qyXmwGyoWXj3GcD7QTBZ/XKmD2Z7/UrSrm18M=; b=PoaXa309jqd2mIVcWpTe5vWysqYCSTsB5zeWRiwnZHbOElGdBa4oil7wi7RNMvhq+M Gr710nfKmal5KDnBUFpML6s37pgCVZO9tH4AAEhk94V0lLhFjCMRPSxIvzcmIBt3P80x zkOeOyPwodkIyKK3PKyJTlJNgk3EBx0UlDp68wkEBmfFSFmjeRVGFjrirFvaasMMGhNE WPDZd3UOxurKxOBpQ+xsOeYALHnpxVG+ATHNRB6yHcnVubx6WIrunY7Qxk8PBJMns4nG Zj/3ol1K/B+nYYsQ65H/Fn2Vs8vegC36HqXoorGueIIMJAzdcECxLzEOn235UHNosdUl Yoyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ToGJZ/qyXmwGyoWXj3GcD7QTBZ/XKmD2Z7/UrSrm18M=; b=QnbmKK4YduHB9wC2/6PynjmeFSEO6K8WPxIVIZ42IklDvfRGcOpfmpmlFS99nooe76 GLVAY0LRMKdHm/Xqj/RUdzfFiS7VBV1h+6DfFk8g+En6eYrIKsRF1vYQic5NJFKg131Q 6X76pCtjrwwUXkwnvUbvfPvJQf9UmxXCNzi7GHtUpyN6A6NcDbYzV4pXJZUJsLM2xHxW SrV8KbjlJFrmuPboYT4m5TwbAeK9ufVJ5afOMt87Vawp0TpEzUs2Gq5YAQASiyne1RBo IUG/ZKv9IPol7piEYOMEC3ahiRmAt0FZOy7Fsku9Y2aEItHl562wepGMSC43Vy/afqth N++g==
X-Gm-Message-State: AG10YOTZVaX8xKvg6Y1U+MStDSKcz149uxaHIZHxad7MIGyFnq4DUYH5FVBWCYv4cyMHbw==
X-Received: by 10.140.216.15 with SMTP id m15mr325899qhb.22.1453423679327; Thu, 21 Jan 2016 16:47:59 -0800 (PST)
Received: from [192.168.8.101] ([181.202.192.227]) by smtp.gmail.com with ESMTPSA id y104sm1712175qgd.33.2016.01.21.16.47.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 16:47:58 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_FAA8757F-CF7A-4465-A264-271AF06E2913"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 21 Jan 2016 21:47:54 -0300
Message-Id: <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.com>
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com> 
To: Nat Sakimura 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 00:48:05 -0000

--Apple-Mail=_FAA8757F-CF7A-4465-A264-271AF06E2913
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_411BE2B6-3B26-4E26-BD47-09E433149DE5"


--Apple-Mail=_411BE2B6-3B26-4E26-BD47-09E433149DE5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I will point out for clarification that this would be like IdP discovery =
in openID 2 that everyone did.  I think IdP not doing RP discovery in =
openID 2 is a weak argument.
There may be other evidence that RP will not do discovery, but if that =
is the case why are we doing a OAuth discovery spec? =20
Many people see your spec as discovery as well just in a different way.

I think both ways can work, but doing both leaves too many options.=20

John B.


> On Jan 21, 2016, at 9:38 PM, Nat Sakimura  wrote:
>=20
> Still doing the analysis. We spent 1.5 hours today with John, George, =
nov and me on the OpenID Connect WG call on this issue. John explained =
the mitigation, but none of us was convinced that it works.=20
>=20
> Then, after the call, I and nov went on with various scenarios. The =
interim conclusion is that:=20
> client_id response parameter does not help. There are legitimate cases =
that client_id duplicates out there and we cannot ban that. =20
> iss response parameter does not help unless the discovery is performed =
and the value of iss is checked against the value of OAuth issuer inside =
the document. (<- Discovery becomes mandatory. =46rom our experience on =
RP discovery step in OpenID 2.0, chance of this being done properly =
seems to be rather slim.)=20
> sending the state to the token endpoint helps in the case code was =
stollen, but code should not be stolen to start with.=20
> Cheers,=20
>=20
> Nat
>=20
>=20
> 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John Bradley =
>:
> There have been a lot of discussions. I think Hannes posted some =
minutes of the F2F meeting we had with the security researchers.
>=20
> The problem can=E2=80=99t be mitigated without some action on the =
client side.  It boils down to the client making a request to AS1 (=46rom =
it=E2=80=99s perspective) and getting back a response from AS 2 (that it =
thinks is AS1)
>=20
> This can be done if AS1 is a good AS but has it=E2=80=99s logs =
compromised so that an attacker can read them. Hans Zandbelt built a =
proof of concept for the attack.=20
>=20
> In some cases the attacker gets the code and the credential to use it =
at the good AS token endpoint and in others it just gets the code and =
can replay that at the client to extract information from the API =
through the client by binding the api access to a new account.
>=20
> PKCE unfortunately mitigates a different attack, where the client is =
impersonated and trys to replay a intercepted code.  It however assumes =
the token endpoint is good, and is no help in the case of a compromised =
token endpoint.
>=20
> The client in these attacks is vulnerable because it relies on some =
local state, or the value of the state parameter to know who the =
response is coming from.  This allows a authorization request that is =
intercepted to be used to create a new request in that browser to a =
different AS, or trick the client into using a Authorization endpoint =
for a different authorization server.
>=20
> One problem is that OAuth doesn=E2=80=99t really have a unified =
concept of what a AS is.  Traditionally it is a Authorization endpoint =
URI, token end point URI and resource server URI that some one gives the =
client in some documentation.  =20
>=20
> As ling as a client only talks to one AS then there is no problem.   =
However once a client is configured to talk to more than one AS, we have =
problems if one of those AS lies about it=E2=80=99s endpoints, or is =
compromised and used to attack another AS.   As a design goal you =
don=E2=80=99t want the overall  security to be limited by the weakest =
system.
>=20
> One approach as Nat promotes is to have the authorization endpoint =
return the next hop, token endpoint for code or RS URI for token. The =
token endpoint must also return the RS URI or the client must push the =
RS URI to the token endpoint or the attacker just replaces the RS URI in =
the config and captures the token that way.=20
>=20
> The other way is to provide a name for each AS as part of registration =
and the client not allow duplicate registrations with the same name.  =
When the response comes back the client checks the name against the one =
it made the request to.  If the name dereferences to a discovery =
document then the client can check that name at registration or runtime =
to validate the net hops.
>=20
> I think the two approaches mitigate the attack in similar ways.  =
Nat=E2=80=99s is more REST friendly and returns the next hop as a =
parameter of header. =20
>=20
> The one Mike and I wrote up based on the meeting in Germany provides =
identifiers (iss and client_id) that can be checked for validity in the =
simple case and be dereferenced via .well-known to get the information =
Nat=E2=80=99s proposal is providing.
>=20
> Perhaps the main difference is Nat is using the token endpoint as the =
identifier for the AS and Mike=E2=80=99s is using location for a =
discovery document as the identifier.
>=20
> I don=E2=80=99t recall the reasons using the token endpoint as the =
identifier was rejected at the meeting.  Perhaps others can post the =
reasons.
>=20
> We need to close on this quickly, otherwise if we are indecisive fixes =
will not go into products for another year or so until this is a RFC.
>=20
> That is my main concern.
>=20
> John B.
>=20
>=20
>=20
>=20
>=20
>> On Jan 21, 2016, at 11:50 AM, Josh Mandel > wrote:
>>=20
>> Thanks Nat - that's helpful. If both mitigations *can* work =
effectively, then I would like to see this group consider the decision =
between them carefully (if that hasn't happened yet). Again, don't =
hesitate to let me know if this is the wrong place/time for such =
discussion.
>>=20
>> At a high level, I would rather ask server developers to do some =
"coding", for two reasons:
>>=20
>> 1. Most OAuth servers talk to many, many clients. So consolidating =
the security critical work in one place (server) is a net savings of =
work (rather than asking each client to implement these checks.
>>=20
>> 2. OAuth server developers are typically more sophisticated than =
client developers, and therefore more likely to understand the =
implications and more likely to get these critical details correct. =
Asking each client developer to do something right is likely to result =
in heterogenius implementation and persistent security holes. But if the =
server does the heavy lifting, and clients just have to pass along an =
extra parameter, this is more likely to see consistent implementation =
(for example, clients will fail to work if misconfigured, which will =
prompt developers to fix them).
>>=20
>> On Jan 21, 2016 09:40, "Nat Sakimura" > wrote:
>> Hi Josh,=20
>>=20
>> It is similar but slightly different IMHO.=20
>>=20
>> Section 4.6.4 of the RFC6819 is the access token phishing by a =
counterfeit resource server.=20
>> The mix-up attack described here is the code phishing by a =
counterfeit token endpoint.=20
>>=20
>> In my view, both can be mitigated by the server returning the next =
step: i.e., authorization endpoint returning the legitimate token =
endpoint uri, and token endpoint returning legitimate resource endpoint =
uris. This involves no discovery endpoint, which is good.=20
>>=20
>> Your way also works. It is just the reverse of my proposal. The =
difference being that my proposal does not need any coding on the server =
but just configuration, and it can return more metadata if needed.=20
>>=20
>> Cheers,=20
>>=20
>> Nat
>>=20
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel =
>:
>> Apologies if this is the wrong forum for my comment (and please =
direct me to the appropriate place in that case), but I have two =
questions about the propose mitigation (and the thinking behind it) that =
I think the write-up could address:
>>=20
>> 1. Could the writeup clarify whether/how the primary "mixup" threat =
differs from what RFC6819 identifies as in section 4.6.4?
>>=20
>> 2. Has the workgroup considered a mitigation that puts more =
responsibility on the authorization server, and less on the client? For =
example, if would be helpful for the writeup to clarify why having the =
client send an "audience field" (in the terminology of RFC6819) to the =
authorization endpoint would not mitigate the threat. (In that scenario, =
the authorization server can recognize that the audience does not =
correspond to a resource server it knows, rather than asking clients to =
make this check). I assume this approach has been considered and =
rejected as an incomplete mitigation, but I don't have visibility into =
where/how that discussion went.
>>=20
>> Thanks,
>>=20
>> Josh=20
>> Hi all,
>>=20
>> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 =

>>=20
>> Please let us know by Feb 9th whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>>=20
>> Note: This call is related to the announcement made on the list =
earlier
>> this month, see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html =
. More
>> time for analysis is provided due to the complexity of the topic.
>>=20
>> Ciao
>> Hannes & Derek
>>=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 =

>=20


--Apple-Mail=_411BE2B6-3B26-4E26-BD47-09E433149DE5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I will point out for clarification that this would be like =
IdP discovery in openID 2 that everyone did.  I think IdP not doing =
RP discovery in openID 2 is a weak argument.
There may be =
other evidence that RP will not do discovery, but if that is the case =
why are we doing a OAuth discovery spec?  
Many =
people see your spec as discovery as well just in a different =
way.

I think =
both ways can work, but doing both leaves too many =
options. 

John B.


On Jan 21, 2016, at 9:38 PM, =
Nat Sakimura <sakimura@gmail.com> wrote:

Still doing the analysis. We spent 1.5 hours today with John, =
George, nov and me on the OpenID Connect WG call on this issue. John =
explained the mitigation, but none of us was convinced that it =
works. 

Then, =
after the call, I and nov went on with various scenarios. The interim =
conclusion is that: 
  • client_id response parameter does not help. There are =
legitimate cases that client_id duplicates out there and we cannot ban =
that.  
  • iss response parameter =
does not help unless the discovery is performed and the value of iss is =
checked against the value of OAuth issuer inside the document. (<- =
Discovery becomes mandatory. =46rom our experience on RP discovery step =
in OpenID 2.0, chance of this being done properly seems to be rather =
slim.) 
  • sending the state to the token endpoint =
helps in the case code was stollen, but code should not be stolen to =
start with. 
Cheers, 

Nat


2016=E5=B9=B41=E6=9C=882=
2=E6=97=A5(=E9=87=91) 7:59 John Bradley <ve7jtb@ve7jtb.com>:
There have been a lot of =
discussions. I think Hannes posted some minutes of the F2F meeting we =
had with the security researchers.

The problem can=E2=80=99t be mitigated =
without some action on the client side.  It boils down to the =
client making a request to AS1 (=46rom it=E2=80=99s perspective) and =
getting back a response from AS 2 (that it thinks is AS1)

This can be done if AS1 =
is a good AS but has it=E2=80=99s logs compromised so that an attacker =
can read them. Hans Zandbelt built a proof of concept for the =
attack. 

In=
 some cases the attacker gets the code and the credential to use it at =
the good AS token endpoint and in others it just gets the code and can =
replay that at the client to extract information from the API through =
the client by binding the api access to a new account.

PKCE unfortunately =
mitigates a different attack, where the client is impersonated and trys =
to replay a intercepted code.  It however assumes the token =
endpoint is good, and is no help in the case of a compromised token =
endpoint.

The =
client in these attacks is vulnerable because it relies on some local =
state, or the value of the state parameter to know who the response is =
coming from.  This allows a authorization request that is =
intercepted to be used to create a new request in that browser to a =
different AS, or trick the client into using a Authorization endpoint =
for a different authorization server.

One problem is that OAuth doesn=E2=80=99t=
 really have a unified concept of what a AS is.  Traditionally it =
is a Authorization endpoint URI, token end point URI and resource server =
URI that some one gives the client in some documentation. =
  

As =
ling as a client only talks to one AS then there is no problem.   =
However once a client is configured to talk to more than one AS, we have =
problems if one of those AS lies about it=E2=80=99s endpoints, or is =
compromised and used to attack another AS.   As a design goal you =
don=E2=80=99t want the overall  security to be limited by the =
weakest system.

One approach as Nat promotes is to have the authorization =
endpoint return the next hop, token endpoint for code or RS URI for =
token. The token endpoint must also return the RS URI or the client must =
push the RS URI to the token endpoint or the attacker just replaces the =
RS URI in the config and captures the token that way. 

The other way is to =
provide a name for each AS as part of registration and the client not =
allow duplicate registrations with the same name.  When the =
response comes back the client checks the name against the one it made =
the request to.  If the name dereferences to a discovery document =
then the client can check that name at registration or runtime to =
validate the net hops.

I think the two approaches mitigate the attack in similar =
ways.  Nat=E2=80=99s is more REST friendly and returns the next hop =
as a parameter of header.  

The one Mike and I wrote up based on =
the meeting in Germany provides identifiers (iss and client_id) that can =
be checked for validity in the simple case and be dereferenced via =
.well-known to get the information Nat=E2=80=99s proposal is =
providing.

Perhaps the main difference is Nat is using the token =
endpoint as the identifier for the AS and Mike=E2=80=99s is using =
location for a discovery document as the identifier.

I don=E2=80=99t recall =
the reasons using the token endpoint as the identifier was rejected at =
the meeting.  Perhaps others can post the reasons.

We need to close on this =
quickly, otherwise if we are indecisive fixes will not go into products =
for another year or so until this is a RFC.

That is my main concern.

John B.





On Jan 21, 2016, at 11:50 AM, Josh Mandel <jmandel@gmail.com> wrote:

Thanks Nat - that's helpful. If =
both mitigations *can* work effectively, then I would like to see this =
group consider the decision between them carefully (if that hasn't =
happened yet). Again, don't hesitate to let me know if this is the wrong =
place/time for such discussion. 
At a high =
level, I would rather ask server developers to do some "coding", for two =
reasons:
1. Most OAuth servers talk to =
many, many clients. So consolidating the security critical work in one =
place (server) is a net savings of work (rather than asking each client =
to implement these checks. 
2. OAuth server =
developers are typically more sophisticated than client developers, and =
therefore more likely to understand the implications and more likely to =
get these critical details correct. Asking each client developer to do =
something right is likely to result in heterogenius implementation and =
persistent security holes. But if the server does the heavy lifting, and =
clients just have to pass along an extra parameter, this is more likely =
to see consistent implementation (for example, clients will fail to work =
if misconfigured, which will prompt developers to fix them). 


On Jan 21, 2016 09:40, "Nat Sakimura" <sakimura@gmail.com> wrote:
Hi Josh, 

It is similar but slightly different IMHO. 

Section 4.6.4 of the =
RFC6819 is the access token phishing by a counterfeit resource =
server. 
The mix-up attack described here is =
the code phishing by a counterfeit token endpoint. 

In my view, both can be =
mitigated by the server returning the next step: i.e., authorization =
endpoint returning the legitimate token endpoint uri, and token endpoint =
returning legitimate resource endpoint uris. This involves no discovery =
endpoint, which is good. 

Your way also works. It is just the =
reverse of my proposal. The difference being that my proposal does not =
need any coding on the server but just configuration, and it can return =
more metadata if needed. 

Cheers, 

Nat

2016=E5=B9=B41=E6=9C=882=
1=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel <jmandel@gmail.com>:
Apologies if this is =
the wrong forum for my comment (and please direct me to the appropriate =
place in that case), but I have two questions about the propose =
mitigation (and the thinking behind it) that I think the write-up could =
address:
1. Could the writeup clarify =
whether/how the primary "mixup" threat differs from what RFC6819 =
identifies as in section 4.6.4? 
2. Has the =
workgroup considered a mitigation that puts more responsibility on the =
authorization server, and less on the client? For example, if would be =
helpful for the writeup to clarify why having the client send an =
"audience field" (in the terminology of RFC6819) to the authorization =
endpoint would not mitigate the threat. (In that scenario, the =
authorization server can recognize that the audience does not correspond =
to a resource server it knows, rather than asking clients to make this =
check). I assume this approach has been considered and rejected as an =
incomplete mitigation, but I don't have visibility into where/how that =
discussion went. 
Thanks, 
Josh 




Hi all,



this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see

https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation=
-00



Please let us know by Feb 9th whether you accept / object to the

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

working group.



Note: This call is related to the announcement made on the list =
earlier

this month, see

http://www.ietf.org/mail-archive/web/oauth/current/msg15336.htm=
l. More

time for analysis is provided due to the complexity of the topic.



Ciao

Hannes & Derek




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





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




=

--Apple-Mail=_411BE2B6-3B26-4E26-BD47-09E433149DE5--

--Apple-Mail=_FAA8757F-CF7A-4465-A264-271AF06E2913
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjIwMDQ3NTRaMCMGCSqGSIb3DQEJBDEWBBSMhgCYN7RLZkSNBJZchIFP
jTXG1DCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAUk1VP0K8ee0QXfRNwitsQPClgezaUbvhrJWpYI6GnZl6j64qow/Cc
bi28ul1ChPPScBs9D5/SmAlRk/Y9g/zav8FKcqTmxG0Sv+CJnWD6oNZCHZlLGAIisTWRm5a3Q9GO
gdcHC/gZEiSM2C6pO1CpHCm8ryKPJcoXliCrUnmaQdTa8o2yB/Q989b8Wq1rOAwz03jE3mIWplF6
39Wl8wsdq9wbqdOcp/gBMBJwiMMXBxWgxYplA5OBsJgpoBT3fPz5l5Ra443KW6g+qFrVwXOlCJdX
M9+EnZPOLXG2cFUoLruDPPHs4BQ5wuCqaoYlM/QJeGIHiBS9t7Sq2HAb2t2QAAAAAAAA
--Apple-Mail=_FAA8757F-CF7A-4465-A264-271AF06E2913--


From nobody Thu Jan 21 16:58:43 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733CB1B2BFC for ; Thu, 21 Jan 2016 16:58:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4azmUTJ2p4Fx for ; Thu, 21 Jan 2016 16:58:38 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25B1F1A88A9 for ; Thu, 21 Jan 2016 16:58:38 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id s68so23238206qkh.3 for ; Thu, 21 Jan 2016 16:58:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=tpFzyN9R3CpC+DTJ0+BNTKPLun64JhEHhCZyb8oVmFE=; b=lK5LI8iaBU1TZ0QBQmT0MRNBO8a3drR4nmY3dADCxgU+MFf6u0rfh6arm5051Ylc5b FYeCLBz4phJMGpJMtUHcYPkWOcZKmzEqNMw+1WFOQsvmRQ4MZiqclMvQtUj7ylfqBaa1 tkT9VCrEP99EVrE4wlw2XjnosAwoRQXnsQlqV6IWFDoUf31NJgqtcPNaGuy9bOFEixMB aXKyIZLgxYjKy2KK2siyglQ/sv/QzeZLjRmHUUNGBiN4Q93Mpzlghs0HnxCbDwn8MeYt Zycvt9P7QL5HGvYNXiBH7VSLzftlmMHlyodDDmP1/1j1zRnON1PXGMSMJdjVp6FsjAoG 2gWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=tpFzyN9R3CpC+DTJ0+BNTKPLun64JhEHhCZyb8oVmFE=; b=BysOhQH/DGj58HV9Old2HtpAz8AcmTDNYlShGKArOHvhqVNFatfEtf92PI+0rKUvYc 6U4sW+GtfyXg1s81YT+/2B6DQff+46/QTxusw+L1CFuTNkO91rRR1A5zmNLx4s9hicSZ GukMuyiCX33X1tFUmyf/3xGXa1zxCTAaRHQlawfouqD+sUqaAGaS7uPxDH3v7o1/Horn BiVbEt+05NyhVb7jELl8Xp29tsU30Geny2286oH7CVSgYhatSM4R4EpAcbwCLtKuwgxK Vb3LGJy6STdvUXret/KrG4CbY81LDS80akTM4M7zb5TXdY8SlLK1lTuenhSXwKJ+oVYp p2Pg==
X-Gm-Message-State: AG10YOT+Q7zwWTC6QtQB66VOQ7HtcITC4NTWaBCNJ1iWBzLFusni/DiH0XtgaXhK7DHnxH5wMVc8l6c2Hzgjrw==
X-Received: by 10.55.71.135 with SMTP id u129mr367075qka.26.1453424317293; Thu, 21 Jan 2016 16:58:37 -0800 (PST)
MIME-Version: 1.0
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.com>
In-Reply-To: <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.com>
From: Nat Sakimura 
Date: Fri, 22 Jan 2016 00:58:27 +0000
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=001a114a7d2023f2e60529e1b8c7
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 00:58:42 -0000

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

The point is, the idea of making discovery mandatory even if the authz
server is currently not doing it but giving info through developer
documentation, does not sound likely to fly.

2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 9:47 John Bradley :

> I will point out for clarification that this would be like IdP discovery
> in openID 2 that everyone did.  I think IdP not doing RP discovery in
> openID 2 is a weak argument.
> There may be other evidence that RP will not do discovery, but if that is
> the case why are we doing a OAuth discovery spec?
> Many people see your spec as discovery as well just in a different way.
>
> I think both ways can work, but doing both leaves too many options.
>
> John B.
>
>
> On Jan 21, 2016, at 9:38 PM, Nat Sakimura  wrote:
>
> Still doing the analysis. We spent 1.5 hours today with John, George, nov
> and me on the OpenID Connect WG call on this issue. John explained the
> mitigation, but none of us was convinced that it works.
>
> Then, after the call, I and nov went on with various scenarios. The
> interim conclusion is that:
>
>    - client_id response parameter does not help. There are legitimate
>    cases that client_id duplicates out there and we cannot ban that.
>    - iss response parameter does not help unless the discovery is
>    performed and the value of iss is checked against the value of OAuth i=
ssuer
>    inside the document. (<- Discovery becomes mandatory. From our experie=
nce
>    on RP discovery step in OpenID 2.0, chance of this being done properly
>    seems to be rather slim.)
>    - sending the state to the token endpoint helps in the case code was
>    stollen, but code should not be stolen to start with.
>
> Cheers,
>
> Nat
>
>
> 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John Bradley :
>
>> There have been a lot of discussions. I think Hannes posted some minutes
>> of the F2F meeting we had with the security researchers.
>>
>> The problem can=E2=80=99t be mitigated without some action on the client=
 side.
>> It boils down to the client making a request to AS1 (From it=E2=80=99s p=
erspective)
>> and getting back a response from AS 2 (that it thinks is AS1)
>>
>> This can be done if AS1 is a good AS but has it=E2=80=99s logs compromis=
ed so
>> that an attacker can read them. Hans Zandbelt built a proof of concept f=
or
>> the attack.
>>
>> In some cases the attacker gets the code and the credential to use it at
>> the good AS token endpoint and in others it just gets the code and can
>> replay that at the client to extract information from the API through th=
e
>> client by binding the api access to a new account.
>>
>> PKCE unfortunately mitigates a different attack, where the client is
>> impersonated and trys to replay a intercepted code.  It however assumes =
the
>> token endpoint is good, and is no help in the case of a compromised toke=
n
>> endpoint.
>>
>> The client in these attacks is vulnerable because it relies on some loca=
l
>> state, or the value of the state parameter to know who the response is
>> coming from.  This allows a authorization request that is intercepted to=
 be
>> used to create a new request in that browser to a different AS, or trick
>> the client into using a Authorization endpoint for a different
>> authorization server.
>>
>> One problem is that OAuth doesn=E2=80=99t really have a unified concept =
of what a
>> AS is.  Traditionally it is a Authorization endpoint URI, token end poin=
t
>> URI and resource server URI that some one gives the client in some
>> documentation.
>>
>> As ling as a client only talks to one AS then there is no problem.
>> However once a client is configured to talk to more than one AS, we have
>> problems if one of those AS lies about it=E2=80=99s endpoints, or is com=
promised
>> and used to attack another AS.   As a design goal you don=E2=80=99t want=
 the
>> overall  security to be limited by the weakest system.
>>
>> One approach as Nat promotes is to have the authorization endpoint retur=
n
>> the next hop, token endpoint for code or RS URI for token. The token
>> endpoint must also return the RS URI or the client must push the RS URI =
to
>> the token endpoint or the attacker just replaces the RS URI in the confi=
g
>> and captures the token that way.
>>
>> The other way is to provide a name for each AS as part of registration
>> and the client not allow duplicate registrations with the same name.  Wh=
en
>> the response comes back the client checks the name against the one it ma=
de
>> the request to.  If the name dereferences to a discovery document then t=
he
>> client can check that name at registration or runtime to validate the ne=
t
>> hops.
>>
>> I think the two approaches mitigate the attack in similar ways.  Nat=E2=
=80=99s is
>> more REST friendly and returns the next hop as a parameter of header.
>>
>> The one Mike and I wrote up based on the meeting in Germany provides
>> identifiers (iss and client_id) that can be checked for validity in the
>> simple case and be dereferenced via .well-known to get the information
>> Nat=E2=80=99s proposal is providing.
>>
>> Perhaps the main difference is Nat is using the token endpoint as the
>> identifier for the AS and Mike=E2=80=99s is using location for a discove=
ry document
>> as the identifier.
>>
>> I don=E2=80=99t recall the reasons using the token endpoint as the ident=
ifier was
>> rejected at the meeting.  Perhaps others can post the reasons.
>>
>> We need to close on this quickly, otherwise if we are indecisive fixes
>> will not go into products for another year or so until this is a RFC.
>>
>> That is my main concern.
>>
>> John B.
>>
>>
>>
>>
>>
>> On Jan 21, 2016, at 11:50 AM, Josh Mandel  wrote:
>>
>> Thanks Nat - that's helpful. If both mitigations *can* work effectively,
>> then I would like to see this group consider the decision between them
>> carefully (if that hasn't happened yet). Again, don't hesitate to let me
>> know if this is the wrong place/time for such discussion.
>>
>> At a high level, I would rather ask server developers to do some
>> "coding", for two reasons:
>>
>> 1. Most OAuth servers talk to many, many clients. So consolidating the
>> security critical work in one place (server) is a net savings of work
>> (rather than asking each client to implement these checks.
>>
>> 2. OAuth server developers are typically more sophisticated than client
>> developers, and therefore more likely to understand the implications and
>> more likely to get these critical details correct. Asking each client
>> developer to do something right is likely to result in heterogenius
>> implementation and persistent security holes. But if the server does the
>> heavy lifting, and clients just have to pass along an extra parameter, t=
his
>> is more likely to see consistent implementation (for example, clients wi=
ll
>> fail to work if misconfigured, which will prompt developers to fix them)=
.
>> On Jan 21, 2016 09:40, "Nat Sakimura"  wrote:
>>
>>> Hi Josh,
>>>
>>> It is similar but slightly different IMHO.
>>>
>>> Section 4.6.4 of the RFC6819 is the access token phishing by a
>>> counterfeit resource server.
>>> The mix-up attack described here is the code phishing by a counterfeit
>>> token endpoint.
>>>
>>> In my view, both can be mitigated by the server returning the next step=
:
>>> i.e., authorization endpoint returning the legitimate token endpoint ur=
i,
>>> and token endpoint returning legitimate resource endpoint uris. This
>>> involves no discovery endpoint, which is good.
>>>
>>> Your way also works. It is just the reverse of my proposal. The
>>> difference being that my proposal does not need any coding on the serve=
r
>>> but just configuration, and it can return more metadata if needed.
>>>
>>> Cheers,
>>>
>>> Nat
>>>
>>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel :
>>>
>>>> Apologies if this is the wrong forum for my comment (and please direct
>>>> me to the appropriate place in that case), but I have two questions ab=
out
>>>> the propose mitigation (and the thinking behind it) that I think the
>>>> write-up could address:
>>>>
>>>> 1. Could the writeup clarify whether/how the primary "mixup" threat
>>>> differs from what RFC6819 identifies as in section 4.6.4?
>>>>
>>>> 2. Has the workgroup considered a mitigation that puts more
>>>> responsibility on the authorization server, and less on the client? Fo=
r
>>>> example, if would be helpful for the writeup to clarify why having the
>>>> client send an "audience field" (in the terminology of RFC6819) to the
>>>> authorization endpoint would not mitigate the threat. (In that scenari=
o,
>>>> the authorization server can recognize that the audience does not
>>>> correspond to a resource server it knows, rather than asking clients t=
o
>>>> make this check). I assume this approach has been considered and rejec=
ted
>>>> as an incomplete mitigation, but I don't have visibility into where/ho=
w
>>>> that discussion went.
>>>>
>>>> Thanks,
>>>>
>>>> Josh
>>>> Hi all,
>>>>
>>>> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
>>>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>>>>
>>>> Please let us know by Feb 9th whether you accept / object to the
>>>> adoption of this document as a starting point for work in the OAuth
>>>> working group.
>>>>
>>>> Note: This call is related to the announcement made on the list earlie=
r
>>>> this month, see
>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
>>>> time for analysis is provided due to the complexity of the topic.
>>>>
>>>> Ciao
>>>> Hannes & Derek
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>

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


The point is, the idea of making discovery mandatory even =
if the authz server is currently not doing it but giving info through devel=
oper documentation, does not sound likely to fly.=C2=A0

2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=
=91) 9:47 John Bradley <ve7jtb@ve7j=
tb.com>:
I will point out for clarification that this would be like=
 IdP discovery in openID 2 that everyone did.=C2=A0 I think IdP not doing R=
P discovery in openID 2 is a weak argument.
There may be other evidence=
 that RP will not do discovery, but if that is the case why are we doing a =
OAuth discovery spec? =C2=A0
Many people see your spec as discove=
ry as well just in a different way.

I think both w=
ays can work, but doing both leaves too many options.=C2=A0

<=
/div>
John B.
=


On Jan 21, 2016, at =
9:38 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Sti=
ll doing the analysis. We spent 1.5 hours today with John, George, nov and =
me on the OpenID Connect WG call on this issue. John explained the mitigati=
on, but none of us was convinced that it works.=C2=A0

Th=
en, after the call, I and nov went on with various scenarios. The interim c=
onclusion is that:=C2=A0
  • client_id response parameter does not help. There are legitimat=
e cases that client_id duplicates out there and we cannot ban that. =C2=A0<=
br>
  • iss response parameter does not help unless the discovery is pe=
rformed and the value of iss is checked against the value of OAuth issuer i=
nside the document. (<- Discovery becomes mandatory. From our experience=
 on RP discovery step in OpenID 2.0, chance of this being done properly see=
ms to be rather slim.)=C2=A0
  • sending the state to the token endpoin=
t helps in the case code was stollen, but code should not be stolen to star=
t with.=C2=A0
Cheers,=C2=A0

Na=
t


=
2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John Bradley <ve7jtb@ve7jtb.com>:<=
br>
There have been a lot of discussions. I t=
hink Hannes posted some minutes of the F2F meeting we had with the security=
 researchers.

The problem can=E2=80=99t be mitigated wit=
hout some action on the client side.=C2=A0 It boils down to the client maki=
ng a request to AS1 (From it=E2=80=99s perspective) and getting back a resp=
onse from AS 2 (that it thinks is AS1)

This can be=
 done if AS1 is a good AS but has it=E2=80=99s logs compromised so that an =
attacker can read them. Hans Zandbelt built a proof of concept for the atta=
ck.=C2=A0

In some cases the attacker gets the code=
 and the credential to use it at the good AS token endpoint and in others i=
t just gets the code and can replay that at the client to extract informati=
on from the API through the client by binding the api access to a new accou=
nt.

PKCE unfortunately mitigates a different attac=
k, where the client is impersonated and trys to replay a intercepted code.=
=C2=A0 It however assumes the token endpoint is good, and is no help in the=
 case of a compromised token endpoint.

The client =
in these attacks is vulnerable because it relies on some local state, or th=
e value of the state parameter to know who the response is coming from.=C2=
=A0 This allows a authorization request that is intercepted to be used to c=
reate a new request in that browser to a different AS, or trick the client =
into using a Authorization endpoint for a different authorization server.

One problem is that OAuth doesn=E2=80=99t really ha=
ve a unified concept of what a AS is.=C2=A0 Traditionally it is a Authoriza=
tion endpoint URI, token end point URI and resource server URI that some on=
e gives the client in some documentation. =C2=A0=C2=A0

=

As ling as a client only talks to one AS then there is no problem. =C2=
=A0 However once a client is configured to talk to more than one AS, we hav=
e problems if one of those AS lies about it=E2=80=99s endpoints, or is comp=
romised and used to attack another AS. =C2=A0 As a design goal you don=E2=
=80=99t want the overall =C2=A0security to be limited by the weakest system=
.

One approach as Nat promotes is to have the auth=
orization endpoint return the next hop, token endpoint for code or RS URI f=
or token. The token endpoint must also return the RS URI or the client must=
 push the RS URI to the token endpoint or the attacker just replaces the RS=
 URI in the config and captures the token that way.=C2=A0

The other way is to provide a name for each AS as part of registrat=
ion and the client not allow duplicate registrations with the same name.=C2=
=A0 When the response comes back the client checks the name against the one=
 it made the request to.=C2=A0 If the name dereferences to a discovery docu=
ment then the client can check that name at registration or runtime to vali=
date the net hops.

I think the two approaches miti=
gate the attack in similar ways.=C2=A0 Nat=E2=80=99s is more REST friendly =
and returns the next hop as a parameter of header. =C2=A0

The one Mike and I wrote up based on the meeting in Germany provide=
s identifiers (iss and client_id) that can be checked for validity in the s=
imple case and be dereferenced via .well-known to get the information Nat=
=E2=80=99s proposal is providing.

Perhaps the main=
 difference is Nat is using the token endpoint as the identifier for the AS=
 and Mike=E2=80=99s is using location for a discovery document as the ident=
ifier.

I don=E2=80=99t recall the reasons using th=
e token endpoint as the identifier was rejected at the meeting.=C2=A0 Perha=
ps others can post the reasons.

We need to close o=
n this quickly, otherwise if we are indecisive fixes will not go into produ=
cts for another year or so until this is a RFC.

Th=
at is my main concern.

John B.





On Jan 21, 2016, =
at 11:50 AM, Josh Mandel <jmandel@gmail.com> wrote:

Than=
ks Nat - that's helpful. If both mitigations *can* work effectively, th=
en I would like to see this group consider the decision between them carefu=
lly (if that hasn't happened yet). Again, don't hesitate to let me =
know if this is the wrong place/time for such discussion. 
At a high level, I would rather ask server developers to do some "co=
ding", for two reasons:
1. Most OAuth servers talk t=
o many, many clients. So consolidating the security critical work in one pl=
ace (server) is a net savings of work (rather than asking each client to im=
plement these checks. 
2. OAuth server developers are typ=
ically more sophisticated than client developers, and therefore more likely=
 to understand the implications and more likely to get these critical detai=
ls correct. Asking each client developer to do something right is likely to=
 result in heterogenius implementation and persistent security holes. But i=
f the server does the heavy lifting, and clients just have to pass along an=
 extra parameter, this is more likely to see consistent implementation (for=
 example, clients will fail to work if misconfigured, which will prompt dev=
elopers to fix them). 


On Jan 21, 2016 09:40, "Nat Sakimura" =
<sakimura@gmail.=
com> wrote:
<=
div dir=3D"ltr">Hi Josh,=C2=A0

It is similar but slightl=
y different IMHO.=C2=A0

Section 4.6.4 of the RFC68=
19 is the access token phishing by a counterfeit resource server.=C2=A0
The mix-up attack described here is the code phishing by a counterfe=
it token endpoint.=C2=A0

In my view, both can be m=
itigated by the server returning the next step: i.e., authorization endpoin=
t returning the legitimate token endpoint uri, and token endpoint returning=
 legitimate resource endpoint uris. This involves no discovery endpoint, wh=
ich is good.=C2=A0

Your way also works. It is just=
 the reverse of my proposal. The difference being that my proposal does not=
 need any coding on the server but just configuration, and it can return mo=
re metadata if needed.=C2=A0

Cheers,=C2=A0

Nat

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel <<=
a href=3D"mailto:jmandel@gmail.com" target=3D"_blank">jmandel@gmail.com=
>:
Apologies if t=
his is the wrong forum for my comment (and please direct me to the appropri=
ate place in that case), but I have two questions about the propose mitigat=
ion (and the thinking behind it) that I think the write-up could address:
1. Could the writeup clarify whether/how the primary "=
;mixup" threat differs from what RFC6819 identifies as in section 4.6.=
4? 
2. Has the workgroup considered a mitigation that put=
s more responsibility on the authorization server, and less on the client? =
For example, if would be helpful for the writeup to clarify why having the =
client send an "audience field" (in the terminology of RFC6819) t=
o the authorization endpoint would not mitigate the threat. (In that scenar=
io, the authorization server can recognize that the audience does not corre=
spond to a resource server it knows, rather than asking clients to make thi=
s check). I assume this approach has been considered and rejected as an inc=
omplete mitigation, but I don't have visibility into where/how that dis=
cussion went. 
Thanks, 
Josh 




https://tools.ietf.org/html/draft-=
jones-oauth-mix-up-mitigation-00



Please let us know by Feb 9th whether you accept / object to the

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

working group.



Note: This call is related to the announcement made on the list earlier

this month, see

http://www.ietf.org/mail-archive/web=
/oauth/current/msg15336.html. More

time for analysis is provided due to the complexity of the topic.



Ciao

Hannes & Derek




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





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





--001a114a7d2023f2e60529e1b8c7--


From nobody Thu Jan 21 16:59:01 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D881B35A7 for ; Thu, 21 Jan 2016 16:58:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdzB8AdB9dDj for ; Thu, 21 Jan 2016 16:58:50 -0800 (PST)
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 2A1AC1B35A1 for ; Thu, 21 Jan 2016 16:58:50 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id s5so23281976qkd.0 for ; Thu, 21 Jan 2016 16:58:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=A+4jCiFfiBpkwCoZfW+gCVcYsneGSf2soPtQZ5+jDT4=; b=bZ7vxVWA51Ces/WesO6h6AW0Wo3VaPdoNZWiCNCGGtpkuq5Na2WV+JG0GF/MRSuumK fSr5HkLxWNTTednNlv9GlTeIxiUdZGEBGA5PMt68OPNcMcunFnmK73eTe4nVG96oySBo 3Dw1nC9xGLr4LwUSoV5JyDYxi0XUbsrXZtiXnpuFpAlxAPoc1ixsEDfvTwPcLfrcvtBc GNJe3vQTLwep9l4peFYb1wSEoruZpIevmrfd+zK4o0mLza20x5g0O2sgWaT+05lbB8zw JFfhXgQ5CH/7HWHJTLJiRLV9fKE85h4H8NNtp/T332YLQL1XXAnAtCsEGQ9gLscf2C0w of5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=A+4jCiFfiBpkwCoZfW+gCVcYsneGSf2soPtQZ5+jDT4=; b=EHReHRdjgCk7uuV3DyKyJBx10125RpPMhytI3tWUfepkfVfY98lrtRof75nKo5KR61 FzWYRxRN0n+El7L0P9Y1e4HpitbhF8LoKzpkR+ebK7zpIjBQvOW5qd4zTnKhDFA/S4NH A5n9nDMfM5Eo9Igr3VNxoNaizYm1G5U+Cao7VcCu3jATG6SWNDePCoFeLKjHcOCpsuub P/baz7uyQjhf8Z288a3SpA8ipr15ffZO7mnK9Lf51hmox9S5tNj7jZA8eME3VikS3zGH SLvrqNDGKpTFMBieIxbqYgPVvCqHDjjW4ai7tQTJBV73Hz5lhX1Nt8Y2+bsBAAmLgKLI SQZg==
X-Gm-Message-State: AG10YOS1kzDwXgWcKB9xP8+HmfUsTlrhoV8P11LtE9Tn14ZPCkH27FkKyo1870s+um4DXg==
X-Received: by 10.55.75.144 with SMTP id y138mr333133qka.96.1453424329161; Thu, 21 Jan 2016 16:58:49 -0800 (PST)
Received: from [192.168.8.101] ([181.202.192.227]) by smtp.gmail.com with ESMTPSA id t187sm1723854qht.39.2016.01.21.16.58.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Jan 2016 16:58:48 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_BF366EBF-2F81-45CC-AF9F-1938DD9A7296"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 21 Jan 2016 21:58:44 -0300
Message-Id: <617BF715-85E3-46F1-B928-68FC176BCDBC@ve7jtb.com>
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com> 
To: William Denniss 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 00:58:57 -0000

--Apple-Mail=_BF366EBF-2F81-45CC-AF9F-1938DD9A7296
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_35305734-62AC-486A-B0BC-BFA8696B8AA0"


--Apple-Mail=_35305734-62AC-486A-B0BC-BFA8696B8AA0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I will point out for the benefit of the people on the the list who were =
not at the F2F in Germany, that Mike and I were asked to write up the =
consensus of the group.

We have done that.=20

The work group is free to adopt it or modify it.  =20

Brian and others raised issues about how accurately we reflected the =
consensus in the first draft.  I think that is mostly resolved.   We =
should continue refining that if needed.

Separately the work group needs to consider other proposals do come to a =
Work Group consensus rather than a meeting consensus.

My main concern is coming to that consensus quickly.    We do have =
people who have implemented the mitigations in the spec Mike and I did.

Perhaps we should also document Nat=E2=80=99s proposal so it can be =
tested as well.

John B.

> On Jan 21, 2016, at 9:43 PM, William Denniss  =
wrote:
>=20
> When I first heard Nat's proposal in Yokohama I thought it was pretty =
elegant. And remember that it was first proposed to add more RESTful =
behavior to OAuth and not just as a mix-up mitigation.
>=20
> For the mix-up topic, I wonder if this comes down to: if you are =
already doing OpenID Connect, the issuer/discovery path feels natural, =
as that's what you're used to. But if you're pure OAuth, without those =
concepts then Nat's solution is more natural?
>=20
> I do recall some contention in Yokohama around returning the same info =
twice (e.g. returning the token endpoint, and returning a discovery =
document URL which could potential reference a different token =
endpoint).
>=20
> There's something quite nice about the possibility for the AS =
returning more detailed configuration like the relevant resource servers =
where the token can be used =E2=80=93 something that discovery can't do =
as it doesn't have the context of the authorization grant.
>=20
> On Fri, Jan 22, 2016 at 6:59 AM, John Bradley > wrote:
> There have been a lot of discussions. I think Hannes posted some =
minutes of the F2F meeting we had with the security researchers.
>=20
> The problem can=E2=80=99t be mitigated without some action on the =
client side.  It boils down to the client making a request to AS1 (=46rom =
it=E2=80=99s perspective) and getting back a response from AS 2 (that it =
thinks is AS1)
>=20
> This can be done if AS1 is a good AS but has it=E2=80=99s logs =
compromised so that an attacker can read them. Hans Zandbelt built a =
proof of concept for the attack.=20
>=20
> In some cases the attacker gets the code and the credential to use it =
at the good AS token endpoint and in others it just gets the code and =
can replay that at the client to extract information from the API =
through the client by binding the api access to a new account.
>=20
> PKCE unfortunately mitigates a different attack, where the client is =
impersonated and trys to replay a intercepted code.  It however assumes =
the token endpoint is good, and is no help in the case of a compromised =
token endpoint.
>=20
> The client in these attacks is vulnerable because it relies on some =
local state, or the value of the state parameter to know who the =
response is coming from.  This allows a authorization request that is =
intercepted to be used to create a new request in that browser to a =
different AS, or trick the client into using a Authorization endpoint =
for a different authorization server.
>=20
> One problem is that OAuth doesn=E2=80=99t really have a unified =
concept of what a AS is.  Traditionally it is a Authorization endpoint =
URI, token end point URI and resource server URI that some one gives the =
client in some documentation.  =20
>=20
> As ling as a client only talks to one AS then there is no problem.   =
However once a client is configured to talk to more than one AS, we have =
problems if one of those AS lies about it=E2=80=99s endpoints, or is =
compromised and used to attack another AS.   As a design goal you =
don=E2=80=99t want the overall  security to be limited by the weakest =
system.
>=20
> One approach as Nat promotes is to have the authorization endpoint =
return the next hop, token endpoint for code or RS URI for token. The =
token endpoint must also return the RS URI or the client must push the =
RS URI to the token endpoint or the attacker just replaces the RS URI in =
the config and captures the token that way.=20
>=20
> The other way is to provide a name for each AS as part of registration =
and the client not allow duplicate registrations with the same name.  =
When the response comes back the client checks the name against the one =
it made the request to.  If the name dereferences to a discovery =
document then the client can check that name at registration or runtime =
to validate the net hops.
>=20
> I think the two approaches mitigate the attack in similar ways.  =
Nat=E2=80=99s is more REST friendly and returns the next hop as a =
parameter of header. =20
>=20
> The one Mike and I wrote up based on the meeting in Germany provides =
identifiers (iss and client_id) that can be checked for validity in the =
simple case and be dereferenced via .well-known to get the information =
Nat=E2=80=99s proposal is providing.
>=20
> Perhaps the main difference is Nat is using the token endpoint as the =
identifier for the AS and Mike=E2=80=99s is using location for a =
discovery document as the identifier.
>=20
> I don=E2=80=99t recall the reasons using the token endpoint as the =
identifier was rejected at the meeting.  Perhaps others can post the =
reasons.
>=20
> We need to close on this quickly, otherwise if we are indecisive fixes =
will not go into products for another year or so until this is a RFC.
>=20
> That is my main concern.
>=20
> John B.
>=20
>=20
>=20
>=20
>=20
>> On Jan 21, 2016, at 11:50 AM, Josh Mandel > wrote:
>>=20
>> Thanks Nat - that's helpful. If both mitigations *can* work =
effectively, then I would like to see this group consider the decision =
between them carefully (if that hasn't happened yet). Again, don't =
hesitate to let me know if this is the wrong place/time for such =
discussion.
>>=20
>> At a high level, I would rather ask server developers to do some =
"coding", for two reasons:
>>=20
>> 1. Most OAuth servers talk to many, many clients. So consolidating =
the security critical work in one place (server) is a net savings of =
work (rather than asking each client to implement these checks.
>>=20
>> 2. OAuth server developers are typically more sophisticated than =
client developers, and therefore more likely to understand the =
implications and more likely to get these critical details correct. =
Asking each client developer to do something right is likely to result =
in heterogenius implementation and persistent security holes. But if the =
server does the heavy lifting, and clients just have to pass along an =
extra parameter, this is more likely to see consistent implementation =
(for example, clients will fail to work if misconfigured, which will =
prompt developers to fix them).
>>=20
>> On Jan 21, 2016 09:40, "Nat Sakimura" > wrote:
>> Hi Josh,=20
>>=20
>> It is similar but slightly different IMHO.=20
>>=20
>> Section 4.6.4 of the RFC6819 is the access token phishing by a =
counterfeit resource server.=20
>> The mix-up attack described here is the code phishing by a =
counterfeit token endpoint.=20
>>=20
>> In my view, both can be mitigated by the server returning the next =
step: i.e., authorization endpoint returning the legitimate token =
endpoint uri, and token endpoint returning legitimate resource endpoint =
uris. This involves no discovery endpoint, which is good.=20
>>=20
>> Your way also works. It is just the reverse of my proposal. The =
difference being that my proposal does not need any coding on the server =
but just configuration, and it can return more metadata if needed.=20
>>=20
>> Cheers,=20
>>=20
>> Nat
>>=20
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel =
>:
>> Apologies if this is the wrong forum for my comment (and please =
direct me to the appropriate place in that case), but I have two =
questions about the propose mitigation (and the thinking behind it) that =
I think the write-up could address:
>>=20
>> 1. Could the writeup clarify whether/how the primary "mixup" threat =
differs from what RFC6819 identifies as in section 4.6.4?
>>=20
>> 2. Has the workgroup considered a mitigation that puts more =
responsibility on the authorization server, and less on the client? For =
example, if would be helpful for the writeup to clarify why having the =
client send an "audience field" (in the terminology of RFC6819) to the =
authorization endpoint would not mitigate the threat. (In that scenario, =
the authorization server can recognize that the audience does not =
correspond to a resource server it knows, rather than asking clients to =
make this check). I assume this approach has been considered and =
rejected as an incomplete mitigation, but I don't have visibility into =
where/how that discussion went.
>>=20
>> Thanks,
>>=20
>> Josh=20
>> Hi all,
>>=20
>> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 =

>>=20
>> Please let us know by Feb 9th whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>>=20
>> Note: This call is related to the announcement made on the list =
earlier
>> this month, see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html =
. More
>> time for analysis is provided due to the complexity of the topic.
>>=20
>> Ciao
>> Hannes & Derek
>>=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 =

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

>=20
>=20


--Apple-Mail=_35305734-62AC-486A-B0BC-BFA8696B8AA0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I will point out for the benefit of the people on the the =
list who were not at the F2F in Germany, that Mike and I were asked to =
write up the consensus of the group.

We have done that. 

The work group is free =
to adopt it or modify it.   

Brian and others raised issues about =
how accurately we reflected the consensus in the first draft.  I =
think that is mostly resolved.   We should continue refining that =
if needed.

Separately the work group needs to consider other proposals =
do come to a Work Group consensus rather than a meeting =
consensus.

My =
main concern is coming to that consensus quickly.    We do =
have people who have implemented the mitigations in the spec Mike and I =
did.

Perhaps =
we should also document Nat=E2=80=99s proposal so it can be tested as =
well.

John =
B.

On Jan 21, 2016, at 9:43 PM, =
William Denniss <wdenniss@google.com> wrote:

When I first heard Nat's proposal in Yokohama I thought it =
was pretty elegant. And remember that it was first proposed to add more =
RESTful behavior to OAuth and not just as a mix-up mitigation.

For the mix-up topic, I =
wonder if this comes down to: if you are already doing OpenID Connect, =
the issuer/discovery path feels natural, as that's what you're used to. =
But if you're pure OAuth, without those concepts then Nat's solution is =
more natural?

I do =
recall some contention in Yokohama around returning the same info twice =
(e.g. returning the token endpoint, and returning a discovery document =
URL which could potential reference a different token =
endpoint).

There's something quite nice about the possibility for the AS =
returning more detailed configuration like the relevant resource servers =
where the token can be used =E2=80=93 something that discovery can't do =
as it doesn't have the context of the authorization =
grant.

On Fri, Jan 22, 2016 at 6:59 AM, John Bradley =
<ve7jtb@ve7jtb.com> wrote:
There have been a lot of =
discussions. I think Hannes posted some minutes of the F2F meeting we =
had with the security researchers.

The problem can=E2=80=99t be mitigated =
without some action on the client side.  It boils down to the =
client making a request to AS1 (=46rom it=E2=80=99s perspective) and =
getting back a response from AS 2 (that it thinks is AS1)

This can be done if AS1 =
is a good AS but has it=E2=80=99s logs compromised so that an attacker =
can read them. Hans Zandbelt built a proof of concept for the =
attack. 

In=
 some cases the attacker gets the code and the credential to use it at =
the good AS token endpoint and in others it just gets the code and can =
replay that at the client to extract information from the API through =
the client by binding the api access to a new account.

PKCE unfortunately =
mitigates a different attack, where the client is impersonated and trys =
to replay a intercepted code.  It however assumes the token =
endpoint is good, and is no help in the case of a compromised token =
endpoint.

The =
client in these attacks is vulnerable because it relies on some local =
state, or the value of the state parameter to know who the response is =
coming from.  This allows a authorization request that is =
intercepted to be used to create a new request in that browser to a =
different AS, or trick the client into using a Authorization endpoint =
for a different authorization server.

One problem is that OAuth doesn=E2=80=99t=
 really have a unified concept of what a AS is.  Traditionally it =
is a Authorization endpoint URI, token end point URI and resource server =
URI that some one gives the client in some documentation. =
  

As =
ling as a client only talks to one AS then there is no problem.   =
However once a client is configured to talk to more than one AS, we have =
problems if one of those AS lies about it=E2=80=99s endpoints, or is =
compromised and used to attack another AS.   As a design goal you =
don=E2=80=99t want the overall  security to be limited by the =
weakest system.

One approach as Nat promotes is to have the authorization =
endpoint return the next hop, token endpoint for code or RS URI for =
token. The token endpoint must also return the RS URI or the client must =
push the RS URI to the token endpoint or the attacker just replaces the =
RS URI in the config and captures the token that way. 

The other way is to =
provide a name for each AS as part of registration and the client not =
allow duplicate registrations with the same name.  When the =
response comes back the client checks the name against the one it made =
the request to.  If the name dereferences to a discovery document =
then the client can check that name at registration or runtime to =
validate the net hops.

I think the two approaches mitigate the attack in similar =
ways.  Nat=E2=80=99s is more REST friendly and returns the next hop =
as a parameter of header.  

The one Mike and I wrote up based on =
the meeting in Germany provides identifiers (iss and client_id) that can =
be checked for validity in the simple case and be dereferenced via =
.well-known to get the information Nat=E2=80=99s proposal is =
providing.

Perhaps the main difference is Nat is using the token =
endpoint as the identifier for the AS and Mike=E2=80=99s is using =
location for a discovery document as the identifier.

I don=E2=80=99t recall =
the reasons using the token endpoint as the identifier was rejected at =
the meeting.  Perhaps others can post the reasons.

We need to close on this =
quickly, otherwise if we are indecisive fixes will not go into products =
for another year or so until this is a RFC.

That is my main concern.

John B.





On Jan =
21, 2016, at 11:50 AM, Josh Mandel <jmandel@gmail.com> wrote:

Thanks Nat - that's helpful. If =
both mitigations *can* work effectively, then I would like to see this =
group consider the decision between them carefully (if that hasn't =
happened yet). Again, don't hesitate to let me know if this is the wrong =
place/time for such discussion. 
At a high =
level, I would rather ask server developers to do some "coding", for two =
reasons:
1. Most OAuth servers talk to =
many, many clients. So consolidating the security critical work in one =
place (server) is a net savings of work (rather than asking each client =
to implement these checks. 
2. OAuth server =
developers are typically more sophisticated than client developers, and =
therefore more likely to understand the implications and more likely to =
get these critical details correct. Asking each client developer to do =
something right is likely to result in heterogenius implementation and =
persistent security holes. But if the server does the heavy lifting, and =
clients just have to pass along an extra parameter, this is more likely =
to see consistent implementation (for example, clients will fail to work =
if misconfigured, which will prompt developers to fix them). 


On Jan 21, 2016 09:40, "Nat Sakimura" <sakimura@gmail.com> wrote:
Hi Josh, 

It is similar but slightly different IMHO. 

Section 4.6.4 of the =
RFC6819 is the access token phishing by a counterfeit resource =
server. 
The mix-up attack described here is =
the code phishing by a counterfeit token endpoint. 

In my view, both can be =
mitigated by the server returning the next step: i.e., authorization =
endpoint returning the legitimate token endpoint uri, and token endpoint =
returning legitimate resource endpoint uris. This involves no discovery =
endpoint, which is good. 

Your way also works. It is just the =
reverse of my proposal. The difference being that my proposal does not =
need any coding on the server but just configuration, and it can return =
more metadata if needed. 

Cheers, 

Nat

2016=E5=B9=B41=E6=9C=882=
1=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel <jmandel@gmail.com>:
Apologies if this is =
the wrong forum for my comment (and please direct me to the appropriate =
place in that case), but I have two questions about the propose =
mitigation (and the thinking behind it) that I think the write-up could =
address:
1. Could the writeup clarify =
whether/how the primary "mixup" threat differs from what RFC6819 =
identifies as in section 4.6.4? 
2. Has the =
workgroup considered a mitigation that puts more responsibility on the =
authorization server, and less on the client? For example, if would be =
helpful for the writeup to clarify why having the client send an =
"audience field" (in the terminology of RFC6819) to the authorization =
endpoint would not mitigate the threat. (In that scenario, the =
authorization server can recognize that the audience does not correspond =
to a resource server it knows, rather than asking clients to make this =
check). I assume this approach has been considered and rejected as an =
incomplete mitigation, but I don't have visibility into where/how that =
discussion went. 
Thanks, 
Josh 




Hi all,



this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see

https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation=
-00



Please let us know by Feb 9th whether you accept / object to the

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

working group.



Note: This call is related to the announcement made on the list =
earlier

this month, see

http://www.ietf.org/mail-archive/web/oauth/current/msg15336.htm=
l. More

time for analysis is provided due to the complexity of the topic.



Ciao

Hannes & Derek




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





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


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






=

--Apple-Mail=_35305734-62AC-486A-B0BC-BFA8696B8AA0--

--Apple-Mail=_BF366EBF-2F81-45CC-AF9F-1938DD9A7296
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjIwMDU4NDVaMCMGCSqGSIb3DQEJBDEWBBQ0nmOCvESb3jHf3fUdKemH
UYR4mzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAbqhFL88ueqW9d+pDPr07Mmoy1uH+l3cWbi1o7/+pru4h67yv22Zfo
8NuE1X0qiTd2UDCWBIva6QsrSibUO3iysgboRe66T9sjq4aIFKFQQTDQT7z+bNYAHUVckCgJUgbx
rPQ24ncd3V7zXtmCwbi/yo6lbXKF5EwgZ4R4gr5f8pr166Xg1u4xb1lv383mAHudNK63QlrrmsM2
J7hBSTJOW4q0mnZgJ/Ke19z8A+Qd7F7DwWJQpF7TXpm8fBPvw60pgyD5Qv6xCjsxjQcBrPwflWOm
+bjnShdEud0ZPrGkOVeUM74gupNWd2GutVU6iHg4glspJuONQdDgeLFplQXzAAAAAAAA
--Apple-Mail=_BF366EBF-2F81-45CC-AF9F-1938DD9A7296--


From nobody Thu Jan 21 17:04:37 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AAA1B35AD for ; Thu, 21 Jan 2016 17:04:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96vgY6__Mn-N for ; Thu, 21 Jan 2016 17:04:30 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0120.outbound.protection.outlook.com [65.55.169.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13CB91B35AA for ; Thu, 21 Jan 2016 17:04:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WMiHPiuDJygphbZ5dhrF3QgGdeterFQrxayzKTQsI9M=; b=J0EN1KCBNRl+IkY8J5rJjy3H7vkN2fKySPug8PeSQX6mCY32fmIwx9syCb4YJDNW+Q+mtdB40OqyBfvgtqnUSsHlPsYXUoSv2jnxJtid7cz86t5LIOjwgVzqfW4LZNXswmU+jIsJu88C6OizstTpwGCobcx1oNNWtzwyD9NyFQ0=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 22 Jan 2016 01:04:26 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Fri, 22 Jan 2016 01:04:26 +0000
From: Mike Jones 
To: John Bradley , Nat Sakimura 
Thread-Topic: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
Thread-Index: AQHRUq+JezA9MNShFkKUMQbx88gF+p8GA9MAgAAKAICAAAL9gIAAiKQAgAAbgwCAAAK4AIAAAH/g
Date: Fri, 22 Jan 2016 01:04:25 +0000
Message-ID: 
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.com>
In-Reply-To: <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [2001:4898:80e8:b::78c]
x-ms-office365-filtering-correlation-id: 5a360af7-7783-4a39-915b-08d322c7f908
x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:P3ZuJijCm1aNPrbwu04o0H2tRUdSgLssjM8Q54uLJ6gHFtAapbk2pIhnre236p5ERU0KjuU6lgZr4k4C6NpwBnUpJlOZxjePseaorIyhJByoLJ78ibgRUbVNa3i+NlXD/2zcJ+SiUFhtMfzYJjgzTA==; 24:jFOv32PLQlIADN03cJqGQsSMwlwfklUTxjTR0ijjzNZdUR23mgXCVdhBZBf4Y91I1Zm4Rh104rUrac6M4+zIVeQ40rjhRs0e/g4/3u3E7lw=
x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; UriScan:; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; 
x-forefront-prvs: 08296C9B35
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(189002)(36944003)(164054003)(53754006)(377454003)(72854002)(199003)(10290500002)(16236675004)(92566002)(6116002)(1096002)(5008740100001)(790700001)(8990500004)(586003)(99286002)(1220700001)(86362001)(86612001)(102836003)(19609705001)(76576001)(10090500001)(189998001)(106116001)(5001960100002)(93886004)(19617315012)(10400500002)(5005710100001)(105586002)(74316001)(106356001)(97736004)(5001770100001)(81156007)(19625215002)(33656002)(76176999)(77096005)(19580405001)(87936001)(54356999)(50986999)(101416001)(19300405004)(561944003)(5002640100001)(4326007)(40100003)(2900100001)(2906002)(5004730100002)(2950100001)(5003600100002)(11100500001)(122556002)(19580395003)(15975445007)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4425923CAC5A0B0A46BA1A6F5C40BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2016 01:04:25.8796 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 01:04:36 -0000

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

SSBiZWxpZXZlIHRoYXQgaXTigJlzIHNpbXBsZXIgYW5kIG1vcmUgZWxlZ2FudCB0byByZXR1cm4g
YW4gaXNzdWVyLCBmcm9tIHdoaWNoIHRoZSBkaXNjb3ZlcnkgbWV0YWRhdGEgZG9jdW1lbnQgY2Fu
IGJlIHJldHJpZXZlZCwgd2hpY2ggY29udGFpbnMgKmFsbCogdGhlIGNvbmZpZ3VyYXRpb24gaW5m
b3JtYXRpb24gYWJvdXQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB0aGFuIHRvIHJldHVybiBz
b21lIG9mIHRoZSBjb25maWd1cmF0aW9uIHBhcmFtZXRlcnMgYnV0IG5vdCBtb3N0IG9mIHRoZW0g
KHdoaWNoIGlzIHdoYXQgdGhlIG9hdXRoLW1ldGEgcHJvcG9zYWwgZG9lcykuICBUaGVyZeKAmXMg
bG90cyBtb3JlIGluIGEgdHlwaWNhbCBkaXNjb3ZlcnkgZG9jdW1lbnQgdGhhbiBqdXN0IGEgZmV3
IGVuZHBvaW50IGFkZHJlc3Nlcy4gIEZvciBpbnN0YW5jZSwgdGhlcmUgYXJlIHN0YXRlbWVudHMg
YWJvdXQgd2hhdCByZXNwb25zZSB0eXBlcyBhcmUgc3VwcG9ydGVkLCBvdGhlciBjb25maWd1cmF0
aW9uIGNob2ljZXMsIGtleXMsIGV0Yy4NCg0KSSBhbHNvIHRoaW5rIHRoYXQgcmV0dXJuaW5nIHRo
ZSBpc3N1ZXIgaXMgbW9yZSBmdXR1cmUtcHJvb2YgdGhhbiB0cnlpbmcgdG8gZGVjaWRlIG5vdyB3
aGF0IGFsbCB0aGUgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBpcyB0aGF0IG1pZ2h0IHdhbnQg
dG8gYmUgdmVyaWZpZWQgYnkgdGhlIGNsaWVudCBhbmQgaG9waW5nIHdlIGdldCBpdCByaWdodC4g
IFdpdGggdGhlIGlzc3VlciwgYXNzdW1pbmcgdGhhdCBkaXNjb3ZlcnkgaXMgc3VwcG9ydGVkLCBp
dCBjYW4gcmV0cmlldmUgYW5kIGNoZWNrIGFsbCBvZiBpdCwgc2hvdWxkIHRoZSBjbGllbnQgd2Fu
dC9uZWVkIHRvIGRvIHNvLiAgRXZlbiB3aGVuIGRpc2NvdmVyeSBpc27igJl0IHN1cHBvcnRlZCwg
dGhlIGlzc3VlciBzdGlsbCBwcm92aWRlcyBhIGNvbmNyZXRlIGlkZW50aWZpZXIgZm9yIHRoZSBh
dXRob3JpemF0aW9uIHNlcnZlciB0aGF0IGNhbiBiZSBjaGVja2VkIGZvciBlcXVhbGl0eS4NCg0K
V2UgdGFsa2VkIGFib3V0IHRoZSB2YWx1ZSBvZiB0aGF0IGFwcHJvYWNoIGluIHRoZSBzaWRlIG1l
ZXRpbmdzIGluIFlva29oYW1hIGFuZCBwZW9wbGUgd2VyZSBzdXBwb3J0aXZlIHRoZW4uDQoNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAtLSBNaWtlDQoNCkZyb206IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIEpvaG4gQnJhZGxleQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjEs
IDIwMTYgNDo0OCBQTQ0KVG86IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPg0KQ2M6
IG9hdXRoQGlldGYub3JnIFdHIDxvYXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgt
V0ddIENhbGwgZm9yIEFkb3B0aW9uOiBPQXV0aCAyLjAgTWl4LVVwIE1pdGlnYXRpb24NCg0KSSB3
aWxsIHBvaW50IG91dCBmb3IgY2xhcmlmaWNhdGlvbiB0aGF0IHRoaXMgd291bGQgYmUgbGlrZSBJ
ZFAgZGlzY292ZXJ5IGluIG9wZW5JRCAyIHRoYXQgZXZlcnlvbmUgZGlkLiAgSSB0aGluayBJZFAg
bm90IGRvaW5nIFJQIGRpc2NvdmVyeSBpbiBvcGVuSUQgMiBpcyBhIHdlYWsgYXJndW1lbnQuDQpU
aGVyZSBtYXkgYmUgb3RoZXIgZXZpZGVuY2UgdGhhdCBSUCB3aWxsIG5vdCBkbyBkaXNjb3Zlcnks
IGJ1dCBpZiB0aGF0IGlzIHRoZSBjYXNlIHdoeSBhcmUgd2UgZG9pbmcgYSBPQXV0aCBkaXNjb3Zl
cnkgc3BlYz8NCk1hbnkgcGVvcGxlIHNlZSB5b3VyIHNwZWMgYXMgZGlzY292ZXJ5IGFzIHdlbGwg
anVzdCBpbiBhIGRpZmZlcmVudCB3YXkuDQoNCkkgdGhpbmsgYm90aCB3YXlzIGNhbiB3b3JrLCBi
dXQgZG9pbmcgYm90aCBsZWF2ZXMgdG9vIG1hbnkgb3B0aW9ucy4NCg0KSm9obiBCLg0KDQoNCk9u
IEphbiAyMSwgMjAxNiwgYXQgOTozOCBQTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5j
b208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpTdGlsbCBkb2luZyB0aGUg
YW5hbHlzaXMuIFdlIHNwZW50IDEuNSBob3VycyB0b2RheSB3aXRoIEpvaG4sIEdlb3JnZSwgbm92
IGFuZCBtZSBvbiB0aGUgT3BlbklEIENvbm5lY3QgV0cgY2FsbCBvbiB0aGlzIGlzc3VlLiBKb2hu
IGV4cGxhaW5lZCB0aGUgbWl0aWdhdGlvbiwgYnV0IG5vbmUgb2YgdXMgd2FzIGNvbnZpbmNlZCB0
aGF0IGl0IHdvcmtzLg0KDQpUaGVuLCBhZnRlciB0aGUgY2FsbCwgSSBhbmQgbm92IHdlbnQgb24g
d2l0aCB2YXJpb3VzIHNjZW5hcmlvcy4gVGhlIGludGVyaW0gY29uY2x1c2lvbiBpcyB0aGF0Og0K
DQogICogICBjbGllbnRfaWQgcmVzcG9uc2UgcGFyYW1ldGVyIGRvZXMgbm90IGhlbHAuIFRoZXJl
IGFyZSBsZWdpdGltYXRlIGNhc2VzIHRoYXQgY2xpZW50X2lkIGR1cGxpY2F0ZXMgb3V0IHRoZXJl
IGFuZCB3ZSBjYW5ub3QgYmFuIHRoYXQuDQogICogICBpc3MgcmVzcG9uc2UgcGFyYW1ldGVyIGRv
ZXMgbm90IGhlbHAgdW5sZXNzIHRoZSBkaXNjb3ZlcnkgaXMgcGVyZm9ybWVkIGFuZCB0aGUgdmFs
dWUgb2YgaXNzIGlzIGNoZWNrZWQgYWdhaW5zdCB0aGUgdmFsdWUgb2YgT0F1dGggaXNzdWVyIGlu
c2lkZSB0aGUgZG9jdW1lbnQuICg8LSBEaXNjb3ZlcnkgYmVjb21lcyBtYW5kYXRvcnkuIEZyb20g
b3VyIGV4cGVyaWVuY2Ugb24gUlAgZGlzY292ZXJ5IHN0ZXAgaW4gT3BlbklEIDIuMCwgY2hhbmNl
IG9mIHRoaXMgYmVpbmcgZG9uZSBwcm9wZXJseSBzZWVtcyB0byBiZSByYXRoZXIgc2xpbS4pDQog
ICogICBzZW5kaW5nIHRoZSBzdGF0ZSB0byB0aGUgdG9rZW4gZW5kcG9pbnQgaGVscHMgaW4gdGhl
IGNhc2UgY29kZSB3YXMgc3RvbGxlbiwgYnV0IGNvZGUgc2hvdWxkIG5vdCBiZSBzdG9sZW4gdG8g
c3RhcnQgd2l0aC4NCkNoZWVycywNCg0KTmF0DQoNCg0KMjAxNuW5tDHmnIgyMuaXpSjph5EpIDc6
NTkgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5j
b20+PjoNClRoZXJlIGhhdmUgYmVlbiBhIGxvdCBvZiBkaXNjdXNzaW9ucy4gSSB0aGluayBIYW5u
ZXMgcG9zdGVkIHNvbWUgbWludXRlcyBvZiB0aGUgRjJGIG1lZXRpbmcgd2UgaGFkIHdpdGggdGhl
IHNlY3VyaXR5IHJlc2VhcmNoZXJzLg0KDQpUaGUgcHJvYmxlbSBjYW7igJl0IGJlIG1pdGlnYXRl
ZCB3aXRob3V0IHNvbWUgYWN0aW9uIG9uIHRoZSBjbGllbnQgc2lkZS4gIEl0IGJvaWxzIGRvd24g
dG8gdGhlIGNsaWVudCBtYWtpbmcgYSByZXF1ZXN0IHRvIEFTMSAoRnJvbSBpdOKAmXMgcGVyc3Bl
Y3RpdmUpIGFuZCBnZXR0aW5nIGJhY2sgYSByZXNwb25zZSBmcm9tIEFTIDIgKHRoYXQgaXQgdGhp
bmtzIGlzIEFTMSkNCg0KVGhpcyBjYW4gYmUgZG9uZSBpZiBBUzEgaXMgYSBnb29kIEFTIGJ1dCBo
YXMgaXTigJlzIGxvZ3MgY29tcHJvbWlzZWQgc28gdGhhdCBhbiBhdHRhY2tlciBjYW4gcmVhZCB0
aGVtLiBIYW5zIFphbmRiZWx0IGJ1aWx0IGEgcHJvb2Ygb2YgY29uY2VwdCBmb3IgdGhlIGF0dGFj
ay4NCg0KSW4gc29tZSBjYXNlcyB0aGUgYXR0YWNrZXIgZ2V0cyB0aGUgY29kZSBhbmQgdGhlIGNy
ZWRlbnRpYWwgdG8gdXNlIGl0IGF0IHRoZSBnb29kIEFTIHRva2VuIGVuZHBvaW50IGFuZCBpbiBv
dGhlcnMgaXQganVzdCBnZXRzIHRoZSBjb2RlIGFuZCBjYW4gcmVwbGF5IHRoYXQgYXQgdGhlIGNs
aWVudCB0byBleHRyYWN0IGluZm9ybWF0aW9uIGZyb20gdGhlIEFQSSB0aHJvdWdoIHRoZSBjbGll
bnQgYnkgYmluZGluZyB0aGUgYXBpIGFjY2VzcyB0byBhIG5ldyBhY2NvdW50Lg0KDQpQS0NFIHVu
Zm9ydHVuYXRlbHkgbWl0aWdhdGVzIGEgZGlmZmVyZW50IGF0dGFjaywgd2hlcmUgdGhlIGNsaWVu
dCBpcyBpbXBlcnNvbmF0ZWQgYW5kIHRyeXMgdG8gcmVwbGF5IGEgaW50ZXJjZXB0ZWQgY29kZS4g
IEl0IGhvd2V2ZXIgYXNzdW1lcyB0aGUgdG9rZW4gZW5kcG9pbnQgaXMgZ29vZCwgYW5kIGlzIG5v
IGhlbHAgaW4gdGhlIGNhc2Ugb2YgYSBjb21wcm9taXNlZCB0b2tlbiBlbmRwb2ludC4NCg0KVGhl
IGNsaWVudCBpbiB0aGVzZSBhdHRhY2tzIGlzIHZ1bG5lcmFibGUgYmVjYXVzZSBpdCByZWxpZXMg
b24gc29tZSBsb2NhbCBzdGF0ZSwgb3IgdGhlIHZhbHVlIG9mIHRoZSBzdGF0ZSBwYXJhbWV0ZXIg
dG8ga25vdyB3aG8gdGhlIHJlc3BvbnNlIGlzIGNvbWluZyBmcm9tLiAgVGhpcyBhbGxvd3MgYSBh
dXRob3JpemF0aW9uIHJlcXVlc3QgdGhhdCBpcyBpbnRlcmNlcHRlZCB0byBiZSB1c2VkIHRvIGNy
ZWF0ZSBhIG5ldyByZXF1ZXN0IGluIHRoYXQgYnJvd3NlciB0byBhIGRpZmZlcmVudCBBUywgb3Ig
dHJpY2sgdGhlIGNsaWVudCBpbnRvIHVzaW5nIGEgQXV0aG9yaXphdGlvbiBlbmRwb2ludCBmb3Ig
YSBkaWZmZXJlbnQgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuDQoNCk9uZSBwcm9ibGVtIGlzIHRoYXQg
T0F1dGggZG9lc27igJl0IHJlYWxseSBoYXZlIGEgdW5pZmllZCBjb25jZXB0IG9mIHdoYXQgYSBB
UyBpcy4gIFRyYWRpdGlvbmFsbHkgaXQgaXMgYSBBdXRob3JpemF0aW9uIGVuZHBvaW50IFVSSSwg
dG9rZW4gZW5kIHBvaW50IFVSSSBhbmQgcmVzb3VyY2Ugc2VydmVyIFVSSSB0aGF0IHNvbWUgb25l
IGdpdmVzIHRoZSBjbGllbnQgaW4gc29tZSBkb2N1bWVudGF0aW9uLg0KDQpBcyBsaW5nIGFzIGEg
Y2xpZW50IG9ubHkgdGFsa3MgdG8gb25lIEFTIHRoZW4gdGhlcmUgaXMgbm8gcHJvYmxlbS4gICBI
b3dldmVyIG9uY2UgYSBjbGllbnQgaXMgY29uZmlndXJlZCB0byB0YWxrIHRvIG1vcmUgdGhhbiBv
bmUgQVMsIHdlIGhhdmUgcHJvYmxlbXMgaWYgb25lIG9mIHRob3NlIEFTIGxpZXMgYWJvdXQgaXTi
gJlzIGVuZHBvaW50cywgb3IgaXMgY29tcHJvbWlzZWQgYW5kIHVzZWQgdG8gYXR0YWNrIGFub3Ro
ZXIgQVMuICAgQXMgYSBkZXNpZ24gZ29hbCB5b3UgZG9u4oCZdCB3YW50IHRoZSBvdmVyYWxsICBz
ZWN1cml0eSB0byBiZSBsaW1pdGVkIGJ5IHRoZSB3ZWFrZXN0IHN5c3RlbS4NCg0KT25lIGFwcHJv
YWNoIGFzIE5hdCBwcm9tb3RlcyBpcyB0byBoYXZlIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50
IHJldHVybiB0aGUgbmV4dCBob3AsIHRva2VuIGVuZHBvaW50IGZvciBjb2RlIG9yIFJTIFVSSSBm
b3IgdG9rZW4uIFRoZSB0b2tlbiBlbmRwb2ludCBtdXN0IGFsc28gcmV0dXJuIHRoZSBSUyBVUkkg
b3IgdGhlIGNsaWVudCBtdXN0IHB1c2ggdGhlIFJTIFVSSSB0byB0aGUgdG9rZW4gZW5kcG9pbnQg
b3IgdGhlIGF0dGFja2VyIGp1c3QgcmVwbGFjZXMgdGhlIFJTIFVSSSBpbiB0aGUgY29uZmlnIGFu
ZCBjYXB0dXJlcyB0aGUgdG9rZW4gdGhhdCB3YXkuDQoNClRoZSBvdGhlciB3YXkgaXMgdG8gcHJv
dmlkZSBhIG5hbWUgZm9yIGVhY2ggQVMgYXMgcGFydCBvZiByZWdpc3RyYXRpb24gYW5kIHRoZSBj
bGllbnQgbm90IGFsbG93IGR1cGxpY2F0ZSByZWdpc3RyYXRpb25zIHdpdGggdGhlIHNhbWUgbmFt
ZS4gIFdoZW4gdGhlIHJlc3BvbnNlIGNvbWVzIGJhY2sgdGhlIGNsaWVudCBjaGVja3MgdGhlIG5h
bWUgYWdhaW5zdCB0aGUgb25lIGl0IG1hZGUgdGhlIHJlcXVlc3QgdG8uICBJZiB0aGUgbmFtZSBk
ZXJlZmVyZW5jZXMgdG8gYSBkaXNjb3ZlcnkgZG9jdW1lbnQgdGhlbiB0aGUgY2xpZW50IGNhbiBj
aGVjayB0aGF0IG5hbWUgYXQgcmVnaXN0cmF0aW9uIG9yIHJ1bnRpbWUgdG8gdmFsaWRhdGUgdGhl
IG5ldCBob3BzLg0KDQpJIHRoaW5rIHRoZSB0d28gYXBwcm9hY2hlcyBtaXRpZ2F0ZSB0aGUgYXR0
YWNrIGluIHNpbWlsYXIgd2F5cy4gIE5hdOKAmXMgaXMgbW9yZSBSRVNUIGZyaWVuZGx5IGFuZCBy
ZXR1cm5zIHRoZSBuZXh0IGhvcCBhcyBhIHBhcmFtZXRlciBvZiBoZWFkZXIuDQoNClRoZSBvbmUg
TWlrZSBhbmQgSSB3cm90ZSB1cCBiYXNlZCBvbiB0aGUgbWVldGluZyBpbiBHZXJtYW55IHByb3Zp
ZGVzIGlkZW50aWZpZXJzIChpc3MgYW5kIGNsaWVudF9pZCkgdGhhdCBjYW4gYmUgY2hlY2tlZCBm
b3IgdmFsaWRpdHkgaW4gdGhlIHNpbXBsZSBjYXNlIGFuZCBiZSBkZXJlZmVyZW5jZWQgdmlhIC53
ZWxsLWtub3duIHRvIGdldCB0aGUgaW5mb3JtYXRpb24gTmF04oCZcyBwcm9wb3NhbCBpcyBwcm92
aWRpbmcuDQoNClBlcmhhcHMgdGhlIG1haW4gZGlmZmVyZW5jZSBpcyBOYXQgaXMgdXNpbmcgdGhl
IHRva2VuIGVuZHBvaW50IGFzIHRoZSBpZGVudGlmaWVyIGZvciB0aGUgQVMgYW5kIE1pa2XigJlz
IGlzIHVzaW5nIGxvY2F0aW9uIGZvciBhIGRpc2NvdmVyeSBkb2N1bWVudCBhcyB0aGUgaWRlbnRp
Zmllci4NCg0KSSBkb27igJl0IHJlY2FsbCB0aGUgcmVhc29ucyB1c2luZyB0aGUgdG9rZW4gZW5k
cG9pbnQgYXMgdGhlIGlkZW50aWZpZXIgd2FzIHJlamVjdGVkIGF0IHRoZSBtZWV0aW5nLiAgUGVy
aGFwcyBvdGhlcnMgY2FuIHBvc3QgdGhlIHJlYXNvbnMuDQoNCldlIG5lZWQgdG8gY2xvc2Ugb24g
dGhpcyBxdWlja2x5LCBvdGhlcndpc2UgaWYgd2UgYXJlIGluZGVjaXNpdmUgZml4ZXMgd2lsbCBu
b3QgZ28gaW50byBwcm9kdWN0cyBmb3IgYW5vdGhlciB5ZWFyIG9yIHNvIHVudGlsIHRoaXMgaXMg
YSBSRkMuDQoNClRoYXQgaXMgbXkgbWFpbiBjb25jZXJuLg0KDQpKb2huIEIuDQoNCg0KDQoNCg0K
T24gSmFuIDIxLCAyMDE2LCBhdCAxMTo1MCBBTSwgSm9zaCBNYW5kZWwgPGptYW5kZWxAZ21haWwu
Y29tPG1haWx0bzpqbWFuZGVsQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpUaGFua3MgTmF0IC0gdGhh
dCdzIGhlbHBmdWwuIElmIGJvdGggbWl0aWdhdGlvbnMgKmNhbiogd29yayBlZmZlY3RpdmVseSwg
dGhlbiBJIHdvdWxkIGxpa2UgdG8gc2VlIHRoaXMgZ3JvdXAgY29uc2lkZXIgdGhlIGRlY2lzaW9u
IGJldHdlZW4gdGhlbSBjYXJlZnVsbHkgKGlmIHRoYXQgaGFzbid0IGhhcHBlbmVkIHlldCkuIEFn
YWluLCBkb24ndCBoZXNpdGF0ZSB0byBsZXQgbWUga25vdyBpZiB0aGlzIGlzIHRoZSB3cm9uZyBw
bGFjZS90aW1lIGZvciBzdWNoIGRpc2N1c3Npb24uDQpBdCBhIGhpZ2ggbGV2ZWwsIEkgd291bGQg
cmF0aGVyIGFzayBzZXJ2ZXIgZGV2ZWxvcGVycyB0byBkbyBzb21lICJjb2RpbmciLCBmb3IgdHdv
IHJlYXNvbnM6DQoxLiBNb3N0IE9BdXRoIHNlcnZlcnMgdGFsayB0byBtYW55LCBtYW55IGNsaWVu
dHMuIFNvIGNvbnNvbGlkYXRpbmcgdGhlIHNlY3VyaXR5IGNyaXRpY2FsIHdvcmsgaW4gb25lIHBs
YWNlIChzZXJ2ZXIpIGlzIGEgbmV0IHNhdmluZ3Mgb2Ygd29yayAocmF0aGVyIHRoYW4gYXNraW5n
IGVhY2ggY2xpZW50IHRvIGltcGxlbWVudCB0aGVzZSBjaGVja3MuDQoyLiBPQXV0aCBzZXJ2ZXIg
ZGV2ZWxvcGVycyBhcmUgdHlwaWNhbGx5IG1vcmUgc29waGlzdGljYXRlZCB0aGFuIGNsaWVudCBk
ZXZlbG9wZXJzLCBhbmQgdGhlcmVmb3JlIG1vcmUgbGlrZWx5IHRvIHVuZGVyc3RhbmQgdGhlIGlt
cGxpY2F0aW9ucyBhbmQgbW9yZSBsaWtlbHkgdG8gZ2V0IHRoZXNlIGNyaXRpY2FsIGRldGFpbHMg
Y29ycmVjdC4gQXNraW5nIGVhY2ggY2xpZW50IGRldmVsb3BlciB0byBkbyBzb21ldGhpbmcgcmln
aHQgaXMgbGlrZWx5IHRvIHJlc3VsdCBpbiBoZXRlcm9nZW5pdXMgaW1wbGVtZW50YXRpb24gYW5k
IHBlcnNpc3RlbnQgc2VjdXJpdHkgaG9sZXMuIEJ1dCBpZiB0aGUgc2VydmVyIGRvZXMgdGhlIGhl
YXZ5IGxpZnRpbmcsIGFuZCBjbGllbnRzIGp1c3QgaGF2ZSB0byBwYXNzIGFsb25nIGFuIGV4dHJh
IHBhcmFtZXRlciwgdGhpcyBpcyBtb3JlIGxpa2VseSB0byBzZWUgY29uc2lzdGVudCBpbXBsZW1l
bnRhdGlvbiAoZm9yIGV4YW1wbGUsIGNsaWVudHMgd2lsbCBmYWlsIHRvIHdvcmsgaWYgbWlzY29u
ZmlndXJlZCwgd2hpY2ggd2lsbCBwcm9tcHQgZGV2ZWxvcGVycyB0byBmaXggdGhlbSkuDQpPbiBK
YW4gMjEsIDIwMTYgMDk6NDAsICJOYXQgU2FraW11cmEiIDxzYWtpbXVyYUBnbWFpbC5jb208bWFp
bHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+IHdyb3RlOg0KSGkgSm9zaCwNCg0KSXQgaXMgc2ltaWxh
ciBidXQgc2xpZ2h0bHkgZGlmZmVyZW50IElNSE8uDQoNClNlY3Rpb24gNC42LjQgb2YgdGhlIFJG
QzY4MTkgaXMgdGhlIGFjY2VzcyB0b2tlbiBwaGlzaGluZyBieSBhIGNvdW50ZXJmZWl0IHJlc291
cmNlIHNlcnZlci4NClRoZSBtaXgtdXAgYXR0YWNrIGRlc2NyaWJlZCBoZXJlIGlzIHRoZSBjb2Rl
IHBoaXNoaW5nIGJ5IGEgY291bnRlcmZlaXQgdG9rZW4gZW5kcG9pbnQuDQoNCkluIG15IHZpZXcs
IGJvdGggY2FuIGJlIG1pdGlnYXRlZCBieSB0aGUgc2VydmVyIHJldHVybmluZyB0aGUgbmV4dCBz
dGVwOiBpLmUuLCBhdXRob3JpemF0aW9uIGVuZHBvaW50IHJldHVybmluZyB0aGUgbGVnaXRpbWF0
ZSB0b2tlbiBlbmRwb2ludCB1cmksIGFuZCB0b2tlbiBlbmRwb2ludCByZXR1cm5pbmcgbGVnaXRp
bWF0ZSByZXNvdXJjZSBlbmRwb2ludCB1cmlzLiBUaGlzIGludm9sdmVzIG5vIGRpc2NvdmVyeSBl
bmRwb2ludCwgd2hpY2ggaXMgZ29vZC4NCg0KWW91ciB3YXkgYWxzbyB3b3Jrcy4gSXQgaXMganVz
dCB0aGUgcmV2ZXJzZSBvZiBteSBwcm9wb3NhbC4gVGhlIGRpZmZlcmVuY2UgYmVpbmcgdGhhdCBt
eSBwcm9wb3NhbCBkb2VzIG5vdCBuZWVkIGFueSBjb2Rpbmcgb24gdGhlIHNlcnZlciBidXQganVz
dCBjb25maWd1cmF0aW9uLCBhbmQgaXQgY2FuIHJldHVybiBtb3JlIG1ldGFkYXRhIGlmIG5lZWRl
ZC4NCg0KQ2hlZXJzLA0KDQpOYXQNCg0KMjAxNuW5tDHmnIgyMeaXpSjmnKgpIDIzOjA0IEpvc2gg
TWFuZGVsIDxqbWFuZGVsQGdtYWlsLmNvbTxtYWlsdG86am1hbmRlbEBnbWFpbC5jb20+PjoNCkFw
b2xvZ2llcyBpZiB0aGlzIGlzIHRoZSB3cm9uZyBmb3J1bSBmb3IgbXkgY29tbWVudCAoYW5kIHBs
ZWFzZSBkaXJlY3QgbWUgdG8gdGhlIGFwcHJvcHJpYXRlIHBsYWNlIGluIHRoYXQgY2FzZSksIGJ1
dCBJIGhhdmUgdHdvIHF1ZXN0aW9ucyBhYm91dCB0aGUgcHJvcG9zZSBtaXRpZ2F0aW9uIChhbmQg
dGhlIHRoaW5raW5nIGJlaGluZCBpdCkgdGhhdCBJIHRoaW5rIHRoZSB3cml0ZS11cCBjb3VsZCBh
ZGRyZXNzOg0KMS4gQ291bGQgdGhlIHdyaXRldXAgY2xhcmlmeSB3aGV0aGVyL2hvdyB0aGUgcHJp
bWFyeSAibWl4dXAiIHRocmVhdCBkaWZmZXJzIGZyb20gd2hhdCBSRkM2ODE5IGlkZW50aWZpZXMg
YXMgaW4gc2VjdGlvbiA0LjYuND8NCjIuIEhhcyB0aGUgd29ya2dyb3VwIGNvbnNpZGVyZWQgYSBt
aXRpZ2F0aW9uIHRoYXQgcHV0cyBtb3JlIHJlc3BvbnNpYmlsaXR5IG9uIHRoZSBhdXRob3JpemF0
aW9uIHNlcnZlciwgYW5kIGxlc3Mgb24gdGhlIGNsaWVudD8gRm9yIGV4YW1wbGUsIGlmIHdvdWxk
IGJlIGhlbHBmdWwgZm9yIHRoZSB3cml0ZXVwIHRvIGNsYXJpZnkgd2h5IGhhdmluZyB0aGUgY2xp
ZW50IHNlbmQgYW4gImF1ZGllbmNlIGZpZWxkIiAoaW4gdGhlIHRlcm1pbm9sb2d5IG9mIFJGQzY4
MTkpIHRvIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHdvdWxkIG5vdCBtaXRpZ2F0ZSB0aGUg
dGhyZWF0LiAoSW4gdGhhdCBzY2VuYXJpbywgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGNhbiBy
ZWNvZ25pemUgdGhhdCB0aGUgYXVkaWVuY2UgZG9lcyBub3QgY29ycmVzcG9uZCB0byBhIHJlc291
cmNlIHNlcnZlciBpdCBrbm93cywgcmF0aGVyIHRoYW4gYXNraW5nIGNsaWVudHMgdG8gbWFrZSB0
aGlzIGNoZWNrKS4gSSBhc3N1bWUgdGhpcyBhcHByb2FjaCBoYXMgYmVlbiBjb25zaWRlcmVkIGFu
ZCByZWplY3RlZCBhcyBhbiBpbmNvbXBsZXRlIG1pdGlnYXRpb24sIGJ1dCBJIGRvbid0IGhhdmUg
dmlzaWJpbGl0eSBpbnRvIHdoZXJlL2hvdyB0aGF0IGRpc2N1c3Npb24gd2VudC4NClRoYW5rcywN
Ckpvc2gNCkhpIGFsbCwNCg0KdGhpcyBpcyB0aGUgY2FsbCBmb3IgYWRvcHRpb24gb2YgT0F1dGgg
Mi4wIE1peC1VcCBNaXRpZ2F0aW9uLCBzZWUNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1qb25lcy1vYXV0aC1taXgtdXAtbWl0aWdhdGlvbi0wMA0KDQpQbGVhc2UgbGV0IHVzIGtu
b3cgYnkgRmViIDl0aCB3aGV0aGVyIHlvdSBhY2NlcHQgLyBvYmplY3QgdG8gdGhlDQphZG9wdGlv
biBvZiB0aGlzIGRvY3VtZW50IGFzIGEgc3RhcnRpbmcgcG9pbnQgZm9yIHdvcmsgaW4gdGhlIE9B
dXRoDQp3b3JraW5nIGdyb3VwLg0KDQpOb3RlOiBUaGlzIGNhbGwgaXMgcmVsYXRlZCB0byB0aGUg
YW5ub3VuY2VtZW50IG1hZGUgb24gdGhlIGxpc3QgZWFybGllcg0KdGhpcyBtb250aCwgc2VlDQpo
dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTMz
Ni5odG1sLiBNb3JlDQp0aW1lIGZvciBhbmFseXNpcyBpcyBwcm92aWRlZCBkdWUgdG8gdGhlIGNv
bXBsZXhpdHkgb2YgdGhlIHRvcGljLg0KDQpDaWFvDQpIYW5uZXMgJiBEZXJlaw0KDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n
IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu
b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBp
ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K
DQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1
IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh
bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl
ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ
e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNv
bm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN
CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt
ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj
b2xvcjojMDAyMDYwOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsN
Cgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm
aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE3MDQ0NzMzNzU7DQoJbXNvLWxp
c3QtdGVtcGxhdGUtaWRzOi00ODA1OTcxMTY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl
bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs
LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt
aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv
LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1z
by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K
CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl
ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ
Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt
c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl
bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu
Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z
by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0
IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy
LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6
ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z
by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u
dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv
cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h
cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg
ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N
Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh
c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzAwMjA2MCI+SSBiZWxpZXZlIHRoYXQgaXTigJlzIHNpbXBsZXIgYW5kIG1vcmUgZWxl
Z2FudCB0byByZXR1cm4gYW4gaXNzdWVyLCBmcm9tIHdoaWNoIHRoZSBkaXNjb3ZlcnkgbWV0YWRh
dGEgZG9jdW1lbnQgY2FuIGJlIHJldHJpZXZlZCwgd2hpY2ggY29udGFpbnMgKjxiPmFsbDwvYj4q
IHRoZQ0KIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gYWJvdXQgdGhlIGF1dGhvcml6YXRpb24g
c2VydmVyLCB0aGFuIHRvIHJldHVybiBzb21lIG9mIHRoZSBjb25maWd1cmF0aW9uIHBhcmFtZXRl
cnMgYnV0IG5vdCBtb3N0IG9mIHRoZW0gKHdoaWNoIGlzIHdoYXQgdGhlIG9hdXRoLW1ldGEgcHJv
cG9zYWwgZG9lcykuJm5ic3A7IFRoZXJl4oCZcyBsb3RzIG1vcmUgaW4gYSB0eXBpY2FsIGRpc2Nv
dmVyeSBkb2N1bWVudCB0aGFuIGp1c3QgYSBmZXcgZW5kcG9pbnQgYWRkcmVzc2VzLiZuYnNwOw0K
IEZvciBpbnN0YW5jZSwgdGhlcmUgYXJlIHN0YXRlbWVudHMgYWJvdXQgd2hhdCByZXNwb25zZSB0
eXBlcyBhcmUgc3VwcG9ydGVkLCBvdGhlciBjb25maWd1cmF0aW9uIGNob2ljZXMsIGtleXMsIGV0
Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkkgYWxzbyB0aGlu
ayB0aGF0IHJldHVybmluZyB0aGUgaXNzdWVyIGlzIG1vcmUgZnV0dXJlLXByb29mIHRoYW4gdHJ5
aW5nIHRvIGRlY2lkZSBub3cgd2hhdCBhbGwgdGhlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24g
aXMgdGhhdCBtaWdodCB3YW50IHRvIGJlIHZlcmlmaWVkDQogYnkgdGhlIGNsaWVudCBhbmQgaG9w
aW5nIHdlIGdldCBpdCByaWdodC4mbmJzcDsgV2l0aCB0aGUgaXNzdWVyLCBhc3N1bWluZyB0aGF0
IGRpc2NvdmVyeSBpcyBzdXBwb3J0ZWQsIGl0IGNhbiByZXRyaWV2ZSBhbmQgY2hlY2sgYWxsIG9m
IGl0LCBzaG91bGQgdGhlIGNsaWVudCB3YW50L25lZWQgdG8gZG8gc28uJm5ic3A7IEV2ZW4gd2hl
biBkaXNjb3ZlcnkgaXNu4oCZdCBzdXBwb3J0ZWQsIHRoZSBpc3N1ZXIgc3RpbGwgcHJvdmlkZXMg
YSBjb25jcmV0ZSBpZGVudGlmaWVyDQogZm9yIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0aGF0
IGNhbiBiZSBjaGVja2VkIGZvciBlcXVhbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMwMDIwNjAiPldlIHRhbGtlZCBhYm91dCB0aGUgdmFsdWUgb2YgdGhhdCBhcHByb2Fj
aCBpbiB0aGUgc2lkZSBtZWV0aW5ncyBpbiBZb2tvaGFtYSBhbmQgcGVvcGxlIHdlcmUgc3VwcG9y
dGl2ZSB0aGVuLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2
MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw
aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE9BdXRoIFttYWlsdG86b2F1dGgtYm91bmNlc0Bp
ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9obiBCcmFkbGV5PGJyPg0KPGI+U2VudDo8
L2I+IFRodXJzZGF5LCBKYW51YXJ5IDIxLCAyMDE2IDQ6NDggUE08YnI+DQo8Yj5Ubzo8L2I+IE5h
dCBTYWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gb2F1
dGhAaWV0Zi5vcmcgV0cgJmx0O29hdXRoQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i
PiBSZTogW09BVVRILVdHXSBDYWxsIGZvciBBZG9wdGlvbjogT0F1dGggMi4wIE1peC1VcCBNaXRp
Z2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3
aWxsIHBvaW50IG91dCBmb3IgY2xhcmlmaWNhdGlvbiB0aGF0IHRoaXMgd291bGQgYmUgbGlrZSBJ
ZFAgZGlzY292ZXJ5IGluIG9wZW5JRCAyIHRoYXQgZXZlcnlvbmUgZGlkLiAmbmJzcDtJIHRoaW5r
IElkUCBub3QgZG9pbmcgUlAgZGlzY292ZXJ5IGluIG9wZW5JRCAyIGlzIGEgd2VhayBhcmd1bWVu
dC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBtYXkg
YmUgb3RoZXIgZXZpZGVuY2UgdGhhdCBSUCB3aWxsIG5vdCBkbyBkaXNjb3ZlcnksIGJ1dCBpZiB0
aGF0IGlzIHRoZSBjYXNlIHdoeSBhcmUgd2UgZG9pbmcgYSBPQXV0aCBkaXNjb3Zlcnkgc3BlYz8g
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5NYW55IHBlb3BsZSBzZWUgeW91ciBzcGVjIGFzIGRpc2NvdmVyeSBhcyB3ZWxsIGp1c3QgaW4g
YSBkaWZmZXJlbnQgd2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5JIHRoaW5rIGJvdGggd2F5cyBjYW4gd29yaywgYnV0IGRvaW5nIGJvdGgg
bGVhdmVzIHRvbyBtYW55IG9wdGlvbnMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEphbiAyMSwgMjAx
NiwgYXQgOTozOCBQTSwgTmF0IFNha2ltdXJhICZsdDs8YSBocmVmPSJtYWlsdG86c2FraW11cmFA
Z21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0aWxsIGRvaW5nIHRoZSBhbmFseXNp
cy4gV2Ugc3BlbnQgMS41IGhvdXJzIHRvZGF5IHdpdGggSm9obiwgR2VvcmdlLCBub3YgYW5kIG1l
IG9uIHRoZSBPcGVuSUQgQ29ubmVjdCBXRyBjYWxsIG9uIHRoaXMgaXNzdWUuIEpvaG4gZXhwbGFp
bmVkIHRoZSBtaXRpZ2F0aW9uLCBidXQgbm9uZSBvZiB1cyB3YXMgY29udmluY2VkIHRoYXQgaXQg
d29ya3MuJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5UaGVuLCBhZnRlciB0aGUgY2FsbCwgSSBhbmQgbm92IHdlbnQgb24gd2l0aCB2YXJpb3VzIHNj
ZW5hcmlvcy4gVGhlIGludGVyaW0gY29uY2x1c2lvbiBpcyB0aGF0OiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0bztsaW5lLWhlaWdodDoxNC42NXB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5jbGllbnRfaWQgcmVzcG9uc2UgcGFyYW1ldGVyIGRv
ZXMgbm90IGhlbHAuIFRoZXJlIGFyZSBsZWdpdGltYXRlIGNhc2VzIHRoYXQgY2xpZW50X2lkIGR1
cGxpY2F0ZXMgb3V0IHRoZXJlIGFuZCB3ZSBjYW5ub3QgYmFuIHRoYXQuICZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztsaW5lLWhlaWdodDoxNC42NXB0
O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
Ij5pc3MgcmVzcG9uc2UgcGFyYW1ldGVyIGRvZXMgbm90IGhlbHAgdW5sZXNzIHRoZSBkaXNjb3Zl
cnkgaXMgcGVyZm9ybWVkIGFuZCB0aGUgdmFsdWUgb2YgaXNzIGlzIGNoZWNrZWQgYWdhaW5zdCB0
aGUgdmFsdWUgb2YgT0F1dGggaXNzdWVyIGluc2lkZSB0aGUgZG9jdW1lbnQuICgmbHQ7LSBEaXNj
b3ZlcnkgYmVjb21lcyBtYW5kYXRvcnkuIEZyb20gb3VyIGV4cGVyaWVuY2Ugb24gUlAgZGlzY292
ZXJ5DQogc3RlcCBpbiBPcGVuSUQgMi4wLCBjaGFuY2Ugb2YgdGhpcyBiZWluZyBkb25lIHByb3Bl
cmx5IHNlZW1zIHRvIGJlIHJhdGhlciBzbGltLikmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2xp
PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGluZS1oZWlnaHQ6MTQuNjVwdDttc28tbGlzdDpsMCBs
ZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+c2VuZGluZyB0aGUg
c3RhdGUgdG8gdGhlIHRva2VuIGVuZHBvaW50IGhlbHBzIGluIHRoZSBjYXNlIGNvZGUgd2FzIHN0
b2xsZW4sIGJ1dCBjb2RlIHNob3VsZCBub3QgYmUgc3RvbGVuIHRvIHN0YXJ0IHdpdGguJm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Q2hlZXJzLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIwMTY8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3Vu
Ij7lubQ8L3NwYW4+MTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPuaciDwvc3Bhbj4y
MjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPuaXpTwvc3Bhbj4oPHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OlNpbVN1biI+6YeRPC9zcGFuPikgNzo1OSBKb2huIEJyYWRsZXkgJmx0Ozxh
IGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZlN2p0YkB2
ZTdqdGIuY29tPC9hPiZndDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND
IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu
LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaGF2ZSBiZWVu
IGEgbG90IG9mIGRpc2N1c3Npb25zLiBJIHRoaW5rIEhhbm5lcyBwb3N0ZWQgc29tZSBtaW51dGVz
IG9mIHRoZSBGMkYgbWVldGluZyB3ZSBoYWQgd2l0aCB0aGUgc2VjdXJpdHkgcmVzZWFyY2hlcnMu
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJvYmxl
bSBjYW7igJl0IGJlIG1pdGlnYXRlZCB3aXRob3V0IHNvbWUgYWN0aW9uIG9uIHRoZSBjbGllbnQg
c2lkZS4mbmJzcDsgSXQgYm9pbHMgZG93biB0byB0aGUgY2xpZW50IG1ha2luZyBhIHJlcXVlc3Qg
dG8gQVMxIChGcm9tIGl04oCZcyBwZXJzcGVjdGl2ZSkgYW5kIGdldHRpbmcgYmFjayBhIHJlc3Bv
bnNlIGZyb20gQVMgMiAodGhhdCBpdCB0aGlua3MgaXMgQVMxKTxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGNhbiBiZSBkb25lIGlmIEFT
MSBpcyBhIGdvb2QgQVMgYnV0IGhhcyBpdOKAmXMgbG9ncyBjb21wcm9taXNlZCBzbyB0aGF0IGFu
IGF0dGFja2VyIGNhbiByZWFkIHRoZW0uIEhhbnMgWmFuZGJlbHQgYnVpbHQgYSBwcm9vZiBvZiBj
b25jZXB0IGZvciB0aGUgYXR0YWNrLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBzb21lIGNhc2VzIHRoZSBhdHRhY2tlciBnZXRz
IHRoZSBjb2RlIGFuZCB0aGUgY3JlZGVudGlhbCB0byB1c2UgaXQgYXQgdGhlIGdvb2QgQVMgdG9r
ZW4gZW5kcG9pbnQgYW5kIGluIG90aGVycyBpdCBqdXN0IGdldHMgdGhlIGNvZGUgYW5kIGNhbiBy
ZXBsYXkgdGhhdCBhdCB0aGUgY2xpZW50IHRvIGV4dHJhY3QgaW5mb3JtYXRpb24gZnJvbSB0aGUg
QVBJIHRocm91Z2ggdGhlIGNsaWVudCBieSBiaW5kaW5nDQogdGhlIGFwaSBhY2Nlc3MgdG8gYSBu
ZXcgYWNjb3VudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+UEtDRSB1bmZvcnR1bmF0ZWx5IG1pdGlnYXRlcyBhIGRpZmZlcmVudCBhdHRhY2ss
IHdoZXJlIHRoZSBjbGllbnQgaXMgaW1wZXJzb25hdGVkIGFuZCB0cnlzIHRvIHJlcGxheSBhIGlu
dGVyY2VwdGVkIGNvZGUuJm5ic3A7IEl0IGhvd2V2ZXIgYXNzdW1lcyB0aGUgdG9rZW4gZW5kcG9p
bnQgaXMgZ29vZCwgYW5kIGlzIG5vIGhlbHAgaW4gdGhlIGNhc2Ugb2YgYSBjb21wcm9taXNlZCB0
b2tlbiBlbmRwb2ludC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGhlIGNsaWVudCBpbiB0aGVzZSBhdHRhY2tzIGlzIHZ1bG5lcmFibGUgYmVj
YXVzZSBpdCByZWxpZXMgb24gc29tZSBsb2NhbCBzdGF0ZSwgb3IgdGhlIHZhbHVlIG9mIHRoZSBz
dGF0ZSBwYXJhbWV0ZXIgdG8ga25vdyB3aG8gdGhlIHJlc3BvbnNlIGlzIGNvbWluZyBmcm9tLiZu
YnNwOyBUaGlzIGFsbG93cyBhIGF1dGhvcml6YXRpb24gcmVxdWVzdCB0aGF0IGlzIGludGVyY2Vw
dGVkIHRvIGJlIHVzZWQgdG8gY3JlYXRlDQogYSBuZXcgcmVxdWVzdCBpbiB0aGF0IGJyb3dzZXIg
dG8gYSBkaWZmZXJlbnQgQVMsIG9yIHRyaWNrIHRoZSBjbGllbnQgaW50byB1c2luZyBhIEF1dGhv
cml6YXRpb24gZW5kcG9pbnQgZm9yIGEgZGlmZmVyZW50IGF1dGhvcml6YXRpb24gc2VydmVyLjxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUg
cHJvYmxlbSBpcyB0aGF0IE9BdXRoIGRvZXNu4oCZdCByZWFsbHkgaGF2ZSBhIHVuaWZpZWQgY29u
Y2VwdCBvZiB3aGF0IGEgQVMgaXMuJm5ic3A7IFRyYWRpdGlvbmFsbHkgaXQgaXMgYSBBdXRob3Jp
emF0aW9uIGVuZHBvaW50IFVSSSwgdG9rZW4gZW5kIHBvaW50IFVSSSBhbmQgcmVzb3VyY2Ugc2Vy
dmVyIFVSSSB0aGF0IHNvbWUgb25lIGdpdmVzIHRoZSBjbGllbnQgaW4gc29tZSBkb2N1bWVudGF0
aW9uLiAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+QXMgbGluZyBhcyBhIGNsaWVudCBvbmx5IHRhbGtzIHRvIG9uZSBBUyB0
aGVuIHRoZXJlIGlzIG5vIHByb2JsZW0uICZuYnNwOyBIb3dldmVyIG9uY2UgYSBjbGllbnQgaXMg
Y29uZmlndXJlZCB0byB0YWxrIHRvIG1vcmUgdGhhbiBvbmUgQVMsIHdlIGhhdmUgcHJvYmxlbXMg
aWYgb25lIG9mIHRob3NlIEFTIGxpZXMgYWJvdXQgaXTigJlzIGVuZHBvaW50cywgb3IgaXMgY29t
cHJvbWlzZWQgYW5kIHVzZWQgdG8gYXR0YWNrIGFub3RoZXINCiBBUy4gJm5ic3A7IEFzIGEgZGVz
aWduIGdvYWwgeW91IGRvbuKAmXQgd2FudCB0aGUgb3ZlcmFsbCAmbmJzcDtzZWN1cml0eSB0byBi
ZSBsaW1pdGVkIGJ5IHRoZSB3ZWFrZXN0IHN5c3RlbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIGFwcHJvYWNoIGFzIE5hdCBwcm9tb3Rl
cyBpcyB0byBoYXZlIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IHJldHVybiB0aGUgbmV4dCBo
b3AsIHRva2VuIGVuZHBvaW50IGZvciBjb2RlIG9yIFJTIFVSSSBmb3IgdG9rZW4uIFRoZSB0b2tl
biBlbmRwb2ludCBtdXN0IGFsc28gcmV0dXJuIHRoZSBSUyBVUkkgb3IgdGhlIGNsaWVudCBtdXN0
IHB1c2ggdGhlIFJTIFVSSSB0byB0aGUgdG9rZW4gZW5kcG9pbnQNCiBvciB0aGUgYXR0YWNrZXIg
anVzdCByZXBsYWNlcyB0aGUgUlMgVVJJIGluIHRoZSBjb25maWcgYW5kIGNhcHR1cmVzIHRoZSB0
b2tlbiB0aGF0IHdheS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIG90aGVyIHdheSBpcyB0byBwcm92aWRlIGEgbmFtZSBmb3Ig
ZWFjaCBBUyBhcyBwYXJ0IG9mIHJlZ2lzdHJhdGlvbiBhbmQgdGhlIGNsaWVudCBub3QgYWxsb3cg
ZHVwbGljYXRlIHJlZ2lzdHJhdGlvbnMgd2l0aCB0aGUgc2FtZSBuYW1lLiZuYnNwOyBXaGVuIHRo
ZSByZXNwb25zZSBjb21lcyBiYWNrIHRoZSBjbGllbnQgY2hlY2tzIHRoZSBuYW1lIGFnYWluc3Qg
dGhlIG9uZSBpdCBtYWRlIHRoZSByZXF1ZXN0IHRvLiZuYnNwOw0KIElmIHRoZSBuYW1lIGRlcmVm
ZXJlbmNlcyB0byBhIGRpc2NvdmVyeSBkb2N1bWVudCB0aGVuIHRoZSBjbGllbnQgY2FuIGNoZWNr
IHRoYXQgbmFtZSBhdCByZWdpc3RyYXRpb24gb3IgcnVudGltZSB0byB2YWxpZGF0ZSB0aGUgbmV0
IGhvcHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkkgdGhpbmsgdGhlIHR3byBhcHByb2FjaGVzIG1pdGlnYXRlIHRoZSBhdHRhY2sgaW4gc2lt
aWxhciB3YXlzLiZuYnNwOyBOYXTigJlzIGlzIG1vcmUgUkVTVCBmcmllbmRseSBhbmQgcmV0dXJu
cyB0aGUgbmV4dCBob3AgYXMgYSBwYXJhbWV0ZXIgb2YgaGVhZGVyLiAmbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIG9uZSBNaWtl
IGFuZCBJIHdyb3RlIHVwIGJhc2VkIG9uIHRoZSBtZWV0aW5nIGluIEdlcm1hbnkgcHJvdmlkZXMg
aWRlbnRpZmllcnMgKGlzcyBhbmQgY2xpZW50X2lkKSB0aGF0IGNhbiBiZSBjaGVja2VkIGZvciB2
YWxpZGl0eSBpbiB0aGUgc2ltcGxlIGNhc2UgYW5kIGJlIGRlcmVmZXJlbmNlZCB2aWEgLndlbGwt
a25vd24gdG8gZ2V0IHRoZSBpbmZvcm1hdGlvbiBOYXTigJlzIHByb3Bvc2FsIGlzIHByb3ZpZGlu
Zy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
UGVyaGFwcyB0aGUgbWFpbiBkaWZmZXJlbmNlIGlzIE5hdCBpcyB1c2luZyB0aGUgdG9rZW4gZW5k
cG9pbnQgYXMgdGhlIGlkZW50aWZpZXIgZm9yIHRoZSBBUyBhbmQgTWlrZeKAmXMgaXMgdXNpbmcg
bG9jYXRpb24gZm9yIGEgZGlzY292ZXJ5IGRvY3VtZW50IGFzIHRoZSBpZGVudGlmaWVyLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbuKA
mXQgcmVjYWxsIHRoZSByZWFzb25zIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludCBhcyB0aGUgaWRl
bnRpZmllciB3YXMgcmVqZWN0ZWQgYXQgdGhlIG1lZXRpbmcuJm5ic3A7IFBlcmhhcHMgb3RoZXJz
IGNhbiBwb3N0IHRoZSByZWFzb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBuZWVkIHRvIGNsb3NlIG9uIHRoaXMgcXVpY2tseSwgb3Ro
ZXJ3aXNlIGlmIHdlIGFyZSBpbmRlY2lzaXZlIGZpeGVzIHdpbGwgbm90IGdvIGludG8gcHJvZHVj
dHMgZm9yIGFub3RoZXIgeWVhciBvciBzbyB1bnRpbCB0aGlzIGlzIGEgUkZDLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGlzIG15IG1h
aW4gY29uY2Vybi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBKYW4gMjEsIDIwMTYsIGF0
IDExOjUwIEFNLCBKb3NoIE1hbmRlbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptYW5kZWxAZ21haWwu
Y29tIiB0YXJnZXQ9Il9ibGFuayI+am1hbmRlbEBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgTmF0IC0gdGhhdCdz
IGhlbHBmdWwuIElmIGJvdGggbWl0aWdhdGlvbnMgKmNhbiogd29yayBlZmZlY3RpdmVseSwgdGhl
biBJIHdvdWxkIGxpa2UgdG8gc2VlIHRoaXMgZ3JvdXAgY29uc2lkZXIgdGhlIGRlY2lzaW9uIGJl
dHdlZW4gdGhlbSBjYXJlZnVsbHkgKGlmIHRoYXQgaGFzbid0IGhhcHBlbmVkDQogeWV0KS4gQWdh
aW4sIGRvbid0IGhlc2l0YXRlIHRvIGxldCBtZSBrbm93IGlmIHRoaXMgaXMgdGhlIHdyb25nIHBs
YWNlL3RpbWUgZm9yIHN1Y2ggZGlzY3Vzc2lvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj5BdCBhIGhpZ2ggbGV2ZWwsIEkgd291bGQgcmF0aGVyIGFzayBzZXJ2ZXIg
ZGV2ZWxvcGVycyB0byBkbyBzb21lICZxdW90O2NvZGluZyZxdW90OywgZm9yIHR3byByZWFzb25z
OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xLiBNb3N0IE9BdXRoIHNl
cnZlcnMgdGFsayB0byBtYW55LCBtYW55IGNsaWVudHMuIFNvIGNvbnNvbGlkYXRpbmcgdGhlIHNl
Y3VyaXR5IGNyaXRpY2FsIHdvcmsgaW4gb25lIHBsYWNlIChzZXJ2ZXIpIGlzIGEgbmV0IHNhdmlu
Z3Mgb2Ygd29yayAocmF0aGVyIHRoYW4gYXNraW5nIGVhY2ggY2xpZW50IHRvIGltcGxlbWVudA0K
IHRoZXNlIGNoZWNrcy4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIu
IE9BdXRoIHNlcnZlciBkZXZlbG9wZXJzIGFyZSB0eXBpY2FsbHkgbW9yZSBzb3BoaXN0aWNhdGVk
IHRoYW4gY2xpZW50IGRldmVsb3BlcnMsIGFuZCB0aGVyZWZvcmUgbW9yZSBsaWtlbHkgdG8gdW5k
ZXJzdGFuZCB0aGUgaW1wbGljYXRpb25zIGFuZCBtb3JlIGxpa2VseSB0byBnZXQgdGhlc2UgY3Jp
dGljYWwNCiBkZXRhaWxzIGNvcnJlY3QuIEFza2luZyBlYWNoIGNsaWVudCBkZXZlbG9wZXIgdG8g
ZG8gc29tZXRoaW5nIHJpZ2h0IGlzIGxpa2VseSB0byByZXN1bHQgaW4gaGV0ZXJvZ2VuaXVzIGlt
cGxlbWVudGF0aW9uIGFuZCBwZXJzaXN0ZW50IHNlY3VyaXR5IGhvbGVzLiBCdXQgaWYgdGhlIHNl
cnZlciBkb2VzIHRoZSBoZWF2eSBsaWZ0aW5nLCBhbmQgY2xpZW50cyBqdXN0IGhhdmUgdG8gcGFz
cyBhbG9uZyBhbiBleHRyYSBwYXJhbWV0ZXIsIHRoaXMgaXMNCiBtb3JlIGxpa2VseSB0byBzZWUg
Y29uc2lzdGVudCBpbXBsZW1lbnRhdGlvbiAoZm9yIGV4YW1wbGUsIGNsaWVudHMgd2lsbCBmYWls
IHRvIHdvcmsgaWYgbWlzY29uZmlndXJlZCwgd2hpY2ggd2lsbCBwcm9tcHQgZGV2ZWxvcGVycyB0
byBmaXggdGhlbSkuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5PbiBKYW4gMjEsIDIwMTYgMDk6NDAsICZxdW90O05hdCBTYWtpbXVyYSZxdW90OyAmbHQ7PGEg
aHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJh
QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow
aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBKb3NoLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgc2ltaWxhciBidXQgc2xpZ2h0bHkg
ZGlmZmVyZW50IElNSE8uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gNC42LjQgb2YgdGhlIFJGQzY4MTkgaXMgdGhlIGFj
Y2VzcyB0b2tlbiBwaGlzaGluZyBieSBhIGNvdW50ZXJmZWl0IHJlc291cmNlIHNlcnZlci4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo
ZSBtaXgtdXAgYXR0YWNrIGRlc2NyaWJlZCBoZXJlIGlzIHRoZSBjb2RlIHBoaXNoaW5nIGJ5IGEg
Y291bnRlcmZlaXQgdG9rZW4gZW5kcG9pbnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIG15IHZpZXcsIGJvdGggY2FuIGJlIG1p
dGlnYXRlZCBieSB0aGUgc2VydmVyIHJldHVybmluZyB0aGUgbmV4dCBzdGVwOiBpLmUuLCBhdXRo
b3JpemF0aW9uIGVuZHBvaW50IHJldHVybmluZyB0aGUgbGVnaXRpbWF0ZSB0b2tlbiBlbmRwb2lu
dCB1cmksIGFuZCB0b2tlbiBlbmRwb2ludCByZXR1cm5pbmcgbGVnaXRpbWF0ZSByZXNvdXJjZSBl
bmRwb2ludCB1cmlzLiBUaGlzIGludm9sdmVzIG5vIGRpc2NvdmVyeQ0KIGVuZHBvaW50LCB3aGlj
aCBpcyBnb29kLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj5Zb3VyIHdheSBhbHNvIHdvcmtzLiBJdCBpcyBqdXN0IHRoZSByZXZlcnNl
IG9mIG15IHByb3Bvc2FsLiBUaGUgZGlmZmVyZW5jZSBiZWluZyB0aGF0IG15IHByb3Bvc2FsIGRv
ZXMgbm90IG5lZWQgYW55IGNvZGluZyBvbiB0aGUgc2VydmVyIGJ1dCBqdXN0IGNvbmZpZ3VyYXRp
b24sIGFuZCBpdCBjYW4gcmV0dXJuIG1vcmUgbWV0YWRhdGEgaWYgbmVlZGVkLiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMs
Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk5hdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4yMDE2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5bm0PC9zcGFuPjE8c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj7mnIg8L3NwYW4+MjE8c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6U2ltU3VuIj7ml6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1T
dW4iPuacqDwvc3Bhbj4pIDIzOjA0IEpvc2ggTWFuZGVsICZsdDs8YSBocmVmPSJtYWlsdG86am1h
bmRlbEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5qbWFuZGVsQGdtYWlsLmNvbTwvYT4mZ3Q7
OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0
O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5BcG9sb2dpZXMgaWYgdGhpcyBpcyB0aGUgd3JvbmcgZm9ydW0gZm9yIG15IGNvbW1lbnQg
KGFuZCBwbGVhc2UgZGlyZWN0IG1lIHRvIHRoZSBhcHByb3ByaWF0ZSBwbGFjZSBpbiB0aGF0IGNh
c2UpLCBidXQgSSBoYXZlIHR3byBxdWVzdGlvbnMgYWJvdXQgdGhlIHByb3Bvc2UgbWl0aWdhdGlv
biAoYW5kIHRoZQ0KIHRoaW5raW5nIGJlaGluZCBpdCkgdGhhdCBJIHRoaW5rIHRoZSB3cml0ZS11
cCBjb3VsZCBhZGRyZXNzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4x
LiBDb3VsZCB0aGUgd3JpdGV1cCBjbGFyaWZ5IHdoZXRoZXIvaG93IHRoZSBwcmltYXJ5ICZxdW90
O21peHVwJnF1b3Q7IHRocmVhdCBkaWZmZXJzIGZyb20gd2hhdCBSRkM2ODE5IGlkZW50aWZpZXMg
YXMgaW4gc2VjdGlvbiA0LjYuND8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4yLiBIYXMgdGhlIHdvcmtncm91cCBjb25zaWRlcmVkIGEgbWl0aWdhdGlvbiB0aGF0IHB1
dHMgbW9yZSByZXNwb25zaWJpbGl0eSBvbiB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGFuZCBs
ZXNzIG9uIHRoZSBjbGllbnQ/IEZvciBleGFtcGxlLCBpZiB3b3VsZCBiZSBoZWxwZnVsIGZvciB0
aGUgd3JpdGV1cA0KIHRvIGNsYXJpZnkgd2h5IGhhdmluZyB0aGUgY2xpZW50IHNlbmQgYW4gJnF1
b3Q7YXVkaWVuY2UgZmllbGQmcXVvdDsgKGluIHRoZSB0ZXJtaW5vbG9neSBvZiBSRkM2ODE5KSB0
byB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCB3b3VsZCBub3QgbWl0aWdhdGUgdGhlIHRocmVh
dC4gKEluIHRoYXQgc2NlbmFyaW8sIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBjYW4gcmVjb2du
aXplIHRoYXQgdGhlIGF1ZGllbmNlIGRvZXMgbm90IGNvcnJlc3BvbmQgdG8gYSByZXNvdXJjZQ0K
IHNlcnZlciBpdCBrbm93cywgcmF0aGVyIHRoYW4gYXNraW5nIGNsaWVudHMgdG8gbWFrZSB0aGlz
IGNoZWNrKS4gSSBhc3N1bWUgdGhpcyBhcHByb2FjaCBoYXMgYmVlbiBjb25zaWRlcmVkIGFuZCBy
ZWplY3RlZCBhcyBhbiBpbmNvbXBsZXRlIG1pdGlnYXRpb24sIGJ1dCBJIGRvbid0IGhhdmUgdmlz
aWJpbGl0eSBpbnRvIHdoZXJlL2hvdyB0aGF0IGRpc2N1c3Npb24gd2VudC4NCjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MsDQo8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+Sm9zaA0KPG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBhbGwsPGJyPg0KPGJyPg0KdGhpcyBpcyB0aGUg
Y2FsbCBmb3IgYWRvcHRpb24gb2YgT0F1dGggMi4wIE1peC1VcCBNaXRpZ2F0aW9uLCBzZWU8YnI+
DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgt
bWl4LXVwLW1pdGlnYXRpb24tMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtbWl4LXVwLW1pdGlnYXRpb24tMDA8L2E+PGJyPg0K
PGJyPg0KUGxlYXNlIGxldCB1cyBrbm93IGJ5IEZlYiA5dGggd2hldGhlciB5b3UgYWNjZXB0IC8g
b2JqZWN0IHRvIHRoZTxicj4NCmFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgYXMgYSBzdGFydGlu
ZyBwb2ludCBmb3Igd29yayBpbiB0aGUgT0F1dGg8YnI+DQp3b3JraW5nIGdyb3VwLjxicj4NCjxi
cj4NCk5vdGU6IFRoaXMgY2FsbCBpcyByZWxhdGVkIHRvIHRoZSBhbm5vdW5jZW1lbnQgbWFkZSBv
biB0aGUgbGlzdCBlYXJsaWVyPGJyPg0KdGhpcyBtb250aCwgc2VlPGJyPg0KPGEgaHJlZj0iaHR0
cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTUzMzYu
aHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl
Yi9vYXV0aC9jdXJyZW50L21zZzE1MzM2Lmh0bWw8L2E+LiBNb3JlPGJyPg0KdGltZSBmb3IgYW5h
bHlzaXMgaXMgcHJvdmlkZWQgZHVlIHRvIHRoZSBjb21wbGV4aXR5IG9mIHRoZSB0b3BpYy48YnI+
DQo8YnI+DQpDaWFvPGJyPg0KSGFubmVzICZhbXA7IERlcmVrPGJyPg0KPGJyPg0KPGJyPg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBt
YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls
dG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+
DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0
YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy
ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3Jn
PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_BY2PR03MB4425923CAC5A0B0A46BA1A6F5C40BY2PR03MB442namprd_--


From nobody Thu Jan 21 17:35:16 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798411B2BFD for ; Thu, 21 Jan 2016 17:35:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I72Gxu-uPHUq for ; Thu, 21 Jan 2016 17:35:04 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::716]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8691F1B2C01 for ; Thu, 21 Jan 2016 17:35:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zXrvydJ4enN2ETu5ZJyaFf8u5NY26VgAN33SKKqrS18=; b=GbzBeZTjB9MJiBoYTuwlkx9lP9fNt8Q9PrCN/+Xy9G4AizVwQZRO7B2rgf4xF4GVvXQAaqB/nuF/vQYp9DKueO2Q9p4gQaMAk5/mU0+MwMKl+VYtjk18z2iYL6HEochbNfdSF+55gsqXicnySQuHDdchozAuKU+yrjHamCICwPo=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 22 Jan 2016 01:34:40 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Fri, 22 Jan 2016 01:34:40 +0000
From: Mike Jones 
To: Nat Sakimura , Justin Richer 
Thread-Topic: [OAUTH-WG] Call for Adoption
Thread-Index: AQHRUq7PwpSsQC2NpkCHuu6CK/uboJ8DuV2AgAAG9YCAAK43gIABGG0AgAABNnCAAAnOAIAABVcwgABO44CAACMRAIAAtS5g
Date: Fri, 22 Jan 2016 01:34:40 +0000
Message-ID: 
References: <569E2076.2090405@gmx.net>   <569F915D.8020806@mit.edu>      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [2001:4898:80e8:b::78c]
x-ms-office365-filtering-correlation-id: 721eaee7-a54a-41b9-7a9c-08d322cc328a
x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:t9XPNTr5rU2aVMfCG6+9M1gDMWb6bzTs+hr8H9YwnIk+ZnxEO0EUfOGL2nBZpst0uGyS1V5p8nKLjNzt90q34kU6jDSNuFdyxDzDT/xVLXHfOMIHqoHqk271MdEFwa60hx9Am2RL+k8on+P+7HRRUw==; 24:oylXj68+hs+E1Nh3RWBqoXFhAsHOVX+CG8ONgOZqQCAWU+TsinYknYndca1xuBSB3L21us0CU9/IMqTWsVzh5r5cvPG4FUiKC8Vpr44fGiE=
x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; UriScan:; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; 
x-forefront-prvs: 08296C9B35
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(53754006)(199003)(377454003)(24454002)(189002)(52314003)(5002640100001)(102836003)(2950100001)(16236675004)(99286002)(5005710100001)(33656002)(1220700001)(81156007)(586003)(1096002)(790700001)(561944003)(19580395003)(10290500002)(50986999)(97736004)(76176999)(19625215002)(10400500002)(74316001)(5001770100001)(122556002)(86612001)(86362001)(6116002)(76576001)(2900100001)(189998001)(5003600100002)(40100003)(93886004)(101416001)(19300405004)(2171001)(106116001)(106356001)(8990500004)(92566002)(105586002)(19580405001)(5004730100002)(15975445007)(87936001)(2906002)(4326007)(10090500001)(77096005)(5008740100001)(5001960100002)(19609705001)(19617315012)(11100500001)(54356999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442DE057967872C63A56DF8F5C40BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2016 01:34:40.1918 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 01:35:14 -0000

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

TmF0LCBJ4oCZbSBjb25mdXNlZCBieSB0aGlzIHN0YXRlbWVudCBpbiB0aGUgbWVzc2FnZSB5b3Ug
cmVmZXJlbmNlIOKAnFVuZm9ydHVuYXRlbHksIHRoaXMgZG9lcyBub3QgbWF0Y2ggdGhlIHZhbHVl
IG9mIE9BdXRoIGlzc3VlciBkZWZpbmVkIGluIFNlY3Rpb24gMiBvZiBkcmFmdC1qb25lcy1vYXV0
aC1taXgtdXAtbWl0aWdhdGlvbi0wMSBub3IgdGhlICdpc3MnIHJldHVybmVkIGFzIHNwZWNpZmll
ZCBpbiAzLjEuIEFzIHN1Y2gsIHZhbGlkYXRpb24gYXMgc3BlY2lmaWVkIGluIGJ1bGxldCAxIG9m
IFNlY3Rpb24gNCBmYWlscyBpbiBHb29nbGUncyBjYXNlIC0tIE9SIGl0IG1lYW5zIHRoYXQgdGhl
IGRvY3VtZW50IGlzIGludGVybmFsbHkgaW5jb25zaXN0ZW50LuKAnS4gIFRoZSBpc3N1ZXIgZGVm
aW5pdGlvbiBpbiBkcmFmdC1qb25lcy1vYXV0aC1kaXNjb3ZlcnkgaXMgMTAwJSBjb21wYXRpYmxl
IHdpdGggdGhlIG9uZSBpbiBPcGVuSUQgQ29ubmVjdCBEaXNjb3ZlcnksIGJ5IGRlc2lnbi4gIElu
IHRoZSBHb29nbGUgZXhhbXBsZSwgYm90aCB0aGUgT3BlbklEIGlzc3VlciBhbmQgdGhlIE9BdXRo
IGlzc3VlciB2YWx1ZXMgd291bGQgYmUgdGhlIHN0cmluZyDigJxodHRwczovL2FjY291bnRzLmdv
b2dsZS5jb23igJ0uICBXaGF0IGlzIHRoZSBpbmNvbnNpc3RlbmN5IHRoYXQgeW91IHBlcmNlaXZl
Pw0KDQpUaGUgZGlzY3Vzc2lvbiBvZiB0aGUgZHVwbGljYXRpb24gcHJvYmxlbSBoYXBwZW5lZCBp
biB0aGUgcHJpdmF0ZSBtZWV0aW5ncyBpbiBZb2tvaGFtYS4NCg0KSSB3aWxsIGFkbWl0LCBpbiBZ
b2tvaGFtYSwgSSBkaWRu4oCZdCBzcGVhayB1cCBpbiB0aGUgcHVibGljIG1lZXRpbmdzIHRvIHBv
aW50IG91dCB0aGF0IGEgc2ltcGxlciBhbHRlcm5hdGl2ZSB0byBvYXV0aC1tZXRhIHdhcyBhbHJl
YWR5IGJlaW5nIGRpc2N1c3NlZCB0aGVyZSBpbiBwcml2YXRlLCBiZWNhdXNlIHRoZW4gSSB3b3Vs
ZCBoYXZlIGhhZCB0byB0YWxrIGFib3V0IHRoZSBzZWN1cml0eSBpc3N1ZXMsIHdoaWNoIHdl4oCZ
ZCBkZWNpZGVkIG5vdCB0byBwdWJsaWNseSBkbyBhdCB0aGF0IHBvaW50LiAgU28gSSBzdGF5ZWQg
c2lsZW50IGR1cmluZyB0aGUgcG9sbCwgb3V0IG9mIHBvbGl0ZW5lc3MuICBQZXJoYXBzIEkgc2hv
dWxkIGhhdmUgZm91bmQgYSB3YXkgdG8gc2F5IHNvbWV0aGluZyB0aGVuIGFueXdheSwgYnV0IHRo
YXTigJlzIHdhdGVyIHVuZGVyIHRoZSBicmlkZ2Ugbm93Lg0KDQpGaW5hbGx5LCBmb3Igd2hhdCBp
dOKAmXMgd29ydGgsIHRoZSBIQVRFT0FTIHN0dWZmIHJlbWluZHMgbWUgZmFyIHRvbyBtdWNoIG9m
IFdlYiBTZXJ2aWNlcyBEZXNjcmlwdGlvbiBMYW5ndWFnZSAoV1NETCkg4oCTIHBhcnQgb2YgdGhl
IGNvbXBsZXhpdHkgYmFnZ2FnZSB0aGF0IGhlbHBlZCBzaW5rIFdlYiBTZXJ2aWNlcy4gIFRoZSB1
c2Ugb2Yg4oCcbGluayByZWzigJ0gdG8gZGVmaW5lIGFuIGludGVyYWN0aW9uIHZvY2FidWxhcnkg
YW5kIHB1Ymxpc2ggZW5kcG9pbnRzIGZvciB0aGF0IHZvY2FidWxhcnkgc2VlbXMgcHJldHR5IGJh
cm9xdWUgYW5kIHJlbWluaXNjZW50IG9mIOKAnG1pY3JvZm9ybWF0c+KAnSDigJMgYW5vdGhlciBj
dXRlIOKAnFdlYmJ54oCdIGlubm92YXRpb24gdGhhdCBuZXZlciBjYXVnaHQgb24uICBUaGUgaW5k
dXN0cnkgaGFzIHByZXR0eSBtdWNoIHZvdGVkIHdpdGggaXRzIGZlZXQgYW5kIGlzIHVzaW5nIEpT
T04gZm9yIHB1Ymxpc2hpbmcgZGlzY292ZXJ5IGRhdGEgc3RydWN0dXJlcyDigJMgbm90IOKAnGxp
bmsgcmVs4oCdLiAgSSBhbSBhZ2FpbnN0IHVzIHJldmVydGluZyB0byB0aGUg4oCcbGluayByZWzi
gJ0gcHJvcG9zYWwgZnJvbSAyMDA4IHRoYXQgbmV2ZXIgY2F1Z2h0IG9uIHdoZW4gSlNPTiBpcyBz
aW1wbGVyIGFuZCBkb2VzIGEgYmV0dGVyIGpvYi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTog
TmF0IFNha2ltdXJhIFttYWlsdG86c2FraW11cmFAZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXks
IEphbnVhcnkgMjEsIDIwMTYgNjoyNCBBTQ0KVG86IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0
LmVkdT47IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkNjOiBXaWxs
aWFtIERlbm5pc3MgPHdkZW5uaXNzQGdvb2dsZS5jb20+OyA8b2F1dGhAaWV0Zi5vcmc+IDxvYXV0
aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9uDQoN
Ck1pa2UsDQoNCllvdSBqdXN0IGNyaXRpY2l6ZSBteSBkcmFmdC4gVGhhdCdzIG9rLCBidXQgSSB3
b3VsZCByZWFsbHkgbGlrZSB0byBnZXQgc29tZSByZXNwb25zZSB0byBteSBxdWVzdGlvbnMgc3Rh
dGVkIGluIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVu
dC9tc2cxNTQ4My5odG1sIC4gVG8gbWUsIGl0IGp1c3QgZG9lcyBub3Qgc2VlbSB0byB3b3JrLCBh
bmQgdGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBvYXV0aC1tZXRhIGFuZCBQS0NFIHNlZW1zIHRvIGJl
IG11Y2ggbW9yZSBlbGVnYW4sIG5pY2VyLCBhbmQgbXVjaCBzaW1wbGVyIHRvIGltcGxlbWVudC4g
SWYgeW91IGp1c3QgZ2l2ZSB1cCB0aGUgZHluYW1pYyByZXNwb25zZSBhdCB0aGUgYXV0aG9yaXph
dGlvbiBlbmRwb2ludCwgdGhlbiB5b3UgZXZlbiBkbyBub3QgaGF2ZSB0byB0b3VjaCB0aGUgY29k
ZSBidXQganVzdCBjaGFuZ2UgYSBjb25maWcgZmlsZS4NCg0KUGxlYXNlIGNvbnZpbmNlIG1lIGJ5
IGFuc3dlcmluZyB0byBteSBxdWVzdGlvbnMuDQoNCkZvciB0aGUgcmVjb3JkIG9mIFlva29oYW1h
LCBJIGRvIG5vdCByZWNhbGwgbXVjaCBhYm91dCBkdXBsaWNhdGlvbiBpbiBPQXV0aCBzZXNzaW9u
LiBUaGUgcG9sbCBpbiB0aGUgcm9vbSB3YXMgMTkgZm9yIC8gemVybyBhZ2FpbnN0IC8gNCBwZXJz
b25zIG5lZWQgbW9yZSBpbmZvcm1hdGlvbi4gSW5kZWVkLCBpdCBpcyBub3QgZHVwbGljYXRpbmcg
bXVjaC4gQW5kIGlmIHlvdSBtb3ZlIHRvIGEgbmV3IG1vZGVsIHdpdGhvdXQgcHJlLWNvbmZpZ3Vy
ZWQgZGlzY292ZXJ5LCBpdCBpcyBub3QgZHVwbGljYXRpbmcgYW55IGJ1dCB0aGUgcmVzb3VyY2Ug
ZW5kcG9pbnQgVVJJLCB3aGljaCBpcyBvcHRpb25hbCBhbmQgaXMgZm9yIHRoZSBjYXNlcyB3aGVy
ZSB0aGUgY2xpZW50IGRpZCBub3Qga25vdyB0aGUgY29uY3JldGUgcmVzb3VyY2UgZW5kcG9pbnQg
dG8gc3RhcnQgd2l0aC4NCg0KSSB1bmRlcnN0YW5kIHlvdXIgdXNlY2FzZXMgYWx3YXlzIHN0YXJ0
IGZyb20gYSBjb25jcmV0ZSBlbmRwb2ludCBsb2NhdGlvbi4gTWluZSBkbyBub3QuIEluIGEgZm91
ciBwYXJ0eSBtb2RlbCwgaXQgaXMgbGlrZWx5IG5vdC4gVGhlIHVzZXIganVzdCB3YW50IHRvIGhh
dmUgdGhlIHNlcnZpY2UgdG8gZmV0Y2ggaGlzIGRhdGEgZnJvbSBzb21lIHJlc291cmNlIGVuZHBv
aW50LiBIZSBqdXN0IGhpdHMgdGhlIHNlcnZpY2UuIEhlIGRvZXMgbm90IGhpdCB0aGUgcmVzb3Vy
Y2UgZW5kcG9pbnQgZGlyZWN0bHkuIEZvciBleGFtcGxlLCBpbiB0aGUgY2FzZSBvZiBhIGNvbnN1
bWVyIHVzaW5nIGEgcGVyc29uYWwgZmluYW5jZSBwbGF0Zm9ybSAoUEZQKXRvIG1hbmFnZSBoaXMg
cGVuc2lvbiBmdW5kLCBoZSBoaXRzIHRoZSBQRlAgYW5kIG5vdCB0aGUgUGVuc2lvbiBmdW5kLiBB
c3N1bWluZyB0aGF0IHRoZSBwZW5zaW9uIGZ1bmQgaGFzIGRlbGVnYXRlZCB0aGUgYXV0aG9yaXph
dGlvbiBjb250cm9sIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlbiwgdGhlIGF1dGhv
cml6YXRpb24gc2VydmVyIHNob3VsZCByZXR1cm4gYm90aCB0aGUgYWNjZXNzIHRva2VuIGFuZCB0
aGUgZW5kcG9pbnQgb2YgdGhlIHBlbnNpb24gZnVuZCBzbyB0aGF0IHRoZSBQRlAgY2FuIHB1bGwg
dGhlIGRhdGEgdXNpbmcgdGhlbS4gQSBzaW1pbGFyIG1vZGVsIGhvbGRzIGZvciBwZXJzb25hbCBo
ZWFsdGggc2VydmljZSBhbmQgaGVhbHRoIGNhcmUgcHJvdmlkZXJzLg0KDQpCZXN0LA0KDQpOYXQN
Cg0KDQoyMDE25bm0MeaciDIx5pelKOacqCkgMjE6MTggSnVzdGluIFJpY2hlciA8anJpY2hlckBt
aXQuZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+PjoNCkNvbnZlcmdlbmNlIGlzIGV4YWN0bHkg
d2hhdCBJ4oCZbSBhcmd1aW5nIGZvciwgdGhvdWdoLiBUaGVzZSB0aGluZ3Mgb3VnaHQgdG8gd29y
ayB0b2dldGhlci4NCg0KIOKAlCBKdXN0aW4NCg0KT24gSmFuIDIxLCAyMDE2LCBhdCAyOjU1IEFN
LCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwu
Sm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpNeSBtZW1vcnkgb2YgdGhlIGRpc2N1c3Np
b25zIG9mIHRoZSBvYXV0aC1tZXRhIGRyYWZ0IGluIFlva29oYW1hIHdlcmUgdGhhdCBtYW55IHBl
b3BsZSBmZWx0IHRoYXQgaXQgd2FzIHVubmVjZXNzYXJpbHkgZHluYW1pY2FsbHkgZHVwbGljYXRp
bmcgYSBsb3Qgb2YgaW5mb3JtYXRpb24gdGhhdCB0aGUgY2xpZW50IGFscmVhZHkgaGFkLiAgTW9z
dCBvZiB1cyB0aGF0IHdlcmUgYXdhcmUgb2YgdGhlIGF0dGFja3MgdGhlbiB3ZXJlIGluIGZhdm9y
IG9mIGEgbW9yZSB0YXJnZXRlZCwgbWluaW1hbCBhcHByb2FjaC4gIFlvdSB3ZXJlIGxpc3RlbmVk
IHRvIGluIFlva29oYW1hLCBidXQgdGhhdCBkaWRu4oCZdCBuZWNlc3NhcmlseSBtZWFuIHRoYXQg
cGVvcGxlIGFncmVlZCB3aXRoIHRoZSBhcHByb2FjaC4gIFBhcnRpY2lwYW50cyB3ZXJlIGFscmVh
ZHkgYXdhcmUgb2YgdGhlIG9hdXRoLW1ldGEgcHJvcG9zYWwgaW4gRGFybXN0YWR0IGJ1dCBubyBv
bmUgc3Bva2UgdXAgaW4gZmF2b3Igb2YgaXQgdGhhdCBJIGNhbiByZWNhbGwuICBSYXRoZXIsIEkg
dGhpbmsgcGVvcGxlIHdlcmUgdGhpbmtpbmcgdGhhdCDigJxsZXNzIGlzIG1vcmXigJ0uDQoNClRo
ZXJlIGhhdmUgYWxzbyBiZWVuIGRpc2N1c3Npb25zIGluIHRoZSBsYXN0IGRheSBhYm91dCBob3cg
ZHluYW1pY2FsbHkgcmV0dXJuaW5nIGEgcmVzb3VyY2UgVVJMLCB3aGljaCBvYXV0aC1tZXRhIGRv
ZXMsIGlzIGJvdGggdW5uZWNlc3NhcnkgKHNpbmNlIHRoZSBjbGllbnQgaW5pdGlhdGVkIHRoZSBy
ZXNvdXJjZSBhdXRob3JpemF0aW9uIGFscmVhZHkga25vd2luZyB3aGF0IHJlc291cmNlIGl0IHdh
bnRzIHRvIGFjY2VzcykgYW5kIG9mdGVuIHByb2JsZW1hdGljLCBzaW5jZSBtYW55IGF1dGhvcml6
YXRpb24gc2VydmVycyBjYW4gYXV0aG9yaXplIGFjY2VzcyB0byBtdWx0aXBsZSByZXNvdXJjZXMu
ICBJZiBhbnl0aGluZywgdGhlIGNsaWVudCBzaG91bGQgYmUgdGVsbGluZyB0aGUgYXV0aG9yaXph
dGlvbiBzZXJ2ZXIgd2hhdCByZXNvdXJjZSBpdCB3YW50cyB0byBhY2Nlc3Mg4oCTIG5vdCB0aGUg
b3RoZXIgd2F5IGFyb3VuZC4NCg0KSeKAmW0gbm90IHNheWluZyB0aGF0IHRoZXJlIGFyZW7igJl0
IHNvbWUgZ29vZCBpZGVhcyBpbiB0aGUgb2F1dGgtbWV0YSBkcmFmdCDigJMgSeKAmW0gc3VyZSB0
aGVyZSBhcmUsIGp1c3QgYXMgdGhlcmUgYXJlIGluIHRoZSBhcHByb2FjaCBkZXNpZ25lZCBieSB0
aGUgcGFydGljaXBhbnRzIGluIERhcm1zdGFkdC4gIFdoaWxlIEkgdm9sdW50ZWVyZWQgdG8gd3Jp
dGUgdGhlIGZpcnN0IGRyYWZ0IG9mIHRoZSBtaXgtdXAtbWl0aWdhdGlvbiBhcHByb2FjaCwgaXQg
cmVhbGx5IHJlZmxlY3RzIHNvbWV0aGluZyBhIGxvdCBvZiBwZW9wbGUgaGF2ZSBhbHJlYWR5IGJv
dWdodCBpbnRvIOKAkyBhcyBldmlkZW5jZWQgaW4gdGhlIHBhc3Npb24gaW4gdGhlIGhpZ2gtdm9s
dW1lIOKAnE1peC1VcCBBYm91dCBUaGUgTWl4LVVwIE1pdGlnYXRpb27igJ0gdGhyZWFkLCBhbmQg
bm90IGp1c3QgbXkgcGVyc29uYWwgcHJvamVjdC4NCg0KSWYgeW91IHRoaW5rIHRoZXJlIGFyZSB0
aGluZ3MgbWlzc2luZyBvciB3cm9uZyBpbiB0aGUgbWl4LXVwLW1pdGlnYXRpb24gZHJhZnQsIHBs
ZWFzZSBzYXkgd2hhdCB0aGV5IGFyZS4gIFRoYXQgd2lsbCBoZWxwIHVzIHF1aWNrbHkgY29udmVy
Z2Ugb24gYSBzb2x1dGlvbiB0aGF0IHdpbGwgd29yayBmb3IgZXZlcnlvbmUuDQoNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTaW5jZXJl
bHksDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBOYXQgU2FraW11cmEgW21haWx0bzpzYWtpbXVyYUBnbWFp
bC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjAsIDIwMTYgMTE6MTcgUE0NClRvOiBN
aWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbT4+OyBXaWxsaWFtIERlbm5pc3MgPHdkZW5uaXNzQGdvb2dsZS5jb208
bWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20+PjsgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQu
ZWR1PG1haWx0bzpqcmljaGVyQG1pdC5lZHU+Pg0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpv
YXV0aEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9u
DQoNCkhpIE1pa2UuDQoNCkNvbnZlcnNlbHksIEkgd291bGQgbGlrZSB0byBhc2sgd2h5IHRoaXMg
YXBwcm9hY2ggZG9lcyBub3Qgd29yayBmb3IgTWl4LXVwIGF0dGFjay4gQXMgTm92IHN0YXRlZCwg
d2UgaW4gZmFjdCBoYXZlIGRpc2N1c3NlZCB0aGUgYXBwcm9hY2ggaW4gcXVpdGUgYSBsZW5ndGgg
YmFjayBpbiBZb2tvaGFtYS4gSSByZWFsbHkgd291bGQgbGlrZSB0byBrbm93IHdoeSBpdCBkb2Vz
IG5vdCB3b3JrLg0KDQpCZXNpZGVzLCBmb3Igb2F1dGgtbWV0YSBhcHByb2FjaCwgbWl4LXVwIGF0
dGFjayBpcyBvbmx5IG9uZSBvZiB0aGUgdGhpbmcgaXQgc29sdmVzLg0KDQpOYXQgU2FraW11cmEN
Cg0KMjAxNuW5tDHmnIgyMeaXpSjmnKgpIDE2OjAyIE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNA
bWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj46DQpOb3Qg
dG8gYmUgbmVnYXRpdmUsIGJ1dCBJIGRpc2FncmVlIHdpdGggYWRvcHRpbmcgZHJhZnQtc2FraW11
cmEtb2F1dGgtbWV0YS4gIFdlIHNob3VsZCBkZWZpbmUgYW5kIHByb21vdGUgb25lIG1pdGlnYXRp
b24gYXBwcm9hY2ggdG8gdGhlIG1peC11cCBhdHRhY2tzLiAgSGF2aW5nIHR3byB3b3VsZCBjb25m
dXNlIGltcGxlbWVudGVycyBhbmQgY2F1c2UgY29tcGF0aWJpbGl0eSBwcm9ibGVtcyDigJMgcmVk
dWNpbmcgb3ZlcmFsbCBzZWN1cml0eS4NCg0KVGhlIGFwcHJvYWNoIGRlZmluZWQgaW4gZHJhZnQt
am9uZXMtb2F1dGgtbWl4LXVwLW1pdGlnYXRpb24gd2FzIGNyZWF0ZWQgaW4gY29sbGFib3JhdGlv
biB3aXRoIHRoZSBzZWN1cml0eSByZXNlYXJjaGVycyB3aG8gaWRlbnRpZmllZCB0aGUgcHJvYmxl
bXMgaW4gdGhlIGZpcnN0IHBsYWNlLCB3YXMgdmlnb3JvdXNseSBkaXNjdXNzZWQgaW4gdGhlIHNl
Y3VyaXR5IG1lZXRpbmcgSGFubmVzIGFuZCBUb3JzdGVuIGhlbGQgaW4gRGFybXN0YWR0LCBhbmQg
aGFzIGJlZW4gc2luY2UgcmVmaW5lZCBiYXNlZCBvbiBzdWJzdGFudGlhbCBpbnB1dCBmcm9tIHRo
ZSB3b3JraW5nIGdyb3VwLiAgQW5kIGF0IGxlYXN0IHRocmVlIGltcGxlbWVudGVycyBoYXZlIGFs
cmVhZHkgc3RhdGVkIHRoYXQgdGhleeKAmXZlIGltcGxlbWVudGVkIGl0LiAgSeKAmW0gbm90IHNh
eWluZyB0aGF0IGl04oCZcywgYnV0IGlmIHRoZXJlIGFyZSB0aGluZ3MgbWlzc2luZyBvciB0aGlu
Z3MgdGhhdCBuZWVkIHRvIGJlIGltcHJvdmVkIGluIG91ciBhcHByb2FjaCwgd2Ugc2hvdWxkIGRv
IGl0IHRoZXJlLCByYXRoZXIgaW50cm9kdWNpbmcgYSBjb21wZXRpbmcgYXBwcm9hY2guDQoNCkFs
c28sIHN0YW5kYXJkIE9BdXRoIGRlcGxveW1lbnRzIHJlZ2lzdGVyIHRoZSBjbGllbnQgYW5kIHRo
ZW4gdXNlIHRoZSBpbmZvcm1hdGlvbiBnYXRoZXJlZCBhdCByZWdpc3RyYXRpb24gdGltZSBmb3Ig
c3Vic2VxdWVudCBwcm90b2NvbCBpbnRlcmFjdGlvbnMuICBUaGV5IGRvIG5vdCBuZWVkIGFsbCB0
aGUgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBmb3IgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy
IHRvIGJlIHJldHJhbnNtaXR0ZWQgYXQgcnVudGltZS4gIFRoZSBvYXV0aC1tZXRhIGRyYWZ0IGdv
ZXMgdG9vIGZhciBpbiB0aGF0IGRpcmVjdGlvbiwgYXQgbGVhc3QgYXMgSSBzZWUgaXQuICBSZXR1
cm5pbmcgdGhpbmdzIHR3byB3YXlzIGNyZWF0ZXMgaXRzIG93biBwcm9ibGVtcywgYXMgZGlzY3Vz
c2VkIGluIHRoZSBEdXBsaWNhdGUgSW5mb3JtYXRpb24gQXR0YWNrcyBzZWN1cml0eSBjb25zaWRl
cmF0aW9ucyBzZWN0aW9uICg3LjIpIG9mIHRoZSBtaXgtdXAtbWl0aWdhdGlvbiBkcmFmdC4NCg0K
SeKAmWxsIG5vdGUgdGhhdCB0aGUgbWl4LXVwLW1pdGlnYXRpb24gYXBwcm9hY2ggaXMgY29tcGF0
aWJsZSB3aXRoIGV4aXN0aW5nIHByYWN0aWNlIGluIGJvdGggc3RhdGljIGFuZCBkeW5hbWljIG1l
dGFkYXRhIGRpc2NvdmVyeS4gIFJlcGx5aW5nIHRvIEp1c3RpbuKAmXMgY29tbWVudCB0aGF0IOKA
nEl0J3MgdGhlIHByZS1jb25maWd1cmVkIGRpc2NvdmVyeSBkb2N1bWVudCB0aGF0J3MgYXQgdGhl
IHJvb3Qgb2YgdGhlIG1peC11cCBhdHRhY2sgaW4gdGhlIGZpcnN0IHBsYWNl4oCdIOKAkyB0aGlz
IGlzIG5vdCB0aGUgY2FzZS4gIFRoZSBhdHRhY2tzIGNhbiBiZSBwZXJmb3JtZWQgd2l0aG91dCBl
aXRoZXIgZGlzY292ZXJ5IG9yIGR5bmFtaWMgcmVnaXN0cmF0aW9uLg0KDQpJIHdvdWxkIGJlIGlu
dGVyZXN0ZWQgaW4gaGVhcmluZyBhIHRlY2huaWNhbCBkaXNjdXNzaW9uIG9uIHdoZXRoZXIgdGhl
cmUgYXJlIGFzcGVjdHMgb2YgdGhlIG9hdXRoLW1ldGEgYXBwcm9hY2ggdGhhdCBtaXRpZ2F0ZSBh
c3BlY3RzIG9mIHRoZSBhdHRhY2tzIHRoYXQgdGhlIG1peC11cC1taXRpZ2F0aW9uIGFwcHJvYWNo
IGRvZXMgbm90LiAgVGhhdCBjb3VsZCBoZWxwIGluZm9ybSB3aGV0aGVyIHRoZXJlIGFyZSBhZGRp
dGlvbmFsIHRoaW5ncyB3ZSBzaG91bGQgYWRkIHRvIG9yIGNoYW5nZSBpbiB0aGUgbWl4LXVwIGRy
YWZ0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBPQXV0aCBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgV2lsbGlh
bSBEZW5uaXNzDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjAsIDIwMTYgMTA6MzcgUE0NClRv
OiBKdXN0aW4gUmljaGVyIDxqcmljaGVyQG1pdC5lZHU8bWFpbHRvOmpyaWNoZXJAbWl0LmVkdT4+
DQpDYzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6
IFtPQVVUSC1XR10gQ2FsbCBmb3IgQWRvcHRpb24NCg0KKzEgdG8gYWRvcHQgdGhpcywgYW5kIEkg
YWdyZWUgd2l0aCBKdXN0aW4ncyBjb21tZW50cy4NCg0KT24gV2VkLCBKYW4gMjAsIDIwMTYgYXQg
OTo1MyBQTSwgSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpqcmljaGVyQG1p
dC5lZHU+PiB3cm90ZToNCisxDQoNCklubGluZSBkaXNjb3ZlcnkgYW5kIHByZS1jb25maWd1cmVk
IGRpc2NvdmVyeSAoaWUsIC53ZWxsLWtub3duKSBzaG91bGQgYXQgdGhlIHZlcnkgbGVhc3QgYmUg
Y29tcGF0aWJsZSBhbmQgZGV2ZWxvcGVkIHRvZ2V0aGVyLiBJdCdzIHRoZSBwcmUtY29uZmlndXJl
ZCBkaXNjb3ZlcnkgZG9jdW1lbnQgdGhhdCdzIGF0IHRoZSByb290IG9mIHRoZSBtaXgtdXAgYXR0
YWNrIGluIHRoZSBmaXJzdCBwbGFjZS4NCg0KIC0tIEp1c3Rpbg0KDQpPbiAxLzE5LzIwMTYgMTA6
MzAgUE0sIE5hdCBTYWtpbXVyYSB3cm90ZToNCkp1c3QgdG8gZ2l2ZSBtb3JlIGNvbnRleHQsIGF0
IElFVEYgOTQsIEkgaGF2ZSBkb25lIGEgcHJlc2VudGF0aW9uIG9uIGRpc2NvdmVyeS4NCg0KQWNj
b3JkaW5nIHRvIHRoZSBtaW51dGVzLA0KDQoNCiAgICAoZikgRGlzY292ZXJ5IChOYXQpDQoNCg0K
DQogICAgICAgICAgICAgTmF0IGV4cGxhaW5zIGhpcyBkb2N1bWVudCBhcyBhbiBleGFtcGxlIG9m
IHRoZSB3b3JrIHRoYXQgaGFzIHRvIGJlIGRvbmUNCg0KICAgICAgICAgICAgIGluIHRoZSBhcmVh
IG9mIGRpc2NvdmVyeSwgd2hpY2ggaXMgYSB0b3BpYyB0aGF0IGhhcyBiZWVuIGlkZW50aWZpZWQN
Cg0KICAgICAgICAgICAgIGFzIG5lY2Vzc2FyeSBmb3IgaW50ZXJvcGVyYWJpbGl0eSBzaW5jZSBt
YW55IHllYXJzIGJ1dCBzbyBmYXIgdGhlcmUNCg0KICAgICAgICAgICAgIHdhcyBub3QgdGltZSB0
byB3b3JrIG9uIGl0LiBNaWtlLCBKb2huIGFuZCBOYXQgYXJlIHdvcmtpbmcgb24gYSBuZXcNCg0K
ICAgICAgICAgICAgIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIGFkZGl0aW9uYWwgZGlzY292ZXJ5
LXJlbGV2YW50IGNvbXBvbmVudHMuDQoNCg0KDQogICAgICAgICAgICAgUG9sbDogMTkgZm9yIC8g
emVybyBhZ2FpbnN0IC8gNCBwZXJzb25zIG5lZWQgbW9yZSBpbmZvcm1hdGlvbi4NCg0KDQpUaGUg
ZG9jdW1lbnQgZGlzY3Vzc2VkIHRoZXJlIHdhcyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wNS4gVGhpcyBpcyBhIHNpbXBsZSAob25seSAxLXBh
Z2UhKSBidXQgYSB2ZXJ5IHBvd2VyZnVsIGRvY3VtZW50IHRoYXQgbnVkZ2VzIHRvd2FyZHMgSEFU
RU9BUyB3aGljaCBpcyBhdCB0aGUgY29yZSBvZiBSRVNUZnVsLW5lc3MuIEl0IGFsc28gbWl0aWdh
dGVzIHRoZSBNaXgtdXAgYXR0YWNrIHdpdGhvdXQgaW50cm9kdWNpbmcgdGhlIGNvbmNlcHQgb2Yg
aXNzdWVyIHdoaWNoIGlzIG5vdCBpbiBSRkM2NzQ5LiBJdCBpcyBhbHNvIGdvb2QgZm9yIHNlbGVj
dGluZyBkaWZmZXJlbnQgZW5kcG9pbnRzIGRlcGVuZGluZyBvbiB0aGUgdXNlciBhdXRoZW50aWNh
dGlvbiBhbmQgYXV0aG9yaXphdGlvbiByZXN1bHRzIGFuZCBtb3JlIHByaXZhY3kgc2Vuc2l0aXZl
IHRoYW4gcHJlLWFubm91bmNlZCBEaXNjb3ZlcnkgZG9jdW1lbnQuIEl0IGFsc28gYWxsb3dzIHlv
dSB0byBmaW5kIHRvIHdoaWNoIHByb3RlY3RlZCByZXNvdXJjZSBlbmRwb2ludCB5b3UgY2FuIHVz
ZSB0aGUgYWNjZXNzIHRva2VuIGFnYWluc3QuDQoNCkluIHRoZSBsYXN0IHNlbnRlbmNlIG9mIHRo
ZSBtaW51dGVzLCBpdCB0YWxrcyBhYm91dCAiYSBuZXcgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMg
YWRkaXRpb25hbCBkaXNjb3ZlcnktcmVsZXZhbnQgY29tcG9uZW50cyIuIFRoaXMgaXMgaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLWRpc2NvdmVyeS0wMC4gIEl0
IHdlbnQgZm9yIHRoZSBjYWxsIGZvciBhZG9wdGlvbi4gSG93ZXZlciwgaXQgaXMgb25seSBhIGhh
bGYgb2YgdGhlIHN0b3J5LiBJIGJlbGlldmUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDUgdGhhdCB3YXMgZGlzY3Vzc2VkIGF0IElFVEYgOTQg
YW5kIGhhZCBzdXBwb3J0IHRoZXJlIHNob3VsZCBiZSBhZG9wdGVkIGFzIHdlbGwuDQoNCk5hdCBT
YWtpbXVyYQ0KDQoNCg0KDQoyMDE25bm0MeaciDIw5pelKOawtCkgMTI6MDUgTmF0IFNha2ltdXJh
IDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbT4+Og0KVGhhbmtz
IEhhbm5lcy4NCg0KSSBkaWQgbm90IGZpbmQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDUsIHdoaWNoIHdhcyBkaXNjdXNzZWQgaW4gWW9rb2hh
bWEsIGFuZCB3YXMgbGFyZ2VseSBpbiBhZ3JlZW1lbnQgaWYgbXkgcmVjb2xsZWN0aW9uIGlzIGNv
cnJlY3QuIFdoeSBpcyBpdCBub3QgaW4gdGhlIGNhbGwgZm9yIGFkb3B0aW9uPw0KDQoNCg0KMjAx
NuW5tDHmnIgxOeaXpSjngaspIDIwOjM5IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9m
ZW5pZ0BnbXgubmV0PG1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0Pj46DQpIaSBhbGws
DQoNCndlIGhhdmUgc3VibWl0dGVkIG91ciBuZXcgY2hhcnRlciB0byB0aGUgSUVTRyAoc2VlDQpo
dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxNTM3
OS5odG1sKSBhbmQNCnNpbmNlIHNvbWUgSUVTRyBtZW1iZXJzIGxpa2UgdG8gc2VlIGFuIHVwZGF0
ZWQgbGlzdCBvZiBtaWxlc3RvbmVzIGFzDQp3ZWxsLiBGb3IgdGhpcyByZWFzb24sIGJhc2VkIG9u
IGEgc3VnZ2VzdGlvbiBmcm9tIEJhcnJ5LCB3ZSBhcmUgYWxzbw0Kc3RhcnRpbmcgYSBjYWxsIGZv
ciBhZG9wdGlvbiBjb25jdXJyZW50bHkgd2l0aCB0aGUgcmV2aWV3IG9mIHRoZSBjaGFydGVyDQp0
ZXh0IGJ5IHRoZSBJRVNHLg0KDQpXZSB3aWxsIHBvc3Qgc2VwYXJhdGUgbWFpbHMgb24gdGhlIGlu
ZGl2aWR1YWwgZG9jdW1lbnRzLiBZb3VyIGZlZWRiYWNrDQppcyBpbXBvcnRhbnQhIFBsZWFzZSB0
YWtlIHRoZSB0aW1lIHRvIGxvb2sgYXQgdGhlIGRvY3VtZW50cyBhbmQgcHJvdmlkZQ0KeW91ciBm
ZWVkYmFjay4NCg0KQ2lhbw0KSGFubmVzICYgRGVyZWsNCg0KX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0
Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQoNCk9BdXRoIG1haWxpbmcgbGlzdA0KDQpPQXV0aEBpZXRmLm9yZzxtYWls
dG86T0F1dGhAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGgNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0
Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls
aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN
CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OiJNYWxndW4gR290aGljIjsNCglwYW5vc2UtMToyIDExIDUgMyAyIDAgMCAyIDAgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1hbGd1biBHb3RoaWMiOw0KCXBhbm9zZS0xOjIg
MTEgNSAzIDIgMCAwIDIgMCA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h
bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l
dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt
cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N
CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt
YXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u
dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFs
MCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9y
bWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox
Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5IVE1M
UHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh
ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv
cm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1z
dHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVs
dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs
c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ
bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn
ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl
ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0
PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5OYXQsIEnigJltIGNv
bmZ1c2VkIGJ5IHRoaXMgc3RhdGVtZW50IGluIHRoZSBtZXNzYWdlIHlvdSByZWZlcmVuY2Ug4oCc
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5VbmZvcnR1
bmF0ZWx5LCB0aGlzIGRvZXMgbm90IG1hdGNoIHRoZSB2YWx1ZQ0KIG9mIE9BdXRoIGlzc3VlciBk
ZWZpbmVkIGluIFNlY3Rpb24gMiBvZiZuYnNwO2RyYWZ0LWpvbmVzLW9hdXRoLW1peC11cC1taXRp
Z2F0aW9uLTAxIG5vciB0aGUgJ2lzcycgcmV0dXJuZWQgYXMgc3BlY2lmaWVkIGluIDMuMS4mbmJz
cDtBcyBzdWNoLCB2YWxpZGF0aW9uIGFzIHNwZWNpZmllZCBpbiBidWxsZXQgMSBvZiBTZWN0aW9u
IDQgZmFpbHMgaW4gR29vZ2xlJ3MgY2FzZSAtLSBPUiBpdCBtZWFucyB0aGF0IHRoZSBkb2N1bWVu
dCBpcyBpbnRlcm5hbGx5IGluY29uc2lzdGVudC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMwMDIwNjAiPuKAnS4mbmJzcDsNCiBUaGUgaXNzdWVyIGRlZmluaXRpb24gaW4gZHJhZnQtam9u
ZXMtb2F1dGgtZGlzY292ZXJ5IGlzIDEwMCUgY29tcGF0aWJsZSB3aXRoIHRoZSBvbmUgaW4gT3Bl
bklEIENvbm5lY3QgRGlzY292ZXJ5LCBieSBkZXNpZ24uICZuYnNwO0luIHRoZSBHb29nbGUgZXhh
bXBsZSwgYm90aCB0aGUgT3BlbklEIGlzc3VlciBhbmQgdGhlIE9BdXRoIGlzc3VlciB2YWx1ZXMg
d291bGQgYmUgdGhlIHN0cmluZyDigJxodHRwczovL2FjY291bnRzLmdvb2dsZS5jb23igJ0uJm5i
c3A7IFdoYXQNCiBpcyB0aGUgaW5jb25zaXN0ZW5jeSB0aGF0IHlvdSBwZXJjZWl2ZT88bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoZSBkaXNjdXNzaW9uIG9mIHRo
ZSBkdXBsaWNhdGlvbiBwcm9ibGVtIGhhcHBlbmVkIGluIHRoZSBwcml2YXRlIG1lZXRpbmdzIGlu
IFlva29oYW1hLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSB3
aWxsIGFkbWl0LCBpbiBZb2tvaGFtYSwgSSBkaWRu4oCZdCBzcGVhayB1cCBpbiB0aGUgcHVibGlj
IG1lZXRpbmdzIHRvIHBvaW50IG91dCB0aGF0IGEgc2ltcGxlciBhbHRlcm5hdGl2ZSB0byBvYXV0
aC1tZXRhIHdhcyBhbHJlYWR5IGJlaW5nIGRpc2N1c3NlZCB0aGVyZSBpbg0KIHByaXZhdGUsIGJl
Y2F1c2UgdGhlbiBJIHdvdWxkIGhhdmUgaGFkIHRvIHRhbGsgYWJvdXQgdGhlIHNlY3VyaXR5IGlz
c3Vlcywgd2hpY2ggd2XigJlkIGRlY2lkZWQgbm90IHRvIHB1YmxpY2x5IGRvIGF0IHRoYXQgcG9p
bnQuJm5ic3A7IFNvIEkgc3RheWVkIHNpbGVudCBkdXJpbmcgdGhlIHBvbGwsIG91dCBvZiBwb2xp
dGVuZXNzLiZuYnNwOyBQZXJoYXBzIEkgc2hvdWxkIGhhdmUgZm91bmQgYSB3YXkgdG8gc2F5IHNv
bWV0aGluZyB0aGVuIGFueXdheSwgYnV0IHRoYXTigJlzDQogd2F0ZXIgdW5kZXIgdGhlIGJyaWRn
ZSBub3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5GaW5hbGx5
LCBmb3Igd2hhdCBpdOKAmXMgd29ydGgsIHRoZSBIQVRFT0FTIHN0dWZmIHJlbWluZHMgbWUgZmFy
IHRvbyBtdWNoIG9mIFdlYiBTZXJ2aWNlcyBEZXNjcmlwdGlvbiBMYW5ndWFnZSAoV1NETCkg4oCT
IHBhcnQgb2YgdGhlIGNvbXBsZXhpdHkgYmFnZ2FnZSB0aGF0IGhlbHBlZA0KIHNpbmsgV2ViIFNl
cnZpY2VzLiZuYnNwOyBUaGUgdXNlIG9mIOKAnGxpbmsgcmVs4oCdIHRvIGRlZmluZSBhbiBpbnRl
cmFjdGlvbiB2b2NhYnVsYXJ5IGFuZCBwdWJsaXNoIGVuZHBvaW50cyBmb3IgdGhhdCB2b2NhYnVs
YXJ5IHNlZW1zIHByZXR0eSBiYXJvcXVlIGFuZCByZW1pbmlzY2VudCBvZiDigJxtaWNyb2Zvcm1h
dHPigJ0g4oCTIGFub3RoZXIgY3V0ZSDigJxXZWJieeKAnSBpbm5vdmF0aW9uIHRoYXQgbmV2ZXIg
Y2F1Z2h0IG9uLiZuYnNwOyBUaGUgaW5kdXN0cnkgaGFzIHByZXR0eQ0KIG11Y2ggdm90ZWQgd2l0
aCBpdHMgZmVldCBhbmQgaXMgdXNpbmcgSlNPTiBmb3IgcHVibGlzaGluZyBkaXNjb3ZlcnkgZGF0
YSBzdHJ1Y3R1cmVzIOKAkyBub3Qg4oCcbGluayByZWzigJ0uJm5ic3A7IEkgYW0gYWdhaW5zdCB1
cyByZXZlcnRpbmcgdG8gdGhlIOKAnGxpbmsgcmVs4oCdIHByb3Bvc2FsIGZyb20gMjAwOCB0aGF0
IG5ldmVyIGNhdWdodCBvbiB3aGVuIEpTT04gaXMgc2ltcGxlciBhbmQgZG9lcyBhIGJldHRlciBq
b2IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBOYXQgU2FraW11cmEg
W21haWx0bzpzYWtpbXVyYUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXks
IEphbnVhcnkgMjEsIDIwMTYgNjoyNCBBTTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFJpY2hlciAm
bHQ7anJpY2hlckBtaXQuZWR1Jmd0OzsgTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNy
b3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gV2lsbGlhbSBEZW5uaXNzICZsdDt3ZGVubmlz
c0Bnb29nbGUuY29tJmd0OzsgJmx0O29hdXRoQGlldGYub3JnJmd0OyAmbHQ7b2F1dGhAaWV0Zi5v
cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0
aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlrZSwmbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBqdXN0IGNyaXRp
Y2l6ZSBteSBkcmFmdC4gVGhhdCdzIG9rLCBidXQgSSB3b3VsZCByZWFsbHkgbGlrZSB0byBnZXQg
c29tZSByZXNwb25zZSB0byBteSBxdWVzdGlvbnMgc3RhdGVkIGluJm5ic3A7PGEgaHJlZj0iaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDgz
Lmh0bWwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVu
dC9tc2cxNTQ4My5odG1sPC9hPiZuYnNwOy4NCiBUbyBtZSwgaXQganVzdCBkb2VzIG5vdCBzZWVt
IHRvIHdvcmssIGFuZCB0aGUgY29tYmluYXRpb24gb2YgdGhlIG9hdXRoLW1ldGEgYW5kIFBLQ0Ug
c2VlbXMgdG8gYmUgbXVjaCBtb3JlIGVsZWdhbiwgbmljZXIsIGFuZCBtdWNoIHNpbXBsZXIgdG8g
aW1wbGVtZW50LiBJZiB5b3UganVzdCBnaXZlIHVwIHRoZSBkeW5hbWljIHJlc3BvbnNlIGF0IHRo
ZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LCB0aGVuIHlvdSBldmVuIGRvIG5vdCBoYXZlIHRvIHRv
dWNoDQogdGhlIGNvZGUgYnV0IGp1c3QgY2hhbmdlIGEgY29uZmlnIGZpbGUuJm5ic3A7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBj
b252aW5jZSBtZSBieSBhbnN3ZXJpbmcgdG8gbXkgcXVlc3Rpb25zLiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgdGhlIHJlY29y
ZCBvZiBZb2tvaGFtYSwgSSBkbyBub3QgcmVjYWxsIG11Y2ggYWJvdXQgZHVwbGljYXRpb24gaW4g
T0F1dGggc2Vzc2lvbi4gVGhlIHBvbGwgaW4gdGhlIHJvb20gd2FzJm5ic3A7PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+MTkgZm9yIC8gemVybyBhZ2FpbnN0IC8gNCBw
ZXJzb25zIG5lZWQgbW9yZSBpbmZvcm1hdGlvbi4gSW5kZWVkLCBpdCBpcyBub3QgZHVwbGljYXRp
bmcNCiBtdWNoLiBBbmQgaWYgeW91IG1vdmUgdG8gYSBuZXcgbW9kZWwgd2l0aG91dCBwcmUtY29u
ZmlndXJlZCBkaXNjb3ZlcnksIGl0IGlzIG5vdCBkdXBsaWNhdGluZyBhbnkgYnV0IHRoZSByZXNv
dXJjZSBlbmRwb2ludCBVUkksIHdoaWNoIGlzIG9wdGlvbmFsIGFuZCBpcyBmb3IgdGhlIGNhc2Vz
IHdoZXJlIHRoZSBjbGllbnQgZGlkIG5vdCBrbm93IHRoZSBjb25jcmV0ZSByZXNvdXJjZSBlbmRw
b2ludCB0byBzdGFydCB3aXRoLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtjb2xvcjpibGFjayI+SSB1bmRlcnN0YW5kIHlvdXIgdXNlY2FzZXMgYWx3YXlzIHN0YXJ0IGZy
b20gYSBjb25jcmV0ZSBlbmRwb2ludCBsb2NhdGlvbi4gTWluZSBkbyBub3QuIEluIGEgZm91ciBw
YXJ0eSBtb2RlbCwgaXQgaXMgbGlrZWx5IG5vdC4gVGhlIHVzZXIganVzdCB3YW50IHRvIGhhdmUg
dGhlIHNlcnZpY2UgdG8gZmV0Y2ggaGlzIGRhdGEgZnJvbSBzb21lDQogcmVzb3VyY2UgZW5kcG9p
bnQuIEhlIGp1c3QgaGl0cyB0aGUgc2VydmljZS4gSGUgZG9lcyBub3QgaGl0IHRoZSByZXNvdXJj
ZSBlbmRwb2ludCBkaXJlY3RseS4gRm9yIGV4YW1wbGUsIGluIHRoZSBjYXNlIG9mIGEgY29uc3Vt
ZXIgdXNpbmcgYSBwZXJzb25hbCBmaW5hbmNlIHBsYXRmb3JtIChQRlApdG8gbWFuYWdlIGhpcyBw
ZW5zaW9uIGZ1bmQsIGhlIGhpdHMgdGhlIFBGUCBhbmQgbm90IHRoZSBQZW5zaW9uIGZ1bmQuIEFz
c3VtaW5nIHRoYXQgdGhlDQogcGVuc2lvbiBmdW5kIGhhcyBkZWxlZ2F0ZWQgdGhlIGF1dGhvcml6
YXRpb24gY29udHJvbCB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIHRoZW4sIHRoZSBhdXRo
b3JpemF0aW9uIHNlcnZlciBzaG91bGQgcmV0dXJuIGJvdGggdGhlIGFjY2VzcyB0b2tlbiBhbmQg
dGhlIGVuZHBvaW50IG9mIHRoZSBwZW5zaW9uIGZ1bmQgc28gdGhhdCB0aGUgUEZQIGNhbiBwdWxs
IHRoZSBkYXRhIHVzaW5nIHRoZW0uIEEgc2ltaWxhciBtb2RlbCBob2xkcyBmb3INCiBwZXJzb25h
bCBoZWFsdGggc2VydmljZSBhbmQgaGVhbHRoIGNhcmUgcHJvdmlkZXJzLiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+QmVzdCwmbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5h
dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjIwMTY8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90Oyxz
YW5zLXNlcmlmIj7lubQ8L3NwYW4+MTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxn
dW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuaciDwvc3Bhbj4yMTxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuaXpTwvc3Bhbj4o
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1z
ZXJpZiI+5pyoPC9zcGFuPikNCiAyMToxOCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWls
dG86anJpY2hlckBtaXQuZWR1Ij5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0Ozo8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db252
ZXJnZW5jZSBpcyBleGFjdGx5IHdoYXQgSeKAmW0gYXJndWluZyBmb3IsIHRob3VnaC4gVGhlc2Ug
dGhpbmdzIG91Z2h0IHRvIHdvcmsgdG9nZXRoZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDvigJQgSnVzdGluPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5PbiBKYW4gMjEsIDIwMTYsIGF0IDI6NTUgQU0sIE1pa2UgSm9uZXMgJmx0OzxhIGhy
ZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5N
aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMDAyMDYwIj5NeSBtZW1vcnkgb2YgdGhlIGRpc2N1c3Npb25zIG9mIHRoZSBvYXV0aC1t
ZXRhIGRyYWZ0IGluIFlva29oYW1hIHdlcmUgdGhhdCBtYW55IHBlb3BsZSBmZWx0IHRoYXQgaXQN
CiB3YXMgdW5uZWNlc3NhcmlseSBkeW5hbWljYWxseSBkdXBsaWNhdGluZyBhIGxvdCBvZiBpbmZv
cm1hdGlvbiB0aGF0IHRoZSBjbGllbnQgYWxyZWFkeSBoYWQuJm5ic3A7IE1vc3Qgb2YgdXMgdGhh
dCB3ZXJlIGF3YXJlIG9mIHRoZSBhdHRhY2tzIHRoZW4gd2VyZSBpbiBmYXZvciBvZiBhIG1vcmUg
dGFyZ2V0ZWQsIG1pbmltYWwgYXBwcm9hY2guJm5ic3A7IFlvdSB3ZXJlIGxpc3RlbmVkIHRvIGlu
IFlva29oYW1hLCBidXQgdGhhdCBkaWRu4oCZdCBuZWNlc3NhcmlseSBtZWFuDQogdGhhdCBwZW9w
bGUgYWdyZWVkIHdpdGggdGhlIGFwcHJvYWNoLiZuYnNwOyBQYXJ0aWNpcGFudHMgd2VyZSBhbHJl
YWR5IGF3YXJlIG9mIHRoZSBvYXV0aC1tZXRhIHByb3Bvc2FsIGluIERhcm1zdGFkdCBidXQgbm8g
b25lIHNwb2tlIHVwIGluIGZhdm9yIG9mIGl0IHRoYXQgSSBjYW4gcmVjYWxsLiZuYnNwOyBSYXRo
ZXIsIEkgdGhpbmsgcGVvcGxlIHdlcmUgdGhpbmtpbmcgdGhhdCDigJxsZXNzIGlzIG1vcmXigJ0u
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhlcmUgaGF2
ZSBhbHNvIGJlZW4gZGlzY3Vzc2lvbnMgaW4gdGhlIGxhc3QgZGF5IGFib3V0IGhvdyBkeW5hbWlj
YWxseSByZXR1cm5pbmcgYSByZXNvdXJjZSBVUkwsIHdoaWNoDQogb2F1dGgtbWV0YSBkb2VzLCBp
cyBib3RoIHVubmVjZXNzYXJ5IChzaW5jZSB0aGUgY2xpZW50IGluaXRpYXRlZCB0aGUgcmVzb3Vy
Y2UgYXV0aG9yaXphdGlvbiBhbHJlYWR5IGtub3dpbmcgd2hhdCByZXNvdXJjZSBpdCB3YW50cyB0
byBhY2Nlc3MpIGFuZCBvZnRlbiBwcm9ibGVtYXRpYywgc2luY2UgbWFueSBhdXRob3JpemF0aW9u
IHNlcnZlcnMgY2FuIGF1dGhvcml6ZSBhY2Nlc3MgdG8gbXVsdGlwbGUgcmVzb3VyY2VzLiZuYnNw
OyBJZiBhbnl0aGluZywNCiB0aGUgY2xpZW50IHNob3VsZCBiZSB0ZWxsaW5nIHRoZSBhdXRob3Jp
emF0aW9uIHNlcnZlciB3aGF0IHJlc291cmNlIGl0IHdhbnRzIHRvIGFjY2VzcyDigJMgbm90IHRo
ZSBvdGhlciB3YXkgYXJvdW5kLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMwMDIwNjAiPknigJltIG5vdCBzYXlpbmcgdGhhdCB0aGVyZSBhcmVu4oCZdCBzb21lIGdvb2Qg
aWRlYXMgaW4gdGhlIG9hdXRoLW1ldGEgZHJhZnQg4oCTIEnigJltIHN1cmUgdGhlcmUgYXJlLCBq
dXN0DQogYXMgdGhlcmUgYXJlIGluIHRoZSBhcHByb2FjaCBkZXNpZ25lZCBieSB0aGUgcGFydGlj
aXBhbnRzIGluIERhcm1zdGFkdC4mbmJzcDsgV2hpbGUgSSB2b2x1bnRlZXJlZCB0byB3cml0ZSB0
aGUgZmlyc3QgZHJhZnQgb2YgdGhlIG1peC11cC1taXRpZ2F0aW9uIGFwcHJvYWNoLCBpdCByZWFs
bHkgcmVmbGVjdHMgc29tZXRoaW5nIGEgbG90IG9mIHBlb3BsZSBoYXZlIGFscmVhZHkgYm91Z2h0
IGludG8g4oCTIGFzIGV2aWRlbmNlZCBpbiB0aGUgcGFzc2lvbiBpbg0KIHRoZSBoaWdoLXZvbHVt
ZSDigJxNaXgtVXAgQWJvdXQgVGhlIE1peC1VcCBNaXRpZ2F0aW9u4oCdIHRocmVhZCwgYW5kIG5v
dCBqdXN0IG15IHBlcnNvbmFsIHByb2plY3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzAwMjA2MCI+SWYgeW91IHRoaW5rIHRoZXJlIGFyZSB0aGluZ3MgbWlzc2luZyBv
ciB3cm9uZyBpbiB0aGUgbWl4LXVwLW1pdGlnYXRpb24gZHJhZnQsIHBsZWFzZSBzYXkgd2hhdCB0
aGV5DQogYXJlLiZuYnNwOyBUaGF0IHdpbGwgaGVscCB1cyBxdWlja2x5IGNvbnZlcmdlIG9uIGEg
c29sdXRpb24gdGhhdCB3aWxsIHdvcmsgZm9yIGV2ZXJ5b25lLjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTaW5jZXJlbHksPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2
MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IC0tIE1pa2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxhIG5hbWU9Im1zZy1mOjE1MjM5NzgwMTQ1Mjk2NTY3NjdfX01haWxFbmRDb21wb3MiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu
PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBOYXQgU2FraW11cmEgWzxhIGhyZWY9Im1haWx0bzpzYWtp
bXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c2FraW11cmFAZ21haWwuY29t
PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjAsIDIwMTYgMTE6
MTcgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNo
YWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1p
Y3Jvc29mdC5jb208L2E+Jmd0OzsgV2lsbGlhbSBEZW5uaXNzICZsdDs8YSBocmVmPSJtYWlsdG86
d2Rlbm5pc3NAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndkZW5uaXNzQGdvb2dsZS5jb208
L2E+Jmd0OzsgSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVk
dSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i
PiA8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBp
ZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3Ig
QWRvcHRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgTWlr
ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5Db252ZXJzZWx5LCBJIHdvdWxkIGxpa2UgdG8gYXNrIHdoeSB0aGlzIGFwcHJvYWNoIGRvZXMg
bm90IHdvcmsgZm9yIE1peC11cCBhdHRhY2suJm5ic3A7QXMgTm92IHN0YXRlZCwgd2UgaW4gZmFj
dCBoYXZlIGRpc2N1c3NlZCB0aGUgYXBwcm9hY2ggaW4gcXVpdGUgYSBsZW5ndGggYmFjayBpbiBZ
b2tvaGFtYS4gSSByZWFsbHkNCiB3b3VsZCBsaWtlIHRvIGtub3cgd2h5IGl0IGRvZXMgbm90IHdv
cmsuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj5CZXNpZGVzLCBmb3Igb2F1dGgtbWV0YSBhcHByb2FjaCwgbWl4LXVwIGF0dGFj
ayBpcyBvbmx5IG9uZSBvZiB0aGUgdGhpbmcgaXQgc29sdmVzLiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TmF0IFNha2ltdXJh
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij4yMDE2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDss
c2Fucy1zZXJpZiI+5bm0PC9zcGFuPjE8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFs
Z3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+MjE8c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7ml6U8L3NwYW4+
KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMt
c2VyaWYiPuacqDwvc3Bhbj4pDQogMTY6MDIgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRv
Ok1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx
dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw
YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Tm90
IHRvIGJlIG5lZ2F0aXZlLCBidXQgSSBkaXNhZ3JlZSB3aXRoIGFkb3B0aW5nIGRyYWZ0LXNha2lt
dXJhLW9hdXRoLW1ldGEuJm5ic3A7IFdlIHNob3VsZCBkZWZpbmUgYW5kIHByb21vdGUNCiBvbmUg
bWl0aWdhdGlvbiBhcHByb2FjaCB0byB0aGUgbWl4LXVwIGF0dGFja3MuJm5ic3A7IEhhdmluZyB0
d28gd291bGQgY29uZnVzZSBpbXBsZW1lbnRlcnMgYW5kIGNhdXNlIGNvbXBhdGliaWxpdHkgcHJv
YmxlbXMg4oCTIHJlZHVjaW5nIG92ZXJhbGwgc2VjdXJpdHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+
Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhlIGFwcHJvYWNoIGRlZmluZWQgaW4gZHJhZnQt
am9uZXMtb2F1dGgtbWl4LXVwLW1pdGlnYXRpb24gd2FzIGNyZWF0ZWQgaW4gY29sbGFib3JhdGlv
biB3aXRoIHRoZSBzZWN1cml0eQ0KIHJlc2VhcmNoZXJzIHdobyBpZGVudGlmaWVkIHRoZSBwcm9i
bGVtcyBpbiB0aGUgZmlyc3QgcGxhY2UsIHdhcyB2aWdvcm91c2x5IGRpc2N1c3NlZCBpbiB0aGUg
c2VjdXJpdHkgbWVldGluZyBIYW5uZXMgYW5kIFRvcnN0ZW4gaGVsZCBpbiBEYXJtc3RhZHQsIGFu
ZCBoYXMgYmVlbiBzaW5jZSByZWZpbmVkIGJhc2VkIG9uIHN1YnN0YW50aWFsIGlucHV0IGZyb20g
dGhlIHdvcmtpbmcgZ3JvdXAuJm5ic3A7IEFuZCBhdCBsZWFzdCB0aHJlZSBpbXBsZW1lbnRlcnMN
CiBoYXZlIGFscmVhZHkgc3RhdGVkIHRoYXQgdGhleeKAmXZlIGltcGxlbWVudGVkIGl0LiZuYnNw
OyBJ4oCZbSBub3Qgc2F5aW5nIHRoYXQgaXTigJlzLCBidXQgaWYgdGhlcmUgYXJlIHRoaW5ncyBt
aXNzaW5nIG9yIHRoaW5ncyB0aGF0IG5lZWQgdG8gYmUgaW1wcm92ZWQgaW4gb3VyIGFwcHJvYWNo
LCB3ZSBzaG91bGQgZG8gaXQgdGhlcmUsIHJhdGhlciBpbnRyb2R1Y2luZyBhIGNvbXBldGluZyBh
cHByb2FjaC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5B
bHNvLCBzdGFuZGFyZCBPQXV0aCBkZXBsb3ltZW50cyByZWdpc3RlciB0aGUgY2xpZW50IGFuZCB0
aGVuIHVzZSB0aGUgaW5mb3JtYXRpb24gZ2F0aGVyZWQgYXQgcmVnaXN0cmF0aW9uDQogdGltZSBm
b3Igc3Vic2VxdWVudCBwcm90b2NvbCBpbnRlcmFjdGlvbnMuJm5ic3A7IFRoZXkgZG8gbm90IG5l
ZWQgYWxsIHRoZSBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGZvciB0aGUgYXV0aG9yaXphdGlv
biBzZXJ2ZXIgdG8gYmUgcmV0cmFuc21pdHRlZCBhdCBydW50aW1lLiZuYnNwOyBUaGUgb2F1dGgt
bWV0YSBkcmFmdCBnb2VzIHRvbyBmYXIgaW4gdGhhdCBkaXJlY3Rpb24sIGF0IGxlYXN0IGFzIEkg
c2VlIGl0LiZuYnNwOyBSZXR1cm5pbmcgdGhpbmdzIHR3byB3YXlzDQogY3JlYXRlcyBpdHMgb3du
IHByb2JsZW1zLCBhcyBkaXNjdXNzZWQgaW4gdGhlIER1cGxpY2F0ZSBJbmZvcm1hdGlvbiBBdHRh
Y2tzIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gKDcuMikgb2YgdGhlIG1peC11cC1t
aXRpZ2F0aW9uIGRyYWZ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw
MDIwNjAiPknigJlsbCBub3RlIHRoYXQgdGhlIG1peC11cC1taXRpZ2F0aW9uIGFwcHJvYWNoIGlz
IGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBwcmFjdGljZSBpbiBib3RoIHN0YXRpYyBhbmQNCiBk
eW5hbWljIG1ldGFkYXRhIGRpc2NvdmVyeS4mbmJzcDsgUmVwbHlpbmcgdG8gSnVzdGlu4oCZcyBj
b21tZW50IHRoYXQg4oCcPC9zcGFuPkl0J3MgdGhlIHByZS1jb25maWd1cmVkIGRpc2NvdmVyeSBk
b2N1bWVudCB0aGF0J3MgYXQgdGhlIHJvb3Qgb2YgdGhlIG1peC11cCBhdHRhY2sgaW4gdGhlIGZp
cnN0IHBsYWNlPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPuKAnSDigJMgdGhpcw0KIGlz
IG5vdCB0aGUgY2FzZS4mbmJzcDsgVGhlIGF0dGFja3MgY2FuIGJlIHBlcmZvcm1lZCB3aXRob3V0
IGVpdGhlciBkaXNjb3Zlcnkgb3IgZHluYW1pYyByZWdpc3RyYXRpb24uPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAw
MjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+SSB3b3VsZCBiZSBpbnRlcmVzdGVkIGlu
IGhlYXJpbmcgYSB0ZWNobmljYWwgZGlzY3Vzc2lvbiBvbiB3aGV0aGVyIHRoZXJlIGFyZSBhc3Bl
Y3RzIG9mIHRoZSBvYXV0aC1tZXRhDQogYXBwcm9hY2ggdGhhdCBtaXRpZ2F0ZSBhc3BlY3RzIG9m
IHRoZSBhdHRhY2tzIHRoYXQgdGhlIG1peC11cC1taXRpZ2F0aW9uIGFwcHJvYWNoIGRvZXMgbm90
LiZuYnNwOyBUaGF0IGNvdWxkIGhlbHAgaW5mb3JtIHdoZXRoZXIgdGhlcmUgYXJlIGFkZGl0aW9u
YWwgdGhpbmdzIHdlIHNob3VsZCBhZGQgdG8gb3IgY2hhbmdlIGluIHRoZSBtaXgtdXAgZHJhZnQu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1z
Zy1mOjE1MjM5NzgwMTQ1Mjk2NTY3NjdfbXNnLWY6MTUyMzk1ODEiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPiBPQXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P
biBCZWhhbGYgT2YgPC9iPldpbGxpYW0gRGVubmlzczxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk
YXksIEphbnVhcnkgMjAsIDIwMTYgMTA6MzcgUE08YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBSaWNo
ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5q
cmljaGVyQG1pdC5lZHU8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9h
dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+
U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9uPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPiYjNDM7MSB0byBhZG9wdCB0aGlzLCBhbmQgSSBhZ3JlZSB3aXRoIEp1c3RpbidzIGNvbW1l
bnRzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7
PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEph
biAyMCwgMjAxNiBhdCA5OjUzIFBNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86
anJpY2hlckBtaXQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsg
d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h
cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiYjNDM7MTxicj4N
Cjxicj4NCklubGluZSBkaXNjb3ZlcnkgYW5kIHByZS1jb25maWd1cmVkIGRpc2NvdmVyeSAoaWUs
IC53ZWxsLWtub3duKSBzaG91bGQgYXQgdGhlIHZlcnkgbGVhc3QgYmUgY29tcGF0aWJsZSBhbmQg
ZGV2ZWxvcGVkIHRvZ2V0aGVyLiBJdCdzIHRoZSBwcmUtY29uZmlndXJlZCBkaXNjb3ZlcnkgZG9j
dW1lbnQgdGhhdCdzIGF0IHRoZSByb290IG9mIHRoZSBtaXgtdXAgYXR0YWNrIGluIHRoZSBmaXJz
dCBwbGFjZS48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KJm5ic3A7LS0g
SnVzdGluPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w
cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
T24gMS8xOS8yMDE2IDEwOjMwIFBNLCBOYXQgU2FraW11cmEgd3JvdGU6PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SnVzdCB0byBnaXZlIG1v
cmUgY29udGV4dCwgYXQgSUVURiA5NCwgSSBoYXZlIGRvbmUgYSBwcmVzZW50YXRpb24gb24gZGlz
Y292ZXJ5LiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+QWNjb3JkaW5nIHRvIHRoZSBtaW51dGVzLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7IChmKSBEaXNjb3ZlcnkgKE5hdCk8L3NwYW4+PG86cD48L286cD48L3By
ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDtOYXQgZXhwbGFpbnMgaGlzIGRvY3VtZW50IGFzIGFuIGV4YW1wbGUgb2YgdGhlIHdvcmsg
dGhhdCBoYXMgdG8gYmUgZG9uZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW4gdGhlIGFyZWEgb2YgZGlz
Y292ZXJ5LCB3aGljaCBpcyBhIHRvcGljIHRoYXQgaGFzIGJlZW4gaWRlbnRpZmllZDwvc3Bhbj48
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgYXMgbmVjZXNzYXJ5IGZvciBpbnRlcm9wZXJhYmlsaXR5IHNpbmNlIG1hbnkg
eWVhcnMgYnV0IHNvIGZhciB0aGVyZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2FzIG5vdCB0aW1lIHRv
IHdvcmsgb24gaXQuIE1pa2UsIEpvaG4gYW5kIE5hdCBhcmUgd29ya2luZyBvbiBhIG5ldzwvc3Bh
bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgYWRkaXRpb25hbCBkaXNjb3Zl
cnktcmVsZXZhbnQgY29tcG9uZW50cy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtQb2xsOiAx
OSBmb3IgLyB6ZXJvIGFnYWluc3QgLyA0IHBlcnNvbnMgbmVlZCBtb3JlIGluZm9ybWF0aW9uLjwv
c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3Nw
YW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGRvY3VtZW50
IGRpc2N1c3NlZCB0aGVyZSB3YXMNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA1IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wNTwvYT4uIFRo
aXMgaXMgYSBzaW1wbGUgKG9ubHkgMS1wYWdlISkgYnV0IGEgdmVyeSBwb3dlcmZ1bCBkb2N1bWVu
dCB0aGF0IG51ZGdlcyB0b3dhcmRzIEhBVEVPQVMgd2hpY2ggaXMgYXQgdGhlIGNvcmUgb2YgUkVT
VGZ1bC1uZXNzLiBJdCBhbHNvIG1pdGlnYXRlcyB0aGUgTWl4LXVwIGF0dGFjayB3aXRob3V0IGlu
dHJvZHVjaW5nIHRoZSBjb25jZXB0DQogb2YgaXNzdWVyIHdoaWNoIGlzIG5vdCBpbiBSRkM2NzQ5
LiBJdCBpcyBhbHNvIGdvb2QgZm9yIHNlbGVjdGluZyBkaWZmZXJlbnQgZW5kcG9pbnRzIGRlcGVu
ZGluZyBvbiB0aGUgdXNlciBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiByZXN1bHRz
IGFuZCBtb3JlIHByaXZhY3kgc2Vuc2l0aXZlIHRoYW4gcHJlLWFubm91bmNlZCBEaXNjb3Zlcnkg
ZG9jdW1lbnQuIEl0IGFsc28gYWxsb3dzIHlvdSB0byBmaW5kIHRvIHdoaWNoIHByb3RlY3RlZA0K
IHJlc291cmNlIGVuZHBvaW50IHlvdSBjYW4gdXNlIHRoZSBhY2Nlc3MgdG9rZW4gYWdhaW5zdC4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
SW4gdGhlIGxhc3Qgc2VudGVuY2Ugb2YgdGhlIG1pbnV0ZXMsIGl0IHRhbGtzIGFib3V0ICZxdW90
O2EgbmV3IGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIGFkZGl0aW9uYWwgZGlzY292ZXJ5LXJlbGV2
YW50IGNvbXBvbmVudHMmcXVvdDsuIFRoaXMgaXMmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5LTAwIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLWRpc2Nv
dmVyeS0wMDwvYT4uJm5ic3A7DQogSXQgd2VudCBmb3IgdGhlIGNhbGwgZm9yIGFkb3B0aW9uLiBI
b3dldmVyLCBpdCBpcyBvbmx5IGEgaGFsZiBvZiB0aGUgc3RvcnkuIEkgYmVsaWV2ZSZuYnNwOzxh
IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1t
ZXRhLTA1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LXNha2ltdXJhLW9hdXRoLW1ldGEtMDU8L2E+Jm5ic3A7dGhhdCB3YXMgZGlzY3Vzc2VkIGF0IElF
VEYNCiA5NCBhbmQgaGFkIHN1cHBvcnQgdGhlcmUmbmJzcDtzaG91bGQgYmUgYWRvcHRlZCBhcyB3
ZWxsLiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj5OYXQgU2FraW11cmE8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIwMTY8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7lubQ8L3NwYW4+MTxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYi
PuaciDwvc3Bhbj4yMDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGlj
JnF1b3Q7LHNhbnMtc2VyaWYiPuaXpTwvc3Bhbj4oPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5rC0PC9zcGFuPikNCiAxMjowNSBO
YXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdl
dD0iX2JsYW5rIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND
Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgSGFubmVzLiZuYnNwOw0KPG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBkaWQgbm90IGZp
bmQmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11
cmEtb2F1dGgtbWV0YS0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA1PC9hPiwmbmJzcDt3aGljaCB3YXMgZGlz
Y3Vzc2VkDQogaW4gWW9rb2hhbWEsIGFuZCB3YXMgbGFyZ2VseSBpbiBhZ3JlZW1lbnQgaWYgbXkg
cmVjb2xsZWN0aW9uIGlzIGNvcnJlY3QuIFdoeSBpcyBpdCBub3QgaW4gdGhlIGNhbGwgZm9yIGFk
b3B0aW9uPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4yMDE2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5bm0PC9zcGFuPjE8c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7mnIg8L3Nw
YW4+MTk8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90Oyxz
YW5zLXNlcmlmIj7ml6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxn
dW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPueBqzwvc3Bhbj4pDQogMjA6MzkgSGFubmVzIFRz
Y2hvZmVuaWcgJmx0OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0IiB0
YXJnZXQ9Il9ibGFuayI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7OjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGlu
IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBp
bjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgYWxsLDxi
cj4NCjxicj4NCndlIGhhdmUgc3VibWl0dGVkIG91ciBuZXcgY2hhcnRlciB0byB0aGUgSUVTRyAo
c2VlPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29h
dXRoL2N1cnJlbnQvbXNnMTUzNzkuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0
Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1Mzc5Lmh0bWw8L2E+KSBh
bmQ8YnI+DQpzaW5jZSBzb21lIElFU0cgbWVtYmVycyBsaWtlIHRvIHNlZSBhbiB1cGRhdGVkIGxp
c3Qgb2YgbWlsZXN0b25lcyBhczxicj4NCndlbGwuIEZvciB0aGlzIHJlYXNvbiwgYmFzZWQgb24g
YSBzdWdnZXN0aW9uIGZyb20gQmFycnksIHdlIGFyZSBhbHNvPGJyPg0Kc3RhcnRpbmcgYSBjYWxs
IGZvciBhZG9wdGlvbiBjb25jdXJyZW50bHkgd2l0aCB0aGUgcmV2aWV3IG9mIHRoZSBjaGFydGVy
PGJyPg0KdGV4dCBieSB0aGUgSUVTRy48YnI+DQo8YnI+DQpXZSB3aWxsIHBvc3Qgc2VwYXJhdGUg
bWFpbHMgb24gdGhlIGluZGl2aWR1YWwgZG9jdW1lbnRzLiBZb3VyIGZlZWRiYWNrPGJyPg0KaXMg
aW1wb3J0YW50ISBQbGVhc2UgdGFrZSB0aGUgdGltZSB0byBsb29rIGF0IHRoZSBkb2N1bWVudHMg
YW5kIHByb3ZpZGU8YnI+DQp5b3VyIGZlZWRiYWNrLjxicj4NCjxicj4NCkNpYW88YnI+DQpIYW5u
ZXMgJmFtcDsgRGVyZWs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h
aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxi
cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi
IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cHJl
Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286
cD48L3ByZT4NCjxwcmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+
PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0
Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwv
YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGlu
ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu
ayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv
dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0
aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_BY2PR03MB442DE057967872C63A56DF8F5C40BY2PR03MB442namprd_--


From nobody Thu Jan 21 18:08:16 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C24D1B3606 for ; Thu, 21 Jan 2016 18:08:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmSe7Ob0jtOh for ; Thu, 21 Jan 2016 18:08:08 -0800 (PST)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 0CA7E1B3605 for ; Thu, 21 Jan 2016 18:08:08 -0800 (PST)
Received: by mail-qg0-x230.google.com with SMTP id 6so47451003qgy.1 for ; Thu, 21 Jan 2016 18:08:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=0vQA8n+PTUHp1yDiQD/xEcTMK4G4VciZjBAZD9o9Q0o=; b=BGcpq/mAzfrFY/dfAv7pqIPGg9QT4yIrRZoa6NbMB/6UiqMq1HU0P6pTgu0WqX/4SR yXxIEaI3Dz2+yArJ7LW3l698TELE4Tos+vLUHdjX3LQ3en1jyAB3wo704ssgARNlvIdb O707vnoz5ChqFUWHG5jddVXT9uoLwFeOupEtGIgCeVnrWj49FTpxutHaz4dRVxtxkJLG Jupv9sSiNB8u3uFvTQKWSP1NH2B9akpXP18Kf8qWxS8/4TYoj+0yqtjnU8dfQmxsAol8 7KCFshiDQHHQcaaxlVAea3nXQS2g+QqTrF/kfvs437Ngs2h7wBKpSVFxcC/H0gFYdIfD 5D+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=0vQA8n+PTUHp1yDiQD/xEcTMK4G4VciZjBAZD9o9Q0o=; b=lLqq5CKX2ho/8STJ+jmhUvsl3fMr+BUqnSYB2IfbXK/cwnYLnYtsX40dsqXjYKyetN H9GHQK+ClD/nfOMQ93U2/ltWd85p2ZesiFSxoC7ZSmPlzNEckxy28//SqRWie5Y/04i5 l1sMOG2y/lKfOJQlhul6Cbe+gj58FNrNoT+oA9ZJukSp9usj54CmgHPMdb8sFA4FMSfW NIcglLfRPk7BXRRiy8t8yEj+ufHOsba1JaXfPpv0xRiO9w524YV1cW80D+nhY9axiW1U 6rmQBgatRqlc12uM1/s9CJOm6/AS4LNG4HqFh6565Afgj2JAmEtXrf77A3Ziqb+rZxo3 xPGQ==
X-Gm-Message-State: AG10YOQURnYfhPb2uXC7a27OuElUyY85Xjm90cHnzhUgshhUSLQKadqGidOl7jRI+uUHEg7pvBJ39Ee0GutrKw==
X-Received: by 10.140.180.80 with SMTP id b77mr598154qha.67.1453428487146; Thu, 21 Jan 2016 18:08:07 -0800 (PST)
MIME-Version: 1.0
References: <569E2076.2090405@gmx.net>   <569F915D.8020806@mit.edu>       
In-Reply-To: 
From: Nat Sakimura 
Date: Fri, 22 Jan 2016 02:07:56 +0000
Message-ID: 
To: Mike Jones , Justin Richer 
Content-Type: multipart/alternative; boundary=001a113a7e3caed6010529e2b098
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 02:08:14 -0000

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

Re: iss. I discussed this a bit with Nov in more details. It probably is a
sloppy language of the specs that is making it difficult to read what you
wanted to achieve.

In mix-up-mitigation draft, OAuth issuer is "the URL of the authorization
server's configuration information location". In OAuth discovery draft,
there is something called "OAuth 2.0 Configuration Information Location
URL", which is equal to "OpenID Connect Issuer".

When I wrote the statement, I thought you were pointing to the URL that you
can actually pull the configuration information by "the URL of the
authorizaiton server's configuration information location" since otherwise
you would have used the term "OAuth 2.0 Configuration Information Location
URL". But after all, you probably meant these two are the same. Then I
would strongly recommend to fix the language.

Now, even If that is the case, the relationship like

   - iss + .well-know/openid-configuration =3D Connect OP config endoint
   - OAuth config endpoint - .well-known/openid-configuration =3D OAuth iss

is very confusing.

You also claim that your approach is simpler, but to me, your approach seem
to be overly complex. It requires discovery and the check for the value of
the discovered config information to work as the mitigation. (Right. Draft
-01 does not have it, so it does not solve the mix-up issue.) With
oauth-meta, you do not need it.

Finally, your point that HATEOAS reminds you of WSDL, it is not. If you
want to have something similar to WSDL in REST API area, it is Swagger.
(Actually, it is gaining a lot of momentum recently, but that's beside the
fact ;-). And the point here is not the format but the fact that we need to
have a way to associate metadata to the data. The root cause of this mix-up
attack is that the metadata and data is not associated properly. We have a
standard way of associating the data and metadata with link-rel such as
RFC5988 so why not use it? Link-rel-href pattern is used a lot now. Most
modern web pages actually have it. Using a proper way to associate metadata
with data will save you from a lot of other attacks in the future. Instead
of doing patch works, we should solve it architecturally.

Nat



2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 10:34 Mike Jones :

> Nat, I=E2=80=99m confused by this statement in the message you reference =
=E2=80=9CUnfortunately,
> this does not match the value of OAuth issuer defined in Section 2
> of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as
> specified in 3.1. As such, validation as specified in bullet 1 of Section=
 4
> fails in Google's case -- OR it means that the document is internally
> inconsistent.=E2=80=9D.  The issuer definition in draft-jones-oauth-disco=
very is
> 100% compatible with the one in OpenID Connect Discovery, by design.  In
> the Google example, both the OpenID issuer and the OAuth issuer values
> would be the string =E2=80=9Chttps://accounts.google.com=E2=80=9D.  What =
is the
> inconsistency that you perceive?
>
>
>
> The discussion of the duplication problem happened in the private meeting=
s
> in Yokohama.
>
>
>
> I will admit, in Yokohama, I didn=E2=80=99t speak up in the public meetin=
gs to
> point out that a simpler alternative to oauth-meta was already being
> discussed there in private, because then I would have had to talk about t=
he
> security issues, which we=E2=80=99d decided not to publicly do at that po=
int.  So I
> stayed silent during the poll, out of politeness.  Perhaps I should have
> found a way to say something then anyway, but that=E2=80=99s water under =
the bridge
> now.
>
>
>
> Finally, for what it=E2=80=99s worth, the HATEOAS stuff reminds me far to=
o much of
> Web Services Description Language (WSDL) =E2=80=93 part of the complexity=
 baggage
> that helped sink Web Services.  The use of =E2=80=9Clink rel=E2=80=9D to =
define an
> interaction vocabulary and publish endpoints for that vocabulary seems
> pretty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=
=93 another cute =E2=80=9CWebby=E2=80=9D
> innovation that never caught on.  The industry has pretty much voted with
> its feet and is using JSON for publishing discovery data structures =E2=
=80=93 not
> =E2=80=9Clink rel=E2=80=9D.  I am against us reverting to the =E2=80=9Cli=
nk rel=E2=80=9D proposal from 2008
> that never caught on when JSON is simpler and does a better job.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Nat Sakimura [mailto:sakimura@gmail.com]
> *Sent:* Thursday, January 21, 2016 6:24 AM
> *To:* Justin Richer ; Mike Jones <
> Michael.Jones@microsoft.com>
> *Cc:* William Denniss ;  <
> oauth@ietf.org>
>
>
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>
> Mike,
>
>
>
> You just criticize my draft. That's ok, but I would really like to get
> some response to my questions stated in
> https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To
> me, it just does not seem to work, and the combination of the oauth-meta
> and PKCE seems to be much more elegan, nicer, and much simpler to
> implement. If you just give up the dynamic response at the authorization
> endpoint, then you even do not have to touch the code but just change a
> config file.
>
>
>
> Please convince me by answering to my questions.
>
>
>
> For the record of Yokohama, I do not recall much about duplication in
> OAuth session. The poll in the room was 19 for / zero against / 4 persons
> need more information. Indeed, it is not duplicating much. And if you mov=
e
> to a new model without pre-configured discovery, it is not duplicating an=
y
> but the resource endpoint URI, which is optional and is for the cases whe=
re
> the client did not know the concrete resource endpoint to start with.
>
>
>
> I understand your usecases always start from a concrete endpoint location=
.
> Mine do not. In a four party model, it is likely not. The user just want =
to
> have the service to fetch his data from some resource endpoint. He just
> hits the service. He does not hit the resource endpoint directly. For
> example, in the case of a consumer using a personal finance platform
> (PFP)to manage his pension fund, he hits the PFP and not the Pension fund=
.
> Assuming that the pension fund has delegated the authorization control to
> the authorization server, then, the authorization server should return bo=
th
> the access token and the endpoint of the pension fund so that the PFP can
> pull the data using them. A similar model holds for personal health servi=
ce
> and health care providers.
>
>
>
> Best,
>
>
>
> Nat
>
>
>
>
>
> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 21:18 Justin Richer :
>
> Convergence is exactly what I=E2=80=99m arguing for, though. These things=
 ought to
> work together.
>
>
>
>  =E2=80=94 Justin
>
>
>
> On Jan 21, 2016, at 2:55 AM, Mike Jones 
> wrote:
>
>
>
> My memory of the discussions of the oauth-meta draft in Yokohama were tha=
t
> many people felt that it was unnecessarily dynamically duplicating a lot =
of
> information that the client already had.  Most of us that were aware of t=
he
> attacks then were in favor of a more targeted, minimal approach.  You wer=
e
> listened to in Yokohama, but that didn=E2=80=99t necessarily mean that pe=
ople
> agreed with the approach.  Participants were already aware of the
> oauth-meta proposal in Darmstadt but no one spoke up in favor of it that =
I
> can recall.  Rather, I think people were thinking that =E2=80=9Cless is m=
ore=E2=80=9D.
>
>
>
> There have also been discussions in the last day about how dynamically
> returning a resource URL, which oauth-meta does, is both unnecessary (sin=
ce
> the client initiated the resource authorization already knowing what
> resource it wants to access) and often problematic, since many
> authorization servers can authorize access to multiple resources.  If
> anything, the client should be telling the authorization server what
> resource it wants to access =E2=80=93 not the other way around.
>
>
>
> I=E2=80=99m not saying that there aren=E2=80=99t some good ideas in the o=
auth-meta draft =E2=80=93
> I=E2=80=99m sure there are, just as there are in the approach designed by=
 the
> participants in Darmstadt.  While I volunteered to write the first draft =
of
> the mix-up-mitigation approach, it really reflects something a lot of
> people have already bought into =E2=80=93 as evidenced in the passion in =
the
> high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D thread, =
and not just my
> personal project.
>
>
>
> If you think there are things missing or wrong in the mix-up-mitigation
> draft, please say what they are.  That will help us quickly converge on a
> solution that will work for everyone.
>
>
>
>                                                           Sincerely,
>
>                                                           -- Mike
>
>
>
> *From:* Nat Sakimura [mailto:sakimura@gmail.com ]
> *Sent:* Wednesday, January 20, 2016 11:17 PM
> *To:* Mike Jones ; William Denniss <
> wdenniss@google.com>; Justin Richer 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>
> Hi Mike.
>
>
>
> Conversely, I would like to ask why this approach does not work for Mix-u=
p
> attack. As Nov stated, we in fact have discussed the approach in quite a
> length back in Yokohama. I really would like to know why it does not work=
.
>
>
>
> Besides, for oauth-meta approach, mix-up attack is only one of the thing
> it solves.
>
>
>
> Nat Sakimura
>
>
>
> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones :
>
> Not to be negative, but I disagree with adopting
> draft-sakimura-oauth-meta.  We should define and promote one mitigation
> approach to the mix-up attacks.  Having two would confuse implementers an=
d
> cause compatibility problems =E2=80=93 reducing overall security.
>
>
>
> The approach defined in draft-jones-oauth-mix-up-mitigation was created i=
n
> collaboration with the security researchers who identified the problems i=
n
> the first place, was vigorously discussed in the security meeting Hannes
> and Torsten held in Darmstadt, and has been since refined based on
> substantial input from the working group.  And at least three implementer=
s
> have already stated that they=E2=80=99ve implemented it.  I=E2=80=99m not=
 saying that it=E2=80=99s,
> but if there are things missing or things that need to be improved in our
> approach, we should do it there, rather introducing a competing approach.
>
>
>
> Also, standard OAuth deployments register the client and then use the
> information gathered at registration time for subsequent protocol
> interactions.  They do not need all the configuration information for the
> authorization server to be retransmitted at runtime.  The oauth-meta draf=
t
> goes too far in that direction, at least as I see it.  Returning things t=
wo
> ways creates its own problems, as discussed in the Duplicate Information
> Attacks security considerations section (7.2) of the mix-up-mitigation
> draft.
>
>
>
> I=E2=80=99ll note that the mix-up-mitigation approach is compatible with =
existing
> practice in both static and dynamic metadata discovery.  Replying to
> Justin=E2=80=99s comment that =E2=80=9CIt's the pre-configured discovery =
document that's
> at the root of the mix-up attack in the first place=E2=80=9D =E2=80=93 th=
is is not the
> case.  The attacks can be performed without either discovery or dynamic
> registration.
>
>
>
> I would be interested in hearing a technical discussion on whether there
> are aspects of the oauth-meta approach that mitigate aspects of the attac=
ks
> that the mix-up-mitigation approach does not.  That could help inform
> whether there are additional things we should add to or change in the
> mix-up draft.
>
>
>
>                                                           -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William
> Denniss
> *Sent:* Wednesday, January 20, 2016 10:37 PM
> *To:* Justin Richer 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>
> +1 to adopt this, and I agree with Justin's comments.
>
>
>
> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer  wrote:
>
> +1
>
> Inline discovery and pre-configured discovery (ie, .well-known) should at
> the very least be compatible and developed together. It's the
> pre-configured discovery document that's at the root of the mix-up attack
> in the first place.
>
>  -- Justin
>
>
>
> On 1/19/2016 10:30 PM, Nat Sakimura wrote:
>
> Just to give more context, at IETF 94, I have done a presentation on
> discovery.
>
>
>
> According to the minutes,
>
>
>
>     (f) Discovery (Nat)
>
>
>
>              Nat explains his document as an example of the work that has=
 to be done
>
>              in the area of discovery, which is a topic that has been ide=
ntified
>
>              as necessary for interoperability since many years but so fa=
r there
>
>              was not time to work on it. Mike, John and Nat are working o=
n a new
>
>              document that describes additional discovery-relevant compon=
ents.
>
>
>
>              Poll: 19 for / zero against / 4 persons need more informatio=
n.
>
>
>
> The document discussed there was
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
> simple (only 1-page!) but a very powerful document that nudges towards
> HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-u=
p
> attack without introducing the concept of issuer which is not in RFC6749.
> It is also good for selecting different endpoints depending on the user
> authentication and authorization results and more privacy sensitive than
> pre-announced Discovery document. It also allows you to find to which
> protected resource endpoint you can use the access token against.
>
>
>
> In the last sentence of the minutes, it talks about "a new document that
> describes additional discovery-relevant components". This is
> https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went for
> the call for adoption. However, it is only a half of the story. I believe
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was
> discussed at IETF 94 and had support there should be adopted as well.
>
>
>
> Nat Sakimura
>
>
>
>
>
>
>
>
>
> 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura :
>
> Thanks Hannes.
>
>
>
> I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, =
which
> was discussed in Yokohama, and was largely in agreement if my recollectio=
n
> is correct. Why is it not in the call for adoption?
>
>
>
>
>
>
>
> 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig :
>
> Hi all,
>
> we have submitted our new charter to the IESG (see
> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
> since some IESG members like to see an updated list of milestones as
> well. For this reason, based on a suggestion from Barry, we are also
> starting a call for adoption concurrently with the review of the charter
> text by the IESG.
>
> We will post separate mails on the individual documents. Your feedback
> is important! Please take the time to look at the documents and provide
> your feedback.
>
> Ciao
> Hannes & Derek
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>

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


=

--Apple-Mail=_ED800867-02A0-4F12-A3B7-4F1FEDE1029D--


From nobody Thu Jan 21 20:22:46 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368A41B37B9 for ; Thu, 21 Jan 2016 20:22:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZEUK4REuBjQ for ; Thu, 21 Jan 2016 20:22:43 -0800 (PST)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC921B37BA for ; Thu, 21 Jan 2016 20:22:43 -0800 (PST)
Received: from home.alkaline-solutions.com (c-50-155-144-64.hsd1.co.comcast.net [50.155.144.64]) by alkaline-solutions.com (Postfix) with ESMTPSA id DDFA1315B1; Fri, 22 Jan 2016 04:22:40 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2DEA0B48-835C-4A6C-BA22-76EC2B139990"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: David Waite 
In-Reply-To: 
Date: Thu, 21 Jan 2016 21:22:39 -0700
Message-Id: <80218A07-9D37-42A3-B90A-56AEDBC3A86C@alkaline-solutions.com>
References:  <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com> 
To: John Bradley 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 04:22:45 -0000

--Apple-Mail=_2DEA0B48-835C-4A6C-BA22-76EC2B139990
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

> On Jan 21, 2016, at 2:50 PM, John Bradley  wrote:
>=20
> In that case you probably would put a hash of the state in the code to =
manage size.  The alg would be up to the AS, as long as it used the same =
hash both places it would work.
Yes, true.=20
>=20
> Sending the state to the token endpoint is like having nonce and =
c_hash in the id_token, it binds the issued code to the browser =
instance.
I think I understand what you are saying. Someone won=E2=80=99t be able =
to frankenstein up a state and a token from two different responses from =
an AS, and have a client successfully fetch an access token based on the =
amalgamation.
=20
> This protects against codes that leak via redirect uri pattern =
matching. failures etc.  It prevents an attacker from being able to =
replay a code from a different browser.
Yes, if a party intercepts the redirect_url, or the AS fails to enforce =
one time use (which even for a compliant implementation could just mean =
the attacker was faster than the state propagated within the AS)

Makes sense. Thanks John.

-DW

> If the client implements the other mitigations on the authorization =
endpoint, then it wouldn't be leaking the code via the token endpoint.=20=

>=20
> The two mitigations are for different attacks, however some of the =
attacks combined both vulnerabilities.
>=20
> Sending the iss and client_id is enough to stop the confused client =
attacks, but sending state on its own would not have stopped all of =
them.
>=20
> We discussed having them in separate drafts, and may still do that.   =
However for discussion having them in one document is I think better in =
the short run.
>=20
> John B.
>=20
>> On Jan 21, 2016, at 4:48 PM, David Waite =
> =
wrote:
>>=20
>> Question:=20
>>=20
>> I understand how =E2=80=9Ciss" helps mitigate this attack (client =
knows response was from the appropriate issuer and not an attack where =
the request was answered by another issuer).=20
>>=20
>> However, how does passing =E2=80=9Cstate=E2=80=9D on the =
authorization_code grant token request help once you have the above in =
place? Is this against some alternate flow of this attack I don=E2=80=99t =
see, or is it meant to mitigate some entirely separate attack?
>>=20
>> If one is attempting to work statelessly (e.g. your =E2=80=9Cstate=E2=80=
=9D parameter is actual state and not just a randomly generated value), =
a client would have always needed some way to differentiate which issuer =
the authorization_code grant token request would be sent to.
>>=20
>> However, if an AS was treating =E2=80=9Ccode=E2=80=9D as a token (for =
instance, encoding: client, user, consent time and approved scopes), the =
AS now has to include the client=E2=80=99s state as well. This would =
effectively double (likely more with encoding) the state sent in the =
authorization response back to the client redirect URL, adding more =
pressure against maximum URL sizes.
>>=20
>> -DW

--Apple-Mail=_2DEA0B48-835C-4A6C-BA22-76EC2B139990
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On =
Jan 21, 2016, at 2:50 PM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

In that case you probably would put a hash of the state in =
the code to manage size.  The alg would be up to the AS, as long as =
it used the same hash both places it would =
work.
Yes, true. 

Sending the state to the token endpoint =
is like having nonce and c_hash in the id_token, it binds the issued =
code to the browser instance.
I think I =
understand what you are saying. Someone won=E2=80=99t be able to =
frankenstein up a state and a token from two different responses from an =
AS, and have a client successfully fetch an access token based on the =
amalgamation.
 
This protects against codes that leak via redirect uri =
pattern matching. failures etc.  It prevents an attacker from being =
able to replay a code from a different =
browser.
Yes, if a party intercepts the =
redirect_url, or the AS fails to enforce one time use (which even for a =
compliant implementation could just mean the attacker was faster than =
the state propagated within the AS)

Makes sense. Thanks John.

-DW

If the client implements the other =
mitigations on the authorization endpoint, then it wouldn't be leaking =
the code via the token endpoint. 

The two mitigations are for different =
attacks, however some of the attacks combined both =
vulnerabilities.

Sending the iss and client_id is enough to stop the confused =
client attacks, but sending state on its own would not have stopped all =
of them.

We =
discussed having them in separate drafts, and may still do that.   =
However for discussion having them in one document is I think better in =
the short run.

John B.

On Jan 21, 2016, at 4:48 PM, David Waite <david@alkaline-solutions.com> wrote:

Question: 

I understand how =E2=80=9Ciss" helps mitigate this attack =
(client knows response was from the appropriate issuer and not an attack =
where the request was answered by another issuer). 

However, how does =
passing =E2=80=9Cstate=E2=80=9D on the authorization_code grant token =
request help once you have the above in place? Is this against some =
alternate flow of this attack I don=E2=80=99t see, or is it meant to =
mitigate some entirely separate attack?

If one is attempting to work =
statelessly (e.g. your =E2=80=9Cstate=E2=80=9D parameter is actual state =
and not just a randomly generated value), a client would have always =
needed some way to differentiate which issuer the authorization_code =
grant token request would be sent to.

However, if an AS was treating =
=E2=80=9Ccode=E2=80=9D as a token (for instance, encoding: client, user, =
consent time and approved scopes), the AS now has to include the =
client=E2=80=99s state as well. This would effectively double (likely =
more with encoding) the state sent in the authorization response back to =
the client redirect URL, adding more pressure against maximum URL =
sizes.

-DW
=

--Apple-Mail=_2DEA0B48-835C-4A6C-BA22-76EC2B139990--


From nobody Thu Jan 21 22:38:06 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9801A8768 for ; Thu, 21 Jan 2016 22:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHarlKCL6cYV for ; Thu, 21 Jan 2016 22:38:02 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0760.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:760]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3571A19F7 for ; Thu, 21 Jan 2016 22:38:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XtnV+X8xnp/jQk041wewIbnh1SkFQ3HqIxDDXkHK8m8=; b=MaLtAaH71LBSh4vp5wbURkcptcLrn/c7aEBfo6olyYIYbrloA+9kaUBGQ7UkS4pJDhJveGy1M0UKyonfdmTGQ2f9De7ux3HbO+//gbMLwyKkOrO/WtGOGURBz500G41ha9Tmk66S+BG08oQ5PhGI5Vlwwsvi87lHh75MyVIQcnw=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 22 Jan 2016 06:37:42 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Fri, 22 Jan 2016 06:37:42 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: Discovery document updates planned
Thread-Index: AdFU31+93piC5Ir6QUqouzHpMmHoOQ==
Date: Fri, 22 Jan 2016 06:37:41 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [50.47.85.157]
x-ms-office365-filtering-correlation-id: d997a2a0-ebb7-4fab-f972-08d322f687c8
x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:H7zW7rjMy/hbWVivtwJ3AdXjUvp2hA7AYJjD29M8/NK3iq2/wHPBrLJSdSVCqu1n31S2hLDSX3EuUBSp+Xq/lqaTgnZTZmc5F8RA3hd6/iG6QRBf/GJUDudFWobWXX2sgbRp/o/bgUSxnuUurj+JXw==; 24:D7H5qSDLgPffDETM2PSMGl+OrsrDkp1C8Qi+RCE8PId9MV/C3qfzDJPWIrAQwSRRVzkPcB5tbc3zi70Jt9bfTlCi5m8kO4B/rWJ5tDR90YI=
x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; UriScan:; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; 
x-forefront-prvs: 08296C9B35
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(102836003)(19300405004)(40100003)(86362001)(790700001)(77096005)(50986999)(8990500004)(5003600100002)(33656002)(2900100001)(107886002)(5001960100002)(19625215002)(16236675004)(99286002)(54356999)(5002640100001)(15975445007)(81156007)(450100001)(97736004)(19580395003)(86612001)(74316001)(122556002)(2351001)(66066001)(1220700001)(101416001)(586003)(10710500007)(5008740100001)(3846002)(2906002)(87936001)(106356001)(10290500002)(10090500001)(2420400006)(2501003)(5005710100001)(1096002)(110136002)(1730700002)(10400500002)(5004730100002)(6116002)(7110500001)(189998001)(105586002)(76576001)(229853001)(92566002)(11100500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4424365C3A69EDE67C59762F5C40BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2016 06:37:41.4609 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441
Archived-At: 
Subject: [OAUTH-WG] Discovery document updates planned
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 06:38:05 -0000

--_000_BY2PR03MB4424365C3A69EDE67C59762F5C40BY2PR03MB442namprd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Tomorrow I plan to apply updates to the OAuth Discovery document that have =
been requested since the -00 version was published.  Updates on my list to =
make are:

*       Adding an equivalent of token_endpoint_auth_methods_supported for t=
he revocation endpoint

*       Adding an equivalent of token_endpoint_auth_methods_supported for t=
he introspection endpoint

*       Adding code_challenge_methods_supported

Did I miss capturing any metadata values that it makes sense to add at this=
 point?

                                                          Thanks all,
                                                          -- Mike


--_000_BY2PR03MB4424365C3A69EDE67C59762F5C40BY2PR03MB442namprd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Tomorrow I plan to apply updates to the OAuth Discov=
ery document that have been requested since the -00 version was published.&=
nbsp; Updates on my list to make are:


·      
Adding an equivalent of 
token_endpoint_auth_methods_supported for the revocation endpoint


·      
Adding an equivalent of 
token_endpoint_auth_methods_supported for the introspection endpoint=



·      
Adding 
code_challenge_methods_supported


 


Did I miss capturing any metadata values that it mak=
es sense to add at this point?


 


        &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           Thanks al=
l,


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


 






--_000_BY2PR03MB4424365C3A69EDE67C59762F5C40BY2PR03MB442namprd_--


From nobody Fri Jan 22 01:11:45 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B091ACE1B for ; Fri, 22 Jan 2016 01:11:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26UPq9_RVBQN for ; Fri, 22 Jan 2016 01:11:41 -0800 (PST)
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 11B411ACE16 for ; Fri, 22 Jan 2016 01:11:40 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id u188so10566205wmu.1 for ; Fri, 22 Jan 2016 01:11:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=/DJe/QUBsINUKc3Zj7La4cmnQkZErIFfHW/oKHGcWq0=; b=ZLOPQsM9hXx0+/UKG7XFBFuzI15k16PQFyt3UegdUlXiOeUFsxKq1GT3Bk1yHwdjKZ Ow8OEE0IbukuBsW6e+Lq6yM+BequJ6UvoeUv01Xx968aBMOPhIPORYBRoGe9d60MwPZy K7yShloVzkc2e0wUOU/CP5fcFsQFsWktZV3eg=
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-type :content-transfer-encoding; bh=/DJe/QUBsINUKc3Zj7La4cmnQkZErIFfHW/oKHGcWq0=; b=lLzPXdKoR5iNnOlosBc1s9izqMDGe1V60A/JQSDGWFCNlg1ko1IfOmfSz55AUTYrF5 mIB9tyT6MXExoTh5x1fmfY2l76cQt7tqEsEQ+9WTIVpmV2qcw3rKeyQaJW7OjeMSD2uU TINEcLQ6VPM4w65RbmaqGaWXQ4qQ2QedBo5G5d+DrPnljDSVFxfM+VeJbYqj0Ejw7VYs RCkRPyfGSwKU4I9A/AQ5/3/oo/nlFyGjVa5eWrL3937/9BEK3tdjie8vjpy+vteOxTuq xL1YFeY4zedoDWXuwyhOGo2QDV71IHmy+h6zGS1pP6XwCtp2MntGzPRxUFlbGARvSwgB N58Q==
X-Gm-Message-State: AG10YORCtAc08ZBNP2KjXn2c5OAdWW5nT4i3F1rJjrWvjrE5bC145qpvUFCVrz/r8fxJ+5+U
X-Received: by 10.28.136.148 with SMTP id k142mr2396516wmd.41.1453453899503; Fri, 22 Jan 2016 01:11:39 -0800 (PST)
Received: from [192.168.10.222] (5ED52E8A.cm-7-6a.dynamic.ziggo.nl. [94.213.46.138]) by smtp.gmail.com with ESMTPSA id y124sm1995636wmg.3.2016.01.22.01.11.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jan 2016 01:11:38 -0800 (PST)
To: Mike Jones , John Bradley , Nat Sakimura 
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.com> 
From: Hans Zandbelt 
Message-ID: <56A1F249.3020307@pingidentity.com>
Date: Fri, 22 Jan 2016 10:11:37 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
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 WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 09:11:44 -0000

+1 to everything Mike stated

Hans.

On 1/22/16 2:04 AM, Mike Jones wrote:
> I believe that it’s simpler and more elegant to return an issuer, from
> which the discovery metadata document can be retrieved, which contains
> **all** the configuration information about the authorization server,
> than to return some of the configuration parameters but not most of them
> (which is what the oauth-meta proposal does).  There’s lots more in a
> typical discovery document than just a few endpoint addresses. For
> instance, there are statements about what response types are supported,
> other configuration choices, keys, etc.
>
> I also think that returning the issuer is more future-proof than trying
> to decide now what all the configuration information is that might want
> to be verified by the client and hoping we get it right.  With the
> issuer, assuming that discovery is supported, it can retrieve and check
> all of it, should the client want/need to do so.  Even when discovery
> isn’t supported, the issuer still provides a concrete identifier for the
> authorization server that can be checked for equality.
>
> We talked about the value of that approach in the side meetings in
> Yokohama and people were supportive then.
>
>                                                                  -- Mike
>
> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley
> *Sent:* Thursday, January 21, 2016 4:48 PM
> *To:* Nat Sakimura 
> *Cc:* oauth@ietf.org WG 
> *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
>
> I will point out for clarification that this would be like IdP discovery
> in openID 2 that everyone did.  I think IdP not doing RP discovery in
> openID 2 is a weak argument.
>
> There may be other evidence that RP will not do discovery, but if that
> is the case why are we doing a OAuth discovery spec?
>
> Many people see your spec as discovery as well just in a different way.
>
> I think both ways can work, but doing both leaves too many options.
>
> John B.
>
>     On Jan 21, 2016, at 9:38 PM, Nat Sakimura      > wrote:
>
>     Still doing the analysis. We spent 1.5 hours today with John,
>     George, nov and me on the OpenID Connect WG call on this issue. John
>     explained the mitigation, but none of us was convinced that it works.
>
>     Then, after the call, I and nov went on with various scenarios. The
>     interim conclusion is that:
>
>       * client_id response parameter does not help. There are legitimate
>         cases that client_id duplicates out there and we cannot ban that.
>       * iss response parameter does not help unless the discovery is
>         performed and the value of iss is checked against the value of
>         OAuth issuer inside the document. (<- Discovery becomes
>         mandatory. From our experience on RP discovery step in OpenID
>         2.0, chance of this being done properly seems to be rather slim.)
>       * sending the state to the token endpoint helps in the case code
>         was stollen, but code should not be stolen to start with.
>
>     Cheers,
>
>     Nat
>
>     2016年1月22日(金) 7:59 John Bradley      >:
>
>         There have been a lot of discussions. I think Hannes posted some
>         minutes of the F2F meeting we had with the security researchers.
>
>         The problem can’t be mitigated without some action on the client
>         side.  It boils down to the client making a request to AS1 (From
>         it’s perspective) and getting back a response from AS 2 (that it
>         thinks is AS1)
>
>         This can be done if AS1 is a good AS but has it’s logs
>         compromised so that an attacker can read them. Hans Zandbelt
>         built a proof of concept for the attack.
>
>         In some cases the attacker gets the code and the credential to
>         use it at the good AS token endpoint and in others it just gets
>         the code and can replay that at the client to extract
>         information from the API through the client by binding the api
>         access to a new account.
>
>         PKCE unfortunately mitigates a different attack, where the
>         client is impersonated and trys to replay a intercepted code.
>         It however assumes the token endpoint is good, and is no help in
>         the case of a compromised token endpoint.
>
>         The client in these attacks is vulnerable because it relies on
>         some local state, or the value of the state parameter to know
>         who the response is coming from.  This allows a authorization
>         request that is intercepted to be used to create a new request
>         in that browser to a different AS, or trick the client into
>         using a Authorization endpoint for a different authorization server.
>
>         One problem is that OAuth doesn’t really have a unified concept
>         of what a AS is.  Traditionally it is a Authorization endpoint
>         URI, token end point URI and resource server URI that some one
>         gives the client in some documentation.
>
>         As ling as a client only talks to one AS then there is no
>         problem.   However once a client is configured to talk to more
>         than one AS, we have problems if one of those AS lies about it’s
>         endpoints, or is compromised and used to attack another AS.   As
>         a design goal you don’t want the overall  security to be limited
>         by the weakest system.
>
>         One approach as Nat promotes is to have the authorization
>         endpoint return the next hop, token endpoint for code or RS URI
>         for token. The token endpoint must also return the RS URI or the
>         client must push the RS URI to the token endpoint or the
>         attacker just replaces the RS URI in the config and captures the
>         token that way.
>
>         The other way is to provide a name for each AS as part of
>         registration and the client not allow duplicate registrations
>         with the same name.  When the response comes back the client
>         checks the name against the one it made the request to. If the
>         name dereferences to a discovery document then the client can
>         check that name at registration or runtime to validate the net hops.
>
>         I think the two approaches mitigate the attack in similar ways.
>         Nat’s is more REST friendly and returns the next hop as a
>         parameter of header.
>
>         The one Mike and I wrote up based on the meeting in Germany
>         provides identifiers (iss and client_id) that can be checked for
>         validity in the simple case and be dereferenced via .well-known
>         to get the information Nat’s proposal is providing.
>
>         Perhaps the main difference is Nat is using the token endpoint
>         as the identifier for the AS and Mike’s is using location for a
>         discovery document as the identifier.
>
>         I don’t recall the reasons using the token endpoint as the
>         identifier was rejected at the meeting.  Perhaps others can post
>         the reasons.
>
>         We need to close on this quickly, otherwise if we are indecisive
>         fixes will not go into products for another year or so until
>         this is a RFC.
>
>         That is my main concern.
>
>         John B.
>
>             On Jan 21, 2016, at 11:50 AM, Josh Mandel              > wrote:
>
>             Thanks Nat - that's helpful. If both mitigations *can* work
>             effectively, then I would like to see this group consider
>             the decision between them carefully (if that hasn't happened
>             yet). Again, don't hesitate to let me know if this is the
>             wrong place/time for such discussion.
>
>             At a high level, I would rather ask server developers to do
>             some "coding", for two reasons:
>
>             1. Most OAuth servers talk to many, many clients. So
>             consolidating the security critical work in one place
>             (server) is a net savings of work (rather than asking each
>             client to implement these checks.
>
>             2. OAuth server developers are typically more sophisticated
>             than client developers, and therefore more likely to
>             understand the implications and more likely to get these
>             critical details correct. Asking each client developer to do
>             something right is likely to result in heterogenius
>             implementation and persistent security holes. But if the
>             server does the heavy lifting, and clients just have to pass
>             along an extra parameter, this is more likely to see
>             consistent implementation (for example, clients will fail to
>             work if misconfigured, which will prompt developers to fix
>             them).
>
>             On Jan 21, 2016 09:40, "Nat Sakimura"              > wrote:
>
>                 Hi Josh,
>
>                 It is similar but slightly different IMHO.
>
>                 Section 4.6.4 of the RFC6819 is the access token
>                 phishing by a counterfeit resource server.
>
>                 The mix-up attack described here is the code phishing by
>                 a counterfeit token endpoint.
>
>                 In my view, both can be mitigated by the server
>                 returning the next step: i.e., authorization endpoint
>                 returning the legitimate token endpoint uri, and token
>                 endpoint returning legitimate resource endpoint uris.
>                 This involves no discovery endpoint, which is good.
>
>                 Your way also works. It is just the reverse of my
>                 proposal. The difference being that my proposal does not
>                 need any coding on the server but just configuration,
>                 and it can return more metadata if needed.
>
>                 Cheers,
>
>                 Nat
>
>                 2016年1月21日(木) 23:04 Josh Mandel                  >:
>
>                     Apologies if this is the wrong forum for my comment
>                     (and please direct me to the appropriate place in
>                     that case), but I have two questions about the
>                     propose mitigation (and the thinking behind it) that
>                     I think the write-up could address:
>
>                     1. Could the writeup clarify whether/how the primary
>                     "mixup" threat differs from what RFC6819 identifies
>                     as in section 4.6.4?
>
>                     2. Has the workgroup considered a mitigation that
>                     puts more responsibility on the authorization
>                     server, and less on the client? For example, if
>                     would be helpful for the writeup to clarify why
>                     having the client send an "audience field" (in the
>                     terminology of RFC6819) to the authorization
>                     endpoint would not mitigate the threat. (In that
>                     scenario, the authorization server can recognize
>                     that the audience does not correspond to a resource
>                     server it knows, rather than asking clients to make
>                     this check). I assume this approach has been
>                     considered and rejected as an incomplete mitigation,
>                     but I don't have visibility into where/how that
>                     discussion went.
>
>                     Thanks,
>
>                     Josh
>
>                     Hi all,
>
>                     this is the call for adoption of OAuth 2.0 Mix-Up
>                     Mitigation, see
>                     https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>
>                     Please let us know by Feb 9th whether you accept /
>                     object to the
>                     adoption of this document as a starting point for
>                     work in the OAuth
>                     working group.
>
>                     Note: This call is related to the announcement made
>                     on the list earlier
>                     this month, see
>                     http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html.
>                     More
>                     time for analysis is provided due to the complexity
>                     of the topic.
>
>                     Ciao
>                     Hannes & Derek
>
>
>                     _______________________________________________
>                     OAuth mailing list
>                     OAuth@ietf.org 
>                     https://www.ietf.org/mailman/listinfo/oauth
>
>                     _______________________________________________
>                     OAuth mailing list
>                     OAuth@ietf.org 
>                     https://www.ietf.org/mailman/listinfo/oauth
>
>             _______________________________________________
>             OAuth mailing list
>             OAuth@ietf.org 
>             https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity


From nobody Fri Jan 22 04:45:24 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540F61A1B9E for ; Fri, 22 Jan 2016 04:45:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0c-F9GCYPJSm for ; Fri, 22 Jan 2016 04:45:21 -0800 (PST)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::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 81A501A1BB8 for ; Fri, 22 Jan 2016 04:45:21 -0800 (PST)
Received: by mail-yk0-x236.google.com with SMTP id a85so84536877ykb.1 for ; Fri, 22 Jan 2016 04:45:21 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=etryfFTgDdjRrd6zc1pr6pGIpWmCwlLoVnkxWNO9u6U=; b=LbuhSNs5h2PlXlBO+SCphv86SoDO/JGV+3DlnvQcC5/2f+I3aX0VYIsd++DzqqKPkK Nwe7qPsn9yJgmQ/BBipRgLTly4Y8Czc+9EQCYpO2p5k192hg7oLrLAwaKNKbY+t7+bp9 u4G8ys5UhFYI4a+1BEfnel6rH4N0XiINkTDZ8VdbitlSjaIJ3H/KKJWqmJRAqfCvVZKF OxZelEDfuaulVPwCFciXcUc1+vyAESvpnEV2RYgMsoBK2eINZ7yTwpwsWTlMnbv7zkn0 yvhrhMvA1Oz4dph+rJooNQJ1TrERywHKXxLEpO/l6LwyorptlDtTuA4ItFDzWc/ejF15 gLWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=etryfFTgDdjRrd6zc1pr6pGIpWmCwlLoVnkxWNO9u6U=; b=AGFLfu8wzgIaRLTlmpDuKVy/QdEpSrGMufu+GqaaUSUfjxToPWJ4lOZClH9TYTLZdZ +sS2lef5iz/hogVi9jH/R2RigSjleVN/qHV4+61o3cNdeQC+LGSACeblB9+Arlhs1yuF rvBE2JT6ZKT5Wm9K7jZkxdCYKzZtimX7y9zjQE9mOGGWBJtgEsc7ODbDnUVeHq1YuKcF 3qLnRQ5+l8eKQ/2kNmTMREg5ZccFG0RP7n/jyIFlRgw+qXq23qGSIAZakV/fH5ZNYkwJ Ev5beEMrsTIGahnSuoxUv2hXtZl6vOfDTpb/Xl+6b7nFYTvUFYfLrdx+0llMMZRf82to aDmA==
X-Gm-Message-State: AG10YOQbxRuQjVEwVdNULvOH1r0gJtJJy935QD7ZiqED10AY7zvQTv7W4oXJz/NCoC7vPVqn5WFoW0+v0fo2RA==
MIME-Version: 1.0
X-Received: by 10.37.80.76 with SMTP id e73mr1277722ybb.26.1453466720623; Fri, 22 Jan 2016 04:45:20 -0800 (PST)
Received: by 10.37.207.87 with HTTP; Fri, 22 Jan 2016 04:45:20 -0800 (PST)
Received: by 10.37.207.87 with HTTP; Fri, 22 Jan 2016 04:45:20 -0800 (PST)
In-Reply-To: <80218A07-9D37-42A3-B90A-56AEDBC3A86C@alkaline-solutions.com>
References:  <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com>  <80218A07-9D37-42A3-B90A-56AEDBC3A86C@alkaline-solutions.com>
Date: Fri, 22 Jan 2016 09:45:20 -0300
Message-ID: 
From: John Bradley 
To: David Waite 
Content-Type: multipart/alternative; boundary=001a113e9d3493906b0529eb9773
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 12:45:23 -0000

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

Perhaps Frankenstein response is a better name than cut and paste attack.

John B.
On Jan 22, 2016 1:22 AM, "David Waite"  wrote=
:

> On Jan 21, 2016, at 2:50 PM, John Bradley  wrote:
>
> In that case you probably would put a hash of the state in the code to
> manage size.  The alg would be up to the AS, as long as it used the same
> hash both places it would work.
>
> Yes, true.
>
>
> Sending the state to the token endpoint is like having nonce and c_hash i=
n
> the id_token, it binds the issued code to the browser instance.
>
> I think I understand what you are saying. Someone won=E2=80=99t be able t=
o
> frankenstein up a state and a token from two different responses from an
> AS, and have a client successfully fetch an access token based on the
> amalgamation.
>
>
> This protects against codes that leak via redirect uri pattern matching.
> failures etc.  It prevents an attacker from being able to replay a code
> from a different browser.
>
> Yes, if a party intercepts the redirect_url, or the AS fails to enforce
> one time use (which even for a compliant implementation could just mean t=
he
> attacker was faster than the state propagated within the AS)
>
> Makes sense. Thanks John.
>
> -DW
>
> If the client implements the other mitigations on the authorization
> endpoint, then it wouldn't be leaking the code via the token endpoint.
>
> The two mitigations are for different attacks, however some of the attack=
s
> combined both vulnerabilities.
>
> Sending the iss and client_id is enough to stop the confused client
> attacks, but sending state on its own would not have stopped all of them.
>
> We discussed having them in separate drafts, and may still do that.
> However for discussion having them in one document is I think better in t=
he
> short run.
>
> John B.
>
> On Jan 21, 2016, at 4:48 PM, David Waite 
> wrote:
>
> Question:
>
> I understand how =E2=80=9Ciss" helps mitigate this attack (client knows r=
esponse
> was from the appropriate issuer and not an attack where the request was
> answered by another issuer).
>
> However, how does passing =E2=80=9Cstate=E2=80=9D on the authorization_co=
de grant token
> request help once you have the above in place? Is this against some
> alternate flow of this attack I don=E2=80=99t see, or is it meant to miti=
gate some
> entirely separate attack?
>
> If one is attempting to work statelessly (e.g. your =E2=80=9Cstate=E2=80=
=9D parameter is
> actual state and not just a randomly generated value), a client would hav=
e
> always needed some way to differentiate which issuer the authorization_co=
de
> grant token request would be sent to.
>
> However, if an AS was treating =E2=80=9Ccode=E2=80=9D as a token (for ins=
tance, encoding:
> client, user, consent time and approved scopes), the AS now has to includ=
e
> the client=E2=80=99s state as well. This would effectively double (likely=
 more with
> encoding) the state sent in the authorization response back to the client
> redirect URL, adding more pressure against maximum URL sizes.
>
> -DW
>
>

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


Perhaps Frankenstein response is a better name than cut and =
paste attack. 


John B.=C2=A0=C2=A0 


On Jan 22, 2016 1:22 AM, "David Waite"=
 <david@alkaline-solutio=
ns.com> wrote:
O=
n Jan 21, 2016, at 2:50 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

In that case you probably would put a=
 hash of the state in the code to manage size.=C2=A0 The alg would be up to=
 the AS, as long as it used the same hash both places it would work.
<=
/div>
Yes, true.=C2=A0
=


Sending the state t=
o the token endpoint is like having nonce and c_hash in the id_token, it bi=
nds the issued code to the browser instance.
=
I think I understand what you are saying. Someone won=E2=80=99t be able to =
frankenstein up a state and a token from two different responses from an AS=
, and have a client successfully fetch an access token based on the amalgam=
ation.
=C2=A0
This protects against codes that leak via redirec=
t uri pattern matching. failures etc.=C2=A0 It prevents an attacker from be=
ing able to replay a code from a different browser.
Yes, if a party intercepts the redirect_url, or the AS fails to enforce on=
e time use (which even for a compliant implementation could just mean the a=
ttacker was faster than the state propagated within the AS)

<=
/div>
Makes sense. Thanks John.

-DW
=

If the client implements the other mitigations on the authorization =
endpoint, then it wouldn't be leaking the code via the token endpoint.=
=C2=A0

The two mitigations are for different attac=
ks, however some of the attacks combined both vulnerabilities.
Sending the iss and client_id is enough to stop the confused c=
lient attacks, but sending state on its own would not have stopped all of t=
hem.

We discussed having them in separate drafts, =
and may still do that. =C2=A0 However for discussion having them in one doc=
ument is I think better in the short run.

John B.<=
/div>

On Jan 21, 201=
6, at 4:48 PM, David Waite <david@alkaline-solutions.com> wrote:

=

Question:=C2=A0

I understand how =E2=80=9Ciss" helps mitigate this attack (client kno=
ws response was from the appropriate issuer and not an attack where the req=
uest was answered by another issuer).=C2=A0

However, how=
 does passing =E2=80=9Cstate=E2=80=9D on the authorization_code grant token=
 request help once you have the above in place? Is this against some altern=
ate flow of this attack I don=E2=80=99t see, or is it meant to mitigate som=
e entirely separate attack?

If one is attempting t=
o work statelessly (e.g. your =E2=80=9Cstate=E2=80=9D parameter is actual s=
tate and not just a randomly generated value), a client would have always n=
eeded some way to differentiate which issuer the authorization_code grant t=
oken request would be sent to.

However, if an AS w=
as treating =E2=80=9Ccode=E2=80=9D as a token (for instance, encoding: clie=
nt, user, consent time and approved scopes), the AS now has to include the =
client=E2=80=99s state as well. This would effectively double (likely more =
with encoding) the state sent in the authorization response back to the cli=
ent redirect URL, adding more pressure against maximum URL sizes.

-DW
<=
/blockquote>

--001a113e9d3493906b0529eb9773--


From nobody Fri Jan 22 05:11:39 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E02B1A21BE for ; Fri, 22 Jan 2016 05:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHU3D8NnIo9c for ; Fri, 22 Jan 2016 05:11:35 -0800 (PST)
Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::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 97CB61A21C3 for ; Fri, 22 Jan 2016 05:11:35 -0800 (PST)
Received: by mail-ob0-x236.google.com with SMTP id vt7so61984751obb.1 for ; Fri, 22 Jan 2016 05:11:35 -0800 (PST)
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:content-type; bh=z4Dh0bZZ+YHT6s7zgY/VFVYXKye2ZQ28uWCrw9hKcsU=; b=IVbtu6iNLH/A9UCRi1/q1eULPlE3kM4Q+k1BegXEewFo9vUlFfeOd2KNu24gj+fCbN imv+pW8WJKS0+Xa4l08AEstH6rRzgQRWuGqqCH43N4VhiZ6RJ87hmj8QjQ3S803T1Ny0 1BvEyp005m5mC5q2URa0i9ORux5VPW5EJX7P5Tp1hqkdgWITliGbHzCx5yMR6ztS4Z7g LCyjVKMTtiTzqGqvlG2QbDdx36rnsVtDssqE/sW9VaD8GMquScaSJ3wQg/kI8G++1RVE rL4SdkpZWRio6BWBLfoMDJUR6kk/8LYzcVt1vCZAz9khwwJpLKoU92+fxi7grS3Ww2OA WmDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=z4Dh0bZZ+YHT6s7zgY/VFVYXKye2ZQ28uWCrw9hKcsU=; b=ROmVznFHH7MhxFPwSEeQCGst6GbFnoyY8K+j0Khj09AVWNEXS7R2rmHwmIPABfx7m0 PSl4Lx59200VNEqU5ewcTReQGsUFzsN18xNmd8cuVdUqHoX283NSIJUBbRxrxEvCL/PA EHVvBvB92APiHzZkfnTHalvT8eN4mT4/xxoxdFVOvmidO1XQWOJR9iWAU0/Ah9n0f2pG HrTU62dt98aMoW0wVgYFfhyCnbU8d/uWKvwvVZW3R/4s61kyCayuYCBptvjtYbik0CTc bSO7pXH8hKxbIVghYrlHnUO2qJJs+vQxiSc7n4CBqJ2RERqJ1zxIpqUNFyhNfpFkitU4 QiYg==
X-Gm-Message-State: AG10YOQMx3lIYp5cBhQcoXLn0qcUaOzi0uoyIvu/DstiQwAIK3vzJRe01pWEPQllDYoEk5daYh+eyMq4vh52jQzT
X-Received: by 10.182.214.40 with SMTP id nx8mr2397769obc.20.1453468294832; Fri, 22 Jan 2016 05:11:34 -0800 (PST)
MIME-Version: 1.0
References:  <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com>  <80218A07-9D37-42A3-B90A-56AEDBC3A86C@alkaline-solutions.com> 
In-Reply-To: 
From: William Denniss 
Date: Fri, 22 Jan 2016 13:11:24 +0000
Message-ID: 
To: John Bradley , David Waite 
Content-Type: multipart/alternative; boundary=e89a8ff1c01e6842e40529ebf55c
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 13:11:37 -0000

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

+1 ;)
On Fri, Jan 22, 2016 at 8:45 PM John Bradley  wrote:

> Perhaps Frankenstein response is a better name than cut and paste attack.
>
> John B.
> On Jan 22, 2016 1:22 AM, "David Waite" 
> wrote:
>
>> On Jan 21, 2016, at 2:50 PM, John Bradley  wrote:
>>
>> In that case you probably would put a hash of the state in the code to
>> manage size.  The alg would be up to the AS, as long as it used the same
>> hash both places it would work.
>>
>> Yes, true.
>>
>>
>> Sending the state to the token endpoint is like having nonce and c_hash
>> in the id_token, it binds the issued code to the browser instance.
>>
>> I think I understand what you are saying. Someone won=E2=80=99t be able =
to
>> frankenstein up a state and a token from two different responses from an
>> AS, and have a client successfully fetch an access token based on the
>> amalgamation.
>>
>>
>> This protects against codes that leak via redirect uri pattern matching.
>> failures etc.  It prevents an attacker from being able to replay a code
>> from a different browser.
>>
>> Yes, if a party intercepts the redirect_url, or the AS fails to enforce
>> one time use (which even for a compliant implementation could just mean =
the
>> attacker was faster than the state propagated within the AS)
>>
>> Makes sense. Thanks John.
>>
>> -DW
>>
>> If the client implements the other mitigations on the authorization
>> endpoint, then it wouldn't be leaking the code via the token endpoint.
>>
>> The two mitigations are for different attacks, however some of the
>> attacks combined both vulnerabilities.
>>
>> Sending the iss and client_id is enough to stop the confused client
>> attacks, but sending state on its own would not have stopped all of them=
.
>>
>> We discussed having them in separate drafts, and may still do that.
>> However for discussion having them in one document is I think better in =
the
>> short run.
>>
>> John B.
>>
>> On Jan 21, 2016, at 4:48 PM, David Waite 
>> wrote:
>>
>> Question:
>>
>> I understand how =E2=80=9Ciss" helps mitigate this attack (client knows =
response
>> was from the appropriate issuer and not an attack where the request was
>> answered by another issuer).
>>
>> However, how does passing =E2=80=9Cstate=E2=80=9D on the authorization_c=
ode grant token
>> request help once you have the above in place? Is this against some
>> alternate flow of this attack I don=E2=80=99t see, or is it meant to mit=
igate some
>> entirely separate attack?
>>
>> If one is attempting to work statelessly (e.g. your =E2=80=9Cstate=E2=80=
=9D parameter is
>> actual state and not just a randomly generated value), a client would ha=
ve
>> always needed some way to differentiate which issuer the authorization_c=
ode
>> grant token request would be sent to.
>>
>> However, if an AS was treating =E2=80=9Ccode=E2=80=9D as a token (for in=
stance, encoding:
>> client, user, consent time and approved scopes), the AS now has to inclu=
de
>> the client=E2=80=99s state as well. This would effectively double (likel=
y more with
>> encoding) the state sent in the authorization response back to the clien=
t
>> redirect URL, adding more pressure against maximum URL sizes.
>>
>> -DW
>>
>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

+1 ;)
On Fri, Jan 22, 2016 a=
t 8:45 PM John Bradley <ve7jtb@ve7j=
tb.com> wrote:
Perhaps Frankenstein response is a better name than cut and paste attack.=
 


John B.=C2=A0=C2=A0 


On Jan 22, 2016 1:22 AM, "David Waite"=
 <davi=
d@alkaline-solutions.com> wrote:
On Jan 21, 2016, at 2:50 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:=


In that case you pr=
obably would put a hash of the state in the code to manage size.=C2=A0 The =
alg would be up to the AS, as long as it used the same hash both places it =
would work.
Yes, true.=C2=A0

S=
ending the state to the token endpoint is like having nonce and c_hash in t=
he id_token, it binds the issued code to the browser instance.
<=
/div>
I think I understand what you are saying. Someone won=E2=
=80=99t be able to frankenstein up a state and a token from two different r=
esponses from an AS, and have a client successfully fetch an access token b=
ased on the amalgamation.
=C2=A0
This protects against codes th=
at leak via redirect uri pattern matching. failures etc.=C2=A0 It prevents =
an attacker from being able to replay a code from a different browser.
Yes, if a party intercepts the redirect_url, or the AS =
fails to enforce one time use (which even for a compliant implementation co=
uld just mean the attacker was faster than the state propagated within the =
AS)

Makes sense. Thanks John.

=

-DW

If the client implements the other mitigations on=
 the authorization endpoint, then it wouldn't be leaking the code via t=
he token endpoint.=C2=A0

The two mitigations are f=
or different attacks, however some of the attacks combined both vulnerabili=
ties.

Sending the iss and client_id is enough to s=
top the confused client attacks, but sending state on its own would not hav=
e stopped all of them.

We discussed having them in=
 separate drafts, and may still do that. =C2=A0 However for discussion havi=
ng them in one document is I think better in the short run.

<=
/div>
John B.

<=
div>On Jan 21, 2016, at 4:48 PM, David Waite <david@alkaline-solutions.com>=
; wrote:

Question:=C2=A0<=
div>
I understand how =E2=80=9Ciss" helps mitigate this =
attack (client knows response was from the appropriate issuer and not an at=
tack where the request was answered by another issuer).=C2=A0

However, how does passing =E2=80=9Cstate=E2=80=9D on the authorizatio=
n_code grant token request help once you have the above in place? Is this a=
gainst some alternate flow of this attack I don=E2=80=99t see, or is it mea=
nt to mitigate some entirely separate attack?

If o=
ne is attempting to work statelessly (e.g. your =E2=80=9Cstate=E2=80=9D par=
ameter is actual state and not just a randomly generated value), a client w=
ould have always needed some way to differentiate which issuer the authoriz=
ation_code grant token request would be sent to.

H=
owever, if an AS was treating =E2=80=9Ccode=E2=80=9D as a token (for instan=
ce, encoding: client, user, consent time and approved scopes), the AS now h=
as to include the client=E2=80=99s state as well. This would effectively do=
uble (likely more with encoding) the state sent in the authorization respon=
se back to the client redirect URL, adding more pressure against maximum UR=
L sizes.

-DW
<=
/div>

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



--e89a8ff1c01e6842e40529ebf55c--


From news@bucksch.org  Thu Jan 21 16:03:51 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC14E1B3522 for ; Thu, 21 Jan 2016 16:03:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 281-20PbmY9T for ; Thu, 21 Jan 2016 16:03:50 -0800 (PST)
Received: from mail.server.beonex.com (mail.server.beonex.com [144.76.227.234]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3FD1B3524 for ; Thu, 21 Jan 2016 16:03:49 -0800 (PST)
To: oauth@ietf.org
From: Ben Bucksch 
Organization: Me, myself and I
Message-ID: <56A171E9.6060705@bucksch.org>
Date: Fri, 22 Jan 2016 01:03:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0a1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
X-Mailman-Approved-At: Fri, 22 Jan 2016 06:50:48 -0800
Subject: [OAUTH-WG] JWT compares client time with server time
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 00:05:18 -0000

Story: We wrote a script implementing JWT.

The code was working for my colleague, who wrote the script, but I just 
got "Invalid authentication credentials".

We were debugging it for days (!), suspecting shell argument passing and 
parsing, OS differences and what not. We compared credentials and 
confirmed they are identical. Still, the result was different. During 
debugging, once, by coincidence, it worked - at a time when it should be 
expired.

What was the reason? My clock on my computer was fast.

I was speechless. Client/server protocols must NEVER compare client 
clocks with server clocks, because clocks are very often off. Even if it 
was originally set exactly right by the second, clocks always have a 
drift in one way or another. If you have 5 million users, you will 
surely have 500000 whose clocks are off by 1 minute, and 50000 users 
whose clocks are off more than that.
In my case, my clock was 95 seconds fast. That's not uncommon. You 
cannot expect nor demand that every computer in the world runs NTP clients.

OAuth 2.0 knows that and does not rely on client clock matching server 
clock. For good reason. Ditto HTTP Cache headers don't send client time, 
even though that's an obvious and simple implementation, but the server 
sends and ETag and the client echos it back. Even if that's a more 
complex implementation, it's crucial to work reliably.

------------------------------------------------------------------------

Worse, in JWT, iat (time of issue, created by JWT client) is often 
enforced with second precision on the JWT server. A client clock that is 
just 3 seconds fast (very likely) will cause an iat in the future, which 
makes the server reject it.

You simply cannot compare client clock with server clocks. Please change 
the protocol to not do that, or take JWT off the proposed standards track.


From nobody Fri Jan 22 08:05:23 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AE21AD289 for ; Fri, 22 Jan 2016 08:05:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtQtT_KI-fBQ for ; Fri, 22 Jan 2016 08:05:21 -0800 (PST)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 9173A1AD277 for ; Fri, 22 Jan 2016 08:05:20 -0800 (PST)
Received: by mail-lb0-x22f.google.com with SMTP id x4so44085318lbm.0 for ; Fri, 22 Jan 2016 08:05:20 -0800 (PST)
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 :content-type; bh=fsQuwy0V839A5AhYf/Cq9cboIewbAbMN16JJWYEiWIQ=; b=G44wRu7CwtrWEDesKw1Vrnm6Zn2G+IrwJMb2AV+oVGzoDOEcjvQ+Sbix6hygIUpNu/ Cr9WGMuITlLJZxGI+bhVZTSKf/bino9VX3VNcOMqK/v7/dFYw2RRD8utvLvFG4SZ02rQ A1qCJU1OPeR+Bc9hSsM6wwbtdSSDLZ0ByOaHpZY8iFtvdeUDvN97za9zkrkje4vfE7lg cb8/VnSr7e+C2+SpoMIdfmvTDOJucCQL65l+N0gR1SCTvBMHH2UvnyoWExVD17yL9yq4 RU7EUIdIOAuuFap4eVidRiSYAcRlA3HKSs6evWyN2LV0IMMNOv3TdM6yKrCAX/OKCHb9 KbHA==
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:content-type; bh=fsQuwy0V839A5AhYf/Cq9cboIewbAbMN16JJWYEiWIQ=; b=AD7ee4RGjMpgNrvYRk23km8jNZDwU3t6RJXC5nPfZIq7QmvfDdn4Bf7ivawDT8vsEs rJ2ye2BOcTiQt90Gh64Sz9GpWhCaRM58hKaor2NhFjmcoQrVL5ge0cn40Alews8LFp/w Gt5Pp6maSpUJvBD1rSi4pyBwdPZ1yROFb5cGS0wWcnjOMMA3cLACc9MMcQYaizz10iJK gTpDhn9NYsJV9Ty2K16u4yhnVVuMDrQPWknFcGscoad64QilgCyzw583YXVc7bgNytN+ LDu3zNpJVnAIOqxEmxMnFqUMmSRDbKGB0jESjvSNcNRTcTVwnWaHWmgrYtPMvHPkcgCJ T3vg==
X-Gm-Message-State: AG10YOT47X/2z2ZgACvutIRy0CT8BqmgNrly3ZKwMUR244jCOpf4q1Wd0xq0VQOGbsCgeX2Xz0H5UwRTYpygaw==
X-Received: by 10.112.35.162 with SMTP id i2mr1502186lbj.107.1453478718750; Fri, 22 Jan 2016 08:05:18 -0800 (PST)
MIME-Version: 1.0
References: <56A171E9.6060705@bucksch.org>
In-Reply-To: <56A171E9.6060705@bucksch.org>
From: Thomas Broyer 
Date: Fri, 22 Jan 2016 16:05:08 +0000
Message-ID: 
To: Ben Bucksch , oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a11c36b66b84fb10529ee624f
Archived-At: 
Subject: Re: [OAUTH-WG] JWT compares client time with server time
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 16:05:23 -0000

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

Or just account for clock differences when comparing values, which I
believe is what the specs suggest.

Le ven. 22 janv. 2016 15:50, Ben Bucksch  a =C3=A9crit :

> Story: We wrote a script implementing JWT.
>
> The code was working for my colleague, who wrote the script, but I just
> got "Invalid authentication credentials".
>
> We were debugging it for days (!), suspecting shell argument passing and
> parsing, OS differences and what not. We compared credentials and
> confirmed they are identical. Still, the result was different. During
> debugging, once, by coincidence, it worked - at a time when it should be
> expired.
>
> What was the reason? My clock on my computer was fast.
>
> I was speechless. Client/server protocols must NEVER compare client
> clocks with server clocks, because clocks are very often off. Even if it
> was originally set exactly right by the second, clocks always have a
> drift in one way or another. If you have 5 million users, you will
> surely have 500000 whose clocks are off by 1 minute, and 50000 users
> whose clocks are off more than that.
> In my case, my clock was 95 seconds fast. That's not uncommon. You
> cannot expect nor demand that every computer in the world runs NTP client=
s.
>
> OAuth 2.0 knows that and does not rely on client clock matching server
> clock. For good reason. Ditto HTTP Cache headers don't send client time,
> even though that's an obvious and simple implementation, but the server
> sends and ETag and the client echos it back. Even if that's a more
> complex implementation, it's crucial to work reliably.
>
> ------------------------------------------------------------------------
>
> Worse, in JWT, iat (time of issue, created by JWT client) is often
> enforced with second precision on the JWT server. A client clock that is
> just 3 seconds fast (very likely) will cause an iat in the future, which
> makes the server reject it.
>
> You simply cannot compare client clock with server clocks. Please change
> the protocol to not do that, or take JWT off the proposed standards track=
.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Or just account for clock differences when comparing values,=
 which I believe is what the specs suggest.




Le=C2=A0ven. 22 janv. 2016 =
15:50,=C2=A0Ben Bucksch <news@bucksc=
h.org> a =C3=A9crit=C2=A0:
S=
tory: We wrote a script implementing JWT.



The code was working for my colleague, who wrote the script, but I just

got "Invalid authentication credentials".



We were debugging it for days (!), suspecting shell argument passing and
parsing, OS differences and what not. We compared credentials and

confirmed they are identical. Still, the result was different. During

debugging, once, by coincidence, it worked - at a time when it should be
expired.



What was the reason? My clock on my computer was fast.



I was speechless. Client/server protocols must NEVER compare client

clocks with server clocks, because clocks are very often off. Even if it
was originally set exactly right by the second, clocks always have a

drift in one way or another. If you have 5 million users, you will

surely have 500000 whose clocks are off by 1 minute, and 50000 users

whose clocks are off more than that.

In my case, my clock was 95 seconds fast. That's not uncommon. You

cannot expect nor demand that every computer in the world runs NTP clients.=




OAuth 2.0 knows that and does not rely on client clock matching server

clock. For good reason. Ditto HTTP Cache headers don't send client time=
,

even though that's an obvious and simple implementation, but the server=


sends and ETag and the client echos it back. Even if that's a more

complex implementation, it's crucial to work reliably.



------------------------------------------------------------------------


Worse, in JWT, iat (time of issue, created by JWT client) is often

enforced with second precision on the JWT server. A client clock that is
just 3 seconds fast (very likely) will cause an iat in the future, which
makes the server reject it.



You simply cannot compare client clock with server clocks. Please change
the protocol to not do that, or take JWT off the proposed standards track.<=
br>


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--001a11c36b66b84fb10529ee624f--


From nobody Fri Jan 22 08:33:08 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395661B137B for ; Fri, 22 Jan 2016 08:33:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBoueh2Mz_9F for ; Fri, 22 Jan 2016 08:32:55 -0800 (PST)
Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 7834C1AD49F for ; Fri, 22 Jan 2016 08:32:54 -0800 (PST)
Received: by mail-lb0-x230.google.com with SMTP id oh2so44070795lbb.3 for ; Fri, 22 Jan 2016 08:32:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=Ooe4RaLDgmpuC2tjOiMlUHQ98A50Dg7KityRipeuVhk=; b=vashjhdUDgyR2IT5aBUr0ViAtMc99UXfaOGtDJbH30tZG9BFZHJ9U4bngwvF3ZIYPO hZ+xaOCgKZHASdlcrCUq+4RIoORyLnGoZ4IK5KN0v87guhAi/fXgMghs68+fPVFEjvjh 9XZID4K4h0DiG5KXbRT/3YmoMeFxotdgkcMrJAE0c/O+0WYNgEK7BnYn5jrOEABvpCma aKr1/ZoEfhcW3ZP7d5gznu+PIGZtCkT9JPMN2nZI1/K0Sg8jMKmwba+dyJ2CxGZEpnCg gLMB7X3ulKUZ5pLgZ1As1QEMMtksrTRA3yTDxtE0kcmaI1OJbtGzcO16khrzCghaT+lj +TAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=Ooe4RaLDgmpuC2tjOiMlUHQ98A50Dg7KityRipeuVhk=; b=bPmJS8jz1wsyTon1i1UsHr7Fel8QQYFyrcRPNUcTYcdQ0/rk9R2jLejaFXjBZk2gUG 5Cm+kT/In7TO3HdH4rRrSlVU2jHRdVdKVZWxnDFXlysqqyKsqrXY0P4QwDo1akAjSikP isU5VRMINhXuNeYscASB3lm3B/kzoQ/li5liGMRuBlP2fxPpsxgHLQmuHwVRFFWhTCIG iZSTzPGQ0zH6ECV2mD22vLOzrkTRTCts0PpjYN0LRctMvoSzxxHI5rWfv9gcCHSquow4 sRP4EaPgd5Zg2TEZhDMI9W4RUSaYmA0VJZ+Hj+IlNG3Ilh6YC7GuLp7NwK8DQc2TjXEp 610A==
X-Gm-Message-State: AG10YOTr/24Aydm2L8fMio6MYTfnpcO+korZuSaSKjLpVvagnPc52G4sUDTAswgy458UzIfTAJfWpP2+baRQQA==
X-Received: by 10.112.156.164 with SMTP id wf4mr1641909lbb.15.1453480372722; Fri, 22 Jan 2016 08:32:52 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Thomas Broyer 
Date: Fri, 22 Jan 2016 16:32:43 +0000
Message-ID: 
To: John Bradley , Michael Jones 
Content-Type: multipart/alternative; boundary=001a11c34b7a4de4120529eec537
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 16:33:01 -0000

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

Hi John,


Le jeu. 21 janv. 2016 15:42, John Bradley  a =C3=A9crit =
:

> We merged the state verification in with this rather than forcing people
> to also look at the JWT encoded State draft.
> https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state.
>
> While JWT encoded state is how I would do state in a client and at-least
> one client I know of uses it, it is not the only way to manage state,
>

And not how I'd do it (unless you convince me that jwt is really better and
the advantages outweigh the network bloat)

and I am hesitant that developers might be scared away by thinking they
> need to encode state as a JWT.
>
> I decided that cross referencing them is better.   This made sending much
> simpler to describe.
>

Wouldn't linking to RFC 6819 be enough?

I also removed the hashing from state.   That cut the text by about 2/3 by
> not having to describe character set normalization so that both the clien=
t
> and the AS could calculate the same hash.
> That also achieved the goal of not requiring a simple OAuth client doing
> the code flow to add a crypto library to support SHA256.
>
> Once we make a algorithm mandatory, we need to defend why we don=E2=80=99=
t have
> crypto agility eg support for SHA3 etc.  We would be forced by the IESG t=
o
> add another parameter to the request to specify the hash alg if we went
> that direction.
>
> Given that we assume state to be public info in the request that an
> attacker can see, hashing state provides not much value for a lot of
> complexity that people may get wrong or not implement.
>
> I appreciate why from a theory point of view hashing it would have been
> better.
>
> If people really want it I can add it back.
>
> John B.
>
> On Jan 21, 2016, at 3:28 AM, Mike Jones 
> wrote:
>
> John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up
> Mitigation draft.  Changes were:
> =C2=B7       Simplified by no longer specifying the signed JWT method for
> returning the mitigation information.
> =C2=B7       Simplified by no longer depending upon publication of a disc=
overy
> metadata document.
> =C2=B7       Added the =E2=80=9Cstate=E2=80=9D token request parameter.
> =C2=B7       Added examples.
> =C2=B7       Added John Bradley as an editor.
>
> The specification is available at:
> =C2=B7       http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigati=
on-01
>
> An HTML-formatted version is also available at:
> =C2=B7
> http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html
>
>                                                           -- Mike
>
> P.S.  This note was also posted at http://self-issued.info/?p=3D1526 and =
as
> @selfissued .
>
> _______________________________________________
> 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
>

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


Hi John,


Le=C2=A0jeu. 21 janv. 2016 15:42,=C2=
=A0John Bradley <ve7jtb@ve7jtb.com<=
/a>> a =C3=A9crit=C2=A0:
We merged the state verification in with this =
rather than forcing people to also look at the JWT encoded State draft. =C2=
=A0https://tools.ietf.org/html/draft-bradley-oauth-jwt=
-encoded-state. =C2=A0

While JWT encoded state is ho=
w I would do state in a client and at-least one client I know of uses it, i=
t is not the only way to manage state,
<=
br>
And not how I'd do it (unless you convince me that jwt is=
 really better and the advantages outweigh the network bloat)
and I am hesitant that developers might be=
 scared away by thinking they need to encode state as a JWT.

=

I decided that cross referencing them is better. =C2=A0 This mad=
e sending much simpler to describe. =C2=A0=C2=A0

Wouldn't linking to=C2=A0RFC 6819 be enough?

I also removed the hashing from s=
tate. =C2=A0 That cut the text by about 2/3 by not having to describe chara=
cter set normalization so that both the client and the AS could calculate t=
he same hash.
That also achieved the goal of not requiring a simp=
le OAuth client doing the code flow to add a crypto library to support SHA2=
56.

Once we make a algorithm mandatory, we need to=
 defend why we don=E2=80=99t have crypto agility eg support for SHA3 etc.=
=C2=A0 We would be forced by the IESG to add another parameter to the reque=
st to specify the hash alg if we went that direction.

<=
div>Given that we assume state to be public info in the request that an att=
acker can see, hashing state provides not much value for a lot of complexit=
y that people may get wrong or not implement.

I ap=
preciate why from a theory point of view hashing it would have been better.=


If people really want it I can add it back.
=


John B.
=


On Jan 21, 2016, at 3:28 AM, M=
ike Jones <Michael.Jones@microsoft.com> wrote:

John Brad=
ley and I collaborated to create the second OAuth 2.0 Mix-Up Mitigation dra=
ft.=C2=A0 Changes were:
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Simplified by no longer specifying the signed JWT=
 method for returning the mitigation information.
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Simplified by no longer=
 depending upon publication of a discovery metadata document.=

=C2=B7=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Added the =
=E2=80=9Cstate=E2=
=80=9D token request parameter.
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0Added examples.
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0Added John Bradley as a=
n editor.
=C2=A0
=
The specification is available at:
=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://tools.ietf.org/html/draft-j=
ones-oauth-mix-up-mitigation-01
=C2=
=A0
An HTML-formatted version is also available at:
=
=C2=B7=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigatio=
n-01.html
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
=C2=A0
P.S.=C2=A0 This note was als=
o posted at=C2=A0=
http://self-issued.info/?p=3D1526=C2=A0and=C2=
=A0as=C2=A0=
@s=
elfissued.
=C2=A0
______________________________=
_________________
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




--001a11c34b7a4de4120529eec537--


From nobody Fri Jan 22 08:39:18 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FFA1B29B3 for ; Fri, 22 Jan 2016 08:39:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NoU2iTpXoPg for ; Fri, 22 Jan 2016 08:39:15 -0800 (PST)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 1A0E61B29C8 for ; Fri, 22 Jan 2016 08:39:15 -0800 (PST)
Received: by mail-qg0-x236.google.com with SMTP id b35so61236767qge.0 for ; Fri, 22 Jan 2016 08:39:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=jDApSJ/mwpVWZI7/1WaEG1Fd/xYRxv5y+ISEqo0GhAc=; b=Q8Za4idjIaZ6V2fu6x290EMk7hORzFzK0lc/YAgR2iZpfW3flZirGISBbIM+WX/gMS aU4RJuv0Tm9xrXakAfAM0bB5eOULMbc5I85266O2MwXpsehGyELwiy80il9VNAUedsNT wmzu9JTcBy4KbPOHeURXMXJUR6AhDcYvSwhAxlJBFw0HQlqGXzVDyYnxJlfmKHu7Fq8B f0jH3mn6LPHjeT0dZFwPXbJ1Zr1tjQ3nbVH0hs1j1yQKQJPuQgMCrp4zuL5ar32MOnb3 4n2IEvHHqJq2iJk6KHcR89hBYrkmgIrcxqBY+W0MrOtE7qavV+qXIdwb7lL4uk9xZEW4 vyLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=jDApSJ/mwpVWZI7/1WaEG1Fd/xYRxv5y+ISEqo0GhAc=; b=Ec1d2OeCkHnRCyVL1naz8oSuwAg0LVj00e4G++YSeK6q137O0S+PnNLrzmcKCGElgY 1k6LeEHO8q6aQy3rABDsljjvRUDyF80+vwYvVkRD1jfp/k4BK8OROlsIlicpZg97d/Rd cZMUZumm9AFraIl2E+jTHGLLJBCXbVMVb8JSbzZE+xMl76Nna8cZrCzM7I2Sp5D8eqpx yMAmuK37KILtJD/ihHlXA584WY461zCLR7RMgR5/1BvWrr4u+PTOeVOPzecTsu6VOYc4 dirwtACGDIhyd1+l1fB2a5axE7V3RkqkhQlSNCq7qOwpXcx7M5+7B83ev/SlcSUJbnN1 +oBg==
X-Gm-Message-State: AG10YOQrivEKPQIk/dVc3/jbvqydNTiSLG+VRi6X3vr7WZ3NKClFgxFiy2LDuumklostjg==
X-Received: by 10.140.226.8 with SMTP id w8mr5117644qhb.83.1453480754105; Fri, 22 Jan 2016 08:39:14 -0800 (PST)
Received: from [192.168.8.100] ([181.202.234.84]) by smtp.gmail.com with ESMTPSA id v65sm3038512qhc.46.2016.01.22.08.39.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 08:39:13 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_8CB6183F-AD4B-44CC-9149-1BDEE688DB4C"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56A171E9.6060705@bucksch.org>
Date: Fri, 22 Jan 2016 13:39:09 -0300
Message-Id: 
References: <56A171E9.6060705@bucksch.org>
To: Ben Bucksch 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] JWT compares client time with server time
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 16:39:17 -0000

--Apple-Mail=_8CB6183F-AD4B-44CC-9149-1BDEE688DB4C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Sorry to hear about your debugging trouble.

JWT is a security token format, a bit like SAML.

It has =E2=80=9Ciat=E2=80=9D (issued at) as one of the optional claims =
that a protocol can use.
It is defined similarly to IssueInstant in SAML.

It is the protocols that use JWT that need to define the comparison =
rules, the value is what it is, and a receiver needs to  accommodate =
clock drift in both cases.

OAuth is just starting to define a JWT access token for PoP.  =
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution
That has iat in the example but nothing calling it out in the validation =
rules at the RS.   That is something I will note.

OpenID Connect defines the use of iat in id_tokens

	=E2=80=A2 The iat Claim can be used to reject tokens that were =
issued too far away from the current time, limiting the amount of time =
that nonces need to be stored to prevent attacks. The acceptable range =
is Client specific.

In that case it is used to manage the cache for replay protection.

For exp we do note in Connect:
	=E2=80=A2 The current time MUST be before the time represented =
by the exp Claim (possibly allowing for some small leeway to account for =
clock skew).

It is not clear from your email what protocol you are trying to use JWT =
in.

At the JWT level we don=E2=80=99t know what a protocol is going to use =
iat for so specific advice on managing clock skew is difficult.

Regards
John B.


> On Jan 21, 2016, at 9:03 PM, Ben Bucksch  wrote:
>=20
> Story: We wrote a script implementing JWT.
>=20
> The code was working for my colleague, who wrote the script, but I =
just got "Invalid authentication credentials".
>=20
> We were debugging it for days (!), suspecting shell argument passing =
and parsing, OS differences and what not. We compared credentials and =
confirmed they are identical. Still, the result was different. During =
debugging, once, by coincidence, it worked - at a time when it should be =
expired.
>=20
> What was the reason? My clock on my computer was fast.
>=20
> I was speechless. Client/server protocols must NEVER compare client =
clocks with server clocks, because clocks are very often off. Even if it =
was originally set exactly right by the second, clocks always have a =
drift in one way or another. If you have 5 million users, you will =
surely have 500000 whose clocks are off by 1 minute, and 50000 users =
whose clocks are off more than that.
> In my case, my clock was 95 seconds fast. That's not uncommon. You =
cannot expect nor demand that every computer in the world runs NTP =
clients.
>=20
> OAuth 2.0 knows that and does not rely on client clock matching server =
clock. For good reason. Ditto HTTP Cache headers don't send client time, =
even though that's an obvious and simple implementation, but the server =
sends and ETag and the client echos it back. Even if that's a more =
complex implementation, it's crucial to work reliably.
>=20
> =
------------------------------------------------------------------------
>=20
> Worse, in JWT, iat (time of issue, created by JWT client) is often =
enforced with second precision on the JWT server. A client clock that is =
just 3 seconds fast (very likely) will cause an iat in the future, which =
makes the server reject it.
>=20
> You simply cannot compare client clock with server clocks. Please =
change the protocol to not do that, or take JWT off the proposed =
standards track.
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_8CB6183F-AD4B-44CC-9149-1BDEE688DB4C
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjIxNjM5MTBaMCMGCSqGSIb3DQEJBDEWBBShpBX3Fd5Q8PMwnht/4d+c
QXs0STCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCl86QrTfx/0Pt1ltFzNrTLJnZ5mx67tLHAwLEzE5LIRayMeGf0l51o
UFoqC8eYlR/N47nJDb+MhbXTdXA78+LoL+vquLW+OhD2pYK4O0FmOQ0qvhAifX67twJCDfOcaV2j
+mOzy7qR/6c9tnoLQPsEkSS/oPjd59T0+QzHPp+L2RNjDEAx7anX0pC5S71UTg1Vu3L0hlEV63N7
375bSakiBdMVRzFb/eO33cb3u8QuPYnB4dakTEtvuzHFTD30FHa5Pl3bUIVABvgbVI/yWX7KBjEJ
g+M6pfOXA+BhpBjutrAj0mYM+iax9nCJt2wmcLCzvBjI3x2IZuRSGhYIqLjkAAAAAAAA
--Apple-Mail=_8CB6183F-AD4B-44CC-9149-1BDEE688DB4C--


From nobody Fri Jan 22 08:58:15 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A1F1B2A03 for ; Fri, 22 Jan 2016 08:58:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykH_XPkVHn5s for ; Fri, 22 Jan 2016 08:58:11 -0800 (PST)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 CD2EA1B2A01 for ; Fri, 22 Jan 2016 08:58:10 -0800 (PST)
Received: by mail-qg0-x22a.google.com with SMTP id o11so61752903qge.2 for ; Fri, 22 Jan 2016 08:58:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=S/6gwuphmDjWMf8qjNFZquoZUqRQZjwi40HLqNwVA1M=; b=J2E4KTwBTSEqR/l4GB3J3/Y0oiuXatN3LjTuD3x/Apwf75djJZu/biFLpsyHsC/blM WKGegiij2kUlHd+Z1xwEt0dbRjcyJ03ZDGulZB+37i+v+7cc/UF51qFW9wF6N5qtJzSi 4UByuZAegHB5DSeuC/zw0J1xHKyiW0+U1W1wdim07Bm8f2D7lY40/K3WJkXCxV0FyMrd lXyNWQcjxw7m4g57LRUQYV1YvHz/1XhAfUMdoo0X4nzJEY9k6N1FOb4Fz0uxrdjtfYxA m6Zxf0GKUho26zXWLcSTc1rtx58eHN8vWoVu6bjntsrskzucouQF8JMc7VBMsGdQ2tPc lCtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=S/6gwuphmDjWMf8qjNFZquoZUqRQZjwi40HLqNwVA1M=; b=M0F5d9YdYx/Q/QfTR13M4FOVBAwV2h1gbw6gjlLSK6Nako/BGPHhlPDwq182yOhwY3 q37WkgonP9FDWbPuKtccIkEjhSYEFZPTUBu97AQ0JZR8Bv55Cuo2eSDb+flHhUH6xtZQ cI7XN3jbKiYu3Z84y8maNQOj4/uIRy1T1oSGJ8bbNUnw/oPgiW6mdrrLLBLqEKEHy61b NXg9jW3hpnvDoBJIZK2d7zoRajDR8l2xNcCp8VF/rpiCs6bpZAPB3/OSblekQ8PSuEN8 6TI+MorxlbU5Eqf3GQjt2neBu6WeAT0lfLhdeXHr3WnuVGFhSvukbZh1JZ69PTcgPooL +Ubg==
X-Gm-Message-State: AG10YOQyo8T0rygl/LoeyT9PuS9P+jSYAUMuGLLHofbjUbcbohix1NiW3HxsZs0ZHFHeaQ==
X-Received: by 10.140.238.88 with SMTP id j85mr5227526qhc.88.1453481889733; Fri, 22 Jan 2016 08:58:09 -0800 (PST)
Received: from [192.168.8.100] ([181.202.234.84]) by smtp.gmail.com with ESMTPSA id m127sm3072587qhm.43.2016.01.22.08.58.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 08:58:08 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_9C207140-6239-409A-BB0F-1F46597FD0A2"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Fri, 22 Jan 2016 13:58:04 -0300
Message-Id: <6CDFB94F-5343-4DFB-BAC4-53570FBED58E@ve7jtb.com>
References:   
To: Thomas Broyer 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 16:58:14 -0000

--Apple-Mail=_9C207140-6239-409A-BB0F-1F46597FD0A2
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C7E7DFE3-7061-49F8-BD0E-41847AFD86F2"


--Apple-Mail=_C7E7DFE3-7061-49F8-BD0E-41847AFD86F2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I agree that using a JWT is not the only way to do it, however many =
clients were not sending state at all or doing something insecure.

Particularly some people were having trouble with AS like Google who do =
exact redirect_uri matching and not being able to see how to pass =
multiple parameters in state rather then tacking extra query parameters =
on to the redirect_uri.

Documenting how to do it with a JWT and some of the security =
considerations specific to crating a useful state value has been useful =
to some people.

RFC 6819 has only a short section on state.

3.6 .  "state" =
Parameter

   The "state" parameter is used to link requests and callbacks to
   prevent cross-site request forgery attacks (see Section 4.4.1.8 =
)
   where an attacker authorizes access to his own resources and then
   tricks a user into following a redirect with the attacker's token.
   This parameter should bind to the authenticated state in a user agent
   and, as per the core OAuth spec, the user agent must be capable of
   keeping it in a location accessible only by the client and user
   agent, i.e., protected by same-origin policy.

That is a bit hand wavy for some developers who wanted examples.

In any event I think we agree that dragging the whole JWT signed state =
draft into the checking state mitigation.

The mitigation makes checking the integrity of state by the client =
signing less important, as tampering with the value would be detected by =
the server in the code flow.

Perhaps as we develop the mitigation spec we could move some of the more =
critical advice on how to bind the browser instance to the state over to =
the mitigation draft.

John B.


> On Jan 22, 2016, at 1:32 PM, Thomas Broyer  wrote:
>=20
>=20
> Hi John,
>=20
>=20
> Le jeu. 21 janv. 2016 15:42, John Bradley > a =C3=A9crit :
> We merged the state verification in with this rather than forcing =
people to also look at the JWT encoded State draft.  =
https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state =
. =20
>=20
> While JWT encoded state is how I would do state in a client and =
at-least one client I know of uses it, it is not the only way to manage =
state,
>=20
> And not how I'd do it (unless you convince me that jwt is really =
better and the advantages outweigh the network bloat)
>=20
> and I am hesitant that developers might be scared away by thinking =
they need to encode state as a JWT.
>=20
> I decided that cross referencing them is better.   This made sending =
much simpler to describe.  =20
>=20
> Wouldn't linking to RFC 6819 be enough?
>=20
> I also removed the hashing from state.   That cut the text by about =
2/3 by not having to describe character set normalization so that both =
the client and the AS could calculate the same hash.
> That also achieved the goal of not requiring a simple OAuth client =
doing the code flow to add a crypto library to support SHA256.
>=20
> Once we make a algorithm mandatory, we need to defend why we don=E2=80=99=
t have crypto agility eg support for SHA3 etc.  We would be forced by =
the IESG to add another parameter to the request to specify the hash alg =
if we went that direction.
>=20
> Given that we assume state to be public info in the request that an =
attacker can see, hashing state provides not much value for a lot of =
complexity that people may get wrong or not implement.
>=20
> I appreciate why from a theory point of view hashing it would have =
been better.
>=20
> If people really want it I can add it back.
>=20
> John B.
>=20
>> On Jan 21, 2016, at 3:28 AM, Mike Jones > wrote:
>>=20
>> John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up =
Mitigation draft.  Changes were:
>> =C2=B7       Simplified by no longer specifying the signed JWT method =
for returning the mitigation information.
>> =C2=B7       Simplified by no longer depending upon publication of a =
discovery metadata document.
>> =C2=B7       Added the =E2=80=9Cstate=E2=80=9D token request =
parameter.
>> =C2=B7       Added examples.
>> =C2=B7       Added John Bradley as an editor.
>> =20
>> The specification is available at:
>> =C2=B7       =
http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 =

>> =20
>> An HTML-formatted version is also available at:
>> =C2=B7       =
http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html =
=

>> =20
>>                                                           -- Mike
>> =20
>> P.S.  This note was also posted at http://self-issued.info/?p=3D1526 =
 and as @selfissued =
.
>> =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=_C7E7DFE3-7061-49F8-BD0E-41847AFD86F2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I agree that using a JWT is not the only way to do it, =
however many clients were not sending state at all or doing something =
insecure.

Particularly=
 some people were having trouble with AS like Google who do exact =
redirect_uri matching and not being able to see how to pass multiple =
parameters in state rather then tacking extra query parameters on to the =
redirect_uri.

Documenting how to do it with a JWT and some of the security =
considerations specific to crating a useful state value has been useful =
to some people.

RFC 6819 has only a short section on state.

3.6.  "state" Parameter


   The "state" parameter is used to link requests and callbacks to
   prevent cross-site request forgery attacks (see Section 4.4.1.8)
   where an attacker authorizes access to his own resources and then
   tricks a user into following a redirect with the attacker's token.
   This parameter should bind to the authenticated state in a user agent
   and, as per the core OAuth spec, the user agent must be capable of
   keeping it in a location accessible only by the client and user
   agent, i.e., protected by same-origin policy.


That is =
a bit hand wavy for some developers who wanted examples.

In any event I think we =
agree that dragging the whole JWT signed state draft into the checking =
state mitigation.

The mitigation makes checking the integrity of state by the =
client signing less important, as tampering with the value would be =
detected by the server in the code flow.

Perhaps as we develop the mitigation =
spec we could move some of the more critical advice on how to bind the =
browser instance to the state over to the mitigation draft.

John B.


On =
Jan 22, 2016, at 1:32 PM, Thomas Broyer <t.broyer@gmail.com> =
wrote:


Hi John,


Le jeu. 21 janv. 2016 15:42, John =
Bradley <ve7jtb@ve7jtb.com> a =C3=A9crit :
We merged the state =
verification in with this rather than forcing people to also look at the =
JWT encoded State draft.  https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-sta=
te.  

While =
JWT encoded state is how I would do state in a client and at-least one =
client I know of uses it, it is not the only way to manage =
state,

And =
not how I'd do it (unless you convince me that jwt is really better and =
the advantages outweigh the network bloat)

and I am hesitant that developers might be scared away by =
thinking they need to encode state as a JWT.

I decided that cross referencing them =
is better.   This made sending much simpler to describe. =
  

Wouldn't linking to RFC 6819 be enough?

I also removed the hashing from =
state.   That cut the text by about 2/3 by not having to describe =
character set normalization so that both the client and the AS could =
calculate the same hash.
That also achieved the =
goal of not requiring a simple OAuth client doing the code flow to add a =
crypto library to support SHA256.

Once we make a algorithm mandatory, we =
need to defend why we don=E2=80=99t have crypto agility eg support for =
SHA3 etc.  We would be forced by the IESG to add another parameter =
to the request to specify the hash alg if we went that =
direction.

Given=
 that we assume state to be public info in the request that an attacker =
can see, hashing state provides not much value for a lot of complexity =
that people may get wrong or not implement.

I appreciate why from a theory point of =
view hashing it would have been better.

If people really want it I can add it =
back.

John =
B.

On Jan 21, 2016, at 3:28 AM, Mike Jones =
<Michael.Jones@microsoft.com> wrote:

John Bradley and I =
collaborated to create the second OAuth 2.0 Mix-Up Mitigation =
draft.  Changes were:
=C2=B7       Simplified by no longer =
specifying the signed JWT method for returning the mitigation =
information.
=C2=B7       Simplified by no longer =
depending upon publication of a discovery metadata document.
=C2=B7       Added the =E2=80=9Cstate=E2=80=9D =
token request parameter.
=C2=B7       Added examples.
=C2=B7       Added John Bradley as an =
editor.
 
The specification is available at:
 
An HTML-formatted version is also =
available at:
=C2=B7       http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigatio=
n-01.html
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;          -- Mike
 
P.S.  This note was also posted at http://self-issued.info/?p=3D1526 and as @selfissued.
 
_______________________________________________
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=_C7E7DFE3-7061-49F8-BD0E-41847AFD86F2--

--Apple-Mail=_9C207140-6239-409A-BB0F-1F46597FD0A2
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjIxNjU4MDVaMCMGCSqGSIb3DQEJBDEWBBSn2ueLPsAKMmrkypgK+WM4
pAUrzTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCp8y0c92dve/Ke7zAgnU8zJ5IoVhPFwhwGj5rE89AiKTsY9MX+Ugkj
vBZC8ymZGpd9ja81WePp0PtKB57J7J9H+E4rHJjBOKRhT5MeKtyj+/Sc3nq0XR1nZaREVnj8/wMe
oyJwHAftiV7xORdbvGDmxYKIfhr8zzp3qsu68v2uqpzzfOPFfT0T1R26i9wXNI0KgaO9bSwXaQVz
QAuOYiyQ2YhGjy/xiOQAKRSPffM9bxIcj/NIwyOZ1W0OEGq38bpiOrYXopH+EmOXhxmwOSWpj6sn
3wgzwcafpIR5d2hdvl4VNrz2ARcQY6dJualuOsj946aHzYtsAEN0sujxBUh9AAAAAAAA
--Apple-Mail=_9C207140-6239-409A-BB0F-1F46597FD0A2--


From nobody Fri Jan 22 09:02:54 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8C51B2A23 for ; Fri, 22 Jan 2016 09:02:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JreOdWwrVTFE for ; Fri, 22 Jan 2016 09:02:50 -0800 (PST)
Received: from omr-a013e.mx.aol.com (omr-a013e.mx.aol.com [204.29.186.60]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF611B2A0F for ; Fri, 22 Jan 2016 09:02:50 -0800 (PST)
Received: from mtaout-aaj02.mx.aol.com (mtaout-aaj02.mx.aol.com [172.27.3.206]) by omr-a013e.mx.aol.com (Outbound Mail Relay) with ESMTP id B013A380008B; Fri, 22 Jan 2016 12:02:49 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aaj02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 4E6AB380000A8; Fri, 22 Jan 2016 12:02:48 -0500 (EST)
To: William Denniss , John Bradley , David Waite 
References:  <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com>  <80218A07-9D37-42A3-B90A-56AEDBC3A86C@alkaline-solutions.com>  
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56A260B6.4060302@aol.com>
Date: Fri, 22 Jan 2016 12:02:46 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090606080907030607060904"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453482169; bh=AC4x39l/J4ZZCqiPl93lw217eHL5tMBOAyYSKmREQeY=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=hlINPlFPhC6uyJQbn1T+jN4cs5y5R4HLFu/wWNt81koMyYydkyw9+x5JZ+jqzZgD1 jveC3ZJGcPzOcQVFbkHG5jVaadMuV4o2lfGnp/nhglRUXlAxmC7bjKkPLI2YKk1T2p K1TCY3mxpViAEcZf2NWesarEvWFHXIsuBo8Gr2Qk=
x-aol-sid: 3039ac1b03ce56a260b84119
X-AOL-IP: 10.172.102.124
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 17:02:53 -0000

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

"Frankensteinian Amalgamation" -- David Waite

I like it! :)

On 1/22/16 8:11 AM, William Denniss wrote:
> +1 ;)
> On Fri, Jan 22, 2016 at 8:45 PM John Bradley  > wrote:
>
>     Perhaps Frankenstein response is a better name than cut and paste
>     attack.
>
>     John B.
>
>     On Jan 22, 2016 1:22 AM, "David Waite"
>          > wrote:
>
>>         On Jan 21, 2016, at 2:50 PM, John Bradley >         > wrote:
>>
>>         In that case you probably would put a hash of the state in
>>         the code to manage size.  The alg would be up to the AS, as
>>         long as it used the same hash both places it would work.
>         Yes, true.
>>
>>         Sending the state to the token endpoint is like having nonce
>>         and c_hash in the id_token, it binds the issued code to the
>>         browser instance.
>         I think I understand what you are saying. Someone won’t be
>         able to frankenstein up a state and a token from two different
>         responses from an AS, and have a client successfully fetch an
>         access token based on the amalgamation.
>>         This protects against codes that leak via redirect uri
>>         pattern matching. failures etc.  It prevents an attacker from
>>         being able to replay a code from a different browser.
>         Yes, if a party intercepts the redirect_url, or the AS fails
>         to enforce one time use (which even for a compliant
>         implementation could just mean the attacker was faster than
>         the state propagated within the AS)
>
>         Makes sense. Thanks John.
>
>         -DW
>
>>         If the client implements the other mitigations on the
>>         authorization endpoint, then it wouldn't be leaking the code
>>         via the token endpoint.
>>
>>         The two mitigations are for different attacks, however some
>>         of the attacks combined both vulnerabilities.
>>
>>         Sending the iss and client_id is enough to stop the confused
>>         client attacks, but sending state on its own would not have
>>         stopped all of them.
>>
>>         We discussed having them in separate drafts, and may still do
>>         that.   However for discussion having them in one document is
>>         I think better in the short run.
>>
>>         John B.
>>
>>>         On Jan 21, 2016, at 4:48 PM, David Waite
>>>         >>         > wrote:
>>>
>>>         Question:
>>>
>>>         I understand how “iss" helps mitigate this attack (client
>>>         knows response was from the appropriate issuer and not an
>>>         attack where the request was answered by another issuer).
>>>
>>>         However, how does passing “state†on the authorization_code
>>>         grant token request help once you have the above in place?
>>>         Is this against some alternate flow of this attack I don’t
>>>         see, or is it meant to mitigate some entirely separate attack?
>>>
>>>         If one is attempting to work statelessly (e.g. your “stateâ€
>>>         parameter is actual state and not just a randomly generated
>>>         value), a client would have always needed some way to
>>>         differentiate which issuer the authorization_code grant
>>>         token request would be sent to.
>>>
>>>         However, if an AS was treating “code†as a token (for
>>>         instance, encoding: client, user, consent time and approved
>>>         scopes), the AS now has to include the client’s state as
>>>         well. This would effectively double (likely more with
>>>         encoding) the state sent in the authorization response back
>>>         to the client redirect URL, adding more pressure against
>>>         maximum URL sizes.
>>>
>>>         -DW
>
>     _______________________________________________
>     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

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


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


  
    
  
  
    "Frankensteinian Amalgamation"
      -- David Waite

      

      I like it! :)

    

    
On 1/22/16 8:11 AM, William Denniss
      wrote:

    

    
+1 ;)

      

        
On Fri, Jan 22, 2016 at 8:45 PM John Bradley <ve7jtb@ve7jtb.com>
          wrote:

        

        

          
Perhaps Frankenstein response is a better name
            than cut and paste attack. 

          
John B.   

          
On Jan 22, 2016 1:22 AM, "David
            Waite" <david@alkaline-solutions.com>
            wrote:

            

              

                

                  

                    
On Jan 21, 2016, at 2:50 PM, John Bradley <ve7jtb@ve7jtb.com>
                      wrote:

                    

                    

                      

                        
In that case you probably would put a hash
                          of the state in the code to manage size.  The
                          alg would be up to the AS, as long as it used
                          the same hash both places it would work.

                      

                    

                  

                  Yes, true. 

                  

                    

                      

                        


                        

                        
Sending the state to the token endpoint is
                          like having nonce and c_hash in the id_token,
                          it binds the issued code to the browser
                          instance.

                      

                    

                  

                  I think I understand what you are saying. Someone
                  won’t be able to frankenstein up a state and a token
                  from two different responses from an AS, and have a
                  client successfully fetch an access token based on the
                  amalgamation.

                
 

                

                  

                    

                      
This protects against codes that leak via
                        redirect uri pattern matching. failures etc.  It
                        prevents an attacker from being able to replay a
                        code from a different browser.

                    

                  

                  Yes, if a party intercepts the redirect_url, or the AS
                  fails to enforce one time use (which even for a
                  compliant implementation could just mean the attacker
                  was faster than the state propagated within the AS)

                


                

                
Makes sense. Thanks John.

                


                

                
-DW

                


                

                

                  

                    

                      
If the client implements the other
                        mitigations on the authorization endpoint, then
                        it wouldn't be leaking the code via the token
                        endpoint. 

                      


                      

                      
The two mitigations are for different
                        attacks, however some of the attacks combined
                        both vulnerabilities.

                      


                      

                      
Sending the iss and client_id is enough to
                        stop the confused client attacks, but sending
                        state on its own would not have stopped all of
                        them.

                      


                      

                      
We discussed having them in separate drafts,
                        and may still do that.   However for discussion
                        having them in one document is I think better in
                        the short run.

                      


                      

                      
John B.

                      


                      

                      

                        

                          

                            
On Jan 21, 2016, at 4:48 PM, David
                              Waite <david@alkaline-solutions.com>
                              wrote:

                            

                            

                              
Question: 
                                


                                

                                
I understand how “iss" helps
                                  mitigate this attack (client knows
                                  response was from the appropriate
                                  issuer and not an attack where the
                                  request was answered by another
                                  issuer). 
                                  


                                  

                                  
However, how does passing “stateâ€
                                    on the authorization_code grant
                                    token request help once you have the
                                    above in place? Is this against some
                                    alternate flow of this attack I
                                    don’t see, or is it meant to
                                    mitigate some entirely separate
                                    attack?

                                  


                                  

                                  
If one is attempting to work
                                    statelessly (e.g. your “stateâ€
                                    parameter is actual state and not
                                    just a randomly generated value), a
                                    client would have always needed some
                                    way to differentiate which issuer
                                    the authorization_code grant token
                                    request would be sent to.

                                  


                                  

                                  
However, if an AS was treating
                                    “code†as a token (for instance,
                                    encoding: client, user, consent time
                                    and approved scopes), the AS now has
                                    to include the client’s state as
                                    well. This would effectively double
                                    (likely more with encoding) the
                                    state sent in the authorization
                                    response back to the client redirect
                                    URL, adding more pressure against
                                    maximum URL sizes.

                                  


                                  

                                  
-DW

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

          

          _______________________________________________

          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


    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------090606080907030607060904--


From nobody Fri Jan 22 09:54:13 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B519B1B2B17 for ; Fri, 22 Jan 2016 09:54:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_FAIL=0.001, SPF_HELO_FAIL=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfuBojco2BKO for ; Fri, 22 Jan 2016 09:54:09 -0800 (PST)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB941B2B10 for ; Fri, 22 Jan 2016 09:54:09 -0800 (PST)
Received: from [192.168.16.27] (c-50-155-144-64.hsd1.co.comcast.net [50.155.144.64]) by alkaline-solutions.com (Postfix) with ESMTPSA id 800C7315B1; Fri, 22 Jan 2016 17:54:08 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3C380A9B-6C21-4D72-8ACE-AB43E8E07788"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: David Waite 
In-Reply-To: <56A260B6.4060302@aol.com>
Date: Fri, 22 Jan 2016 10:54:07 -0700
Message-Id: <478C8683-0E47-43E7-A7F3-75F89AB1DCDA@alkaline-solutions.com>
References:  <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com>  <80218A07-9D37-42A3-B90A-56AEDBC3A86C@alkaline-solutions.com>   <56A260B6.4060302@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 17:54:11 -0000

--Apple-Mail=_3C380A9B-6C21-4D72-8ACE-AB43E8E07788
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

It=E2=80=99s pronounced FronkenSTEEN-ian.

-DW

> On Jan 22, 2016, at 10:02 AM, George Fletcher  =
wrote:
>=20
> "Frankensteinian Amalgamation" -- David Waite
>=20
> I like it! :)
>=20
> On 1/22/16 8:11 AM, William Denniss wrote:
>> +1 ;)
>> On Fri, Jan 22, 2016 at 8:45 PM John Bradley < =
ve7jtb@ve7jtb.com > =
wrote:
>> Perhaps Frankenstein response is a better name than cut and paste =
attack.
>>=20
>> John B. =20
>>=20
>> On Jan 22, 2016 1:22 AM, "David Waite" > wrote:
>>> On Jan 21, 2016, at 2:50 PM, John Bradley < =
ve7jtb@ve7jtb.com > =
wrote:
>>>=20
>>> In that case you probably would put a hash of the state in the code =
to manage size.  The alg would be up to the AS, as long as it used the =
same hash both places it would work.
>> Yes, true.=20
>>>=20
>>> Sending the state to the token endpoint is like having nonce and =
c_hash in the id_token, it binds the issued code to the browser =
instance.
>> I think I understand what you are saying. Someone won=E2=80=99t be =
able to frankenstein up a state and a token from two different responses =
from an AS, and have a client successfully fetch an access token based =
on the amalgamation.
>> =20
>>> This protects against codes that leak via redirect uri pattern =
matching. failures etc.  It prevents an attacker from being able to =
replay a code from a different browser.
>> Yes, if a party intercepts the redirect_url, or the AS fails to =
enforce one time use (which even for a compliant implementation could =
just mean the attacker was faster than the state propagated within the =
AS)
>>=20
>> Makes sense. Thanks John.
>>=20
>> -DW
>>=20
>>> If the client implements the other mitigations on the authorization =
endpoint, then it wouldn't be leaking the code via the token endpoint.=20=

>>>=20
>>> The two mitigations are for different attacks, however some of the =
attacks combined both vulnerabilities.
>>>=20
>>> Sending the iss and client_id is enough to stop the confused client =
attacks, but sending state on its own would not have stopped all of =
them.
>>>=20
>>> We discussed having them in separate drafts, and may still do that.  =
 However for discussion having them in one document is I think better in =
the short run.
>>>=20
>>> John B.
>>>=20
>>>> On Jan 21, 2016, at 4:48 PM, David Waite =
> =
wrote:
>>>>=20
>>>> Question:=20
>>>>=20
>>>> I understand how =E2=80=9Ciss" helps mitigate this attack (client =
knows response was from the appropriate issuer and not an attack where =
the request was answered by another issuer).=20
>>>>=20
>>>> However, how does passing =E2=80=9Cstate=E2=80=9D on the =
authorization_code grant token request help once you have the above in =
place? Is this against some alternate flow of this attack I don=E2=80=99t =
see, or is it meant to mitigate some entirely separate attack?
>>>>=20
>>>> If one is attempting to work statelessly (e.g. your =E2=80=9Cstate=E2=
=80=9D parameter is actual state and not just a randomly generated =
value), a client would have always needed some way to differentiate =
which issuer the authorization_code grant token request would be sent =
to.
>>>>=20
>>>> However, if an AS was treating =E2=80=9Ccode=E2=80=9D as a token =
(for instance, encoding: client, user, consent time and approved =
scopes), the AS now has to include the client=E2=80=99s state as well. =
This would effectively double (likely more with encoding) the state sent =
in the authorization response back to the client redirect URL, adding =
more pressure against maximum URL sizes.
>>>>=20
>>>> -DW
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

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

>=20
> --=20
> Chief Architect                  =20
> Identity Services Engineering     Work: george.fletcher@teamaol.com =

> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch =

> Office: +1-703-265-2544           Photos: =
http://georgefletcher.photography 


--Apple-Mail=_3C380A9B-6C21-4D72-8ACE-AB43E8E07788
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

It=E2=80=99s pronounced FronkenSTEEN-ian.

-DW

On Jan 22, 2016, at 10:02 AM, George Fletcher <gffletch@aol.com> =
wrote:


 =20
    
 =20
  

    "Frankensteinian Amalgamation"
      -- David Waite

      

      I like it! :)

    

    
On 1/22/16 8:11 AM, William Denniss
      wrote:

    

    
+1 ;)

      

        
On Fri, Jan 22, 2016 at 8:45 PM John =
Bradley <ve7jtb@ve7jtb.com>
          wrote:

        

        
Perhaps Frankenstein response is a better name
            than cut and paste attack. 
John =
B.   

          
On Jan 22, 2016 1:22 AM, "David
            Waite" <david@alkaline-solutions.com>
            wrote:

            

              

                

                  

                    
On Jan 21, 2016, at 2:50 PM, John =
Bradley <ve7jtb@ve7jtb.com>
                      wrote:

                    

                    

                      

                        
In that case you probably would =
put a hash
                          of the state in the code to manage size.  =
The
                          alg would be up to the AS, as long as it used
                          the same hash both places it would work.

                      

                    

                  

                  Yes, true. 

                  

                    

                      

                        


                        

                        
Sending the state to the token =
endpoint is
                          like having nonce and c_hash in the id_token,
                          it binds the issued code to the browser
                          instance.

                      

                    

                  

                  I think I understand what you are saying. Someone
                  won=E2=80=99t be able to frankenstein up a state and a =
token
                  from two different responses from an AS, and have a
                  client successfully fetch an access token based on the
                  amalgamation.

                
 

                

                  

                    

                      
This protects against codes that =
leak via
                        redirect uri pattern matching. failures =
etc.  It
                        prevents an attacker from being able to replay a
                        code from a different browser.

                    

                  

                  Yes, if a party intercepts the redirect_url, or the AS
                  fails to enforce one time use (which even for a
                  compliant implementation could just mean the attacker
                  was faster than the state propagated within the =
AS)

                


                

                
Makes sense. Thanks John.

                


                

                
-DW

                


                

                

                  

                    

                      
If the client implements the other
                        mitigations on the authorization endpoint, then
                        it wouldn't be leaking the code via the token
                        endpoint. 

                      


                      

                      
The two mitigations are for =
different
                        attacks, however some of the attacks combined
                        both vulnerabilities.

                      


                      

                      
Sending the iss and client_id is =
enough to
                        stop the confused client attacks, but sending
                        state on its own would not have stopped all of
                        them.

                      


                      

                      
We discussed having them in =
separate drafts,
                        and may still do that.   However for =
discussion
                        having them in one document is I think better in
                        the short run.

                      


                      

                      
John B.

                      


                      

                      

                        

                          

                            
On Jan 21, 2016, at 4:48 PM, =
David
                              Waite <david@alkaline-solutions.com>
                              wrote:

                            

                            

                              
Question: 
                                


                                

                                
I understand how =E2=80=9C=
iss" helps
                                  mitigate this attack (client knows
                                  response was from the appropriate
                                  issuer and not an attack where the
                                  request was answered by another
                                  issuer). 
                                  


                                  

                                  
However, how does =
passing =E2=80=9Cstate=E2=80=9D
                                    on the authorization_code grant
                                    token request help once you have the
                                    above in place? Is this against some
                                    alternate flow of this attack I
                                    don=E2=80=99t see, or is it meant to
                                    mitigate some entirely separate
                                    attack?

                                  


                                  

                                  
If one is attempting =
to work
                                    statelessly (e.g. your =E2=80=9Cstate=E2=
=80=9D
                                    parameter is actual state and not
                                    just a randomly generated value), a
                                    client would have always needed some
                                    way to differentiate which issuer
                                    the authorization_code grant token
                                    request would be sent to.

                                  


                                  

                                  
However, if an AS was =
treating
                                    =E2=80=9Ccode=E2=80=9D as a token =
(for instance,
                                    encoding: client, user, consent time
                                    and approved scopes), the AS now has
                                    to include the client=E2=80=99s =
state as
                                    well. This would effectively double
                                    (likely more with encoding) the
                                    state sent in the authorization
                                    response back to the client redirect
                                    URL, adding more pressure against
                                    maximum URL sizes.

                                  


                                  

                                  
-DW

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

          

          _______________________________________________

          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
Chief Architect                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photogra=
phy


  




=

--Apple-Mail=_3C380A9B-6C21-4D72-8ACE-AB43E8E07788--


From nobody Fri Jan 22 10:57:17 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D521B2C16 for ; Fri, 22 Jan 2016 10:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3prLwcFbeXM for ; Fri, 22 Jan 2016 10:57:13 -0800 (PST)
Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d: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 0E4CE1B2C13 for ; Fri, 22 Jan 2016 10:57:12 -0800 (PST)
Received: by mail-qk0-x235.google.com with SMTP id s5so32283907qkd.0 for ; Fri, 22 Jan 2016 10:57:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=uO2AIHl8jqLEMr7nuciJDjF9ER55vnqq0urLzaqcZUA=; b=CNAXSECO5LHO1Z2WmioXg4sZ2WtPpdeAOY4SrzAQH7ItS+afD6QI6GUx/siHb2rI1c LUZ0l+pYW26Ezp0qi8pfjly4BqkZPG31VuyVkmIbrVBmZGTP1CvbVfES9v2WsKyQK4B7 7nai30VZo6YWM/3WCwi4GLvr38PBVZbOG2s/O8XOKpoMn8+livXF8Ez9jhGhQh7ZdcjP 6YwOD18Qq4l837BUazuEgo1CTDqlu/tq0n/fBBs0X2wK2/IS7calj006NKRMACdfKZy4 ztsbESqV+i3rugopU//oGj9RQgpLx6u3UDR3qNsmb2xt/1OtfGrtCijVJgzRWV4xcjeN uA+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=uO2AIHl8jqLEMr7nuciJDjF9ER55vnqq0urLzaqcZUA=; b=UKqQlKjumAhpyGIPH/6/5qR8wXIhwPdILbpM7Ory2zenpByYZwsiY37HqSl5UUCo9Z TiobntDOckdL4F0y/ZdiQk4WSEs0nuLoPw8Boaos7Ba/afvCOE3e2ZwB2PNacpbDWAL9 vhwkrhdgO7jfHxmuUb1Z9hRwdZOPG4/aTLqnyt7NcIUFYdKHqSDxk+0d2G47xU4O0kx2 FYNnhGnyuA/IxyysTEXUj7RwZ2NXJyFi4srGdy6CjbxoBIXa9sjF7QUArezqOcsAwUWO CQO3c6OEfaVXGlLygQMI5HOEWwMhiqKzOHCx5ZlnfUKKwy+fyTEaB7srVkap8uBevm0O AbMw==
X-Gm-Message-State: AG10YOSmpXMX1Dx9D+r81nY1NdI1qC5huzll5qPpo+kcdg3AESXYrZWZhnLYUSiIQcsDNg==
X-Received: by 10.55.77.216 with SMTP id a207mr5727402qkb.80.1453489032059; Fri, 22 Jan 2016 10:57:12 -0800 (PST)
Received: from [192.168.8.100] ([181.202.234.84]) by smtp.gmail.com with ESMTPSA id 75sm3337816qkw.19.2016.01.22.10.57.10 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 10:57:11 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_15D6CBDD-FC80-453E-8E89-312FD8DD08A3"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <478C8683-0E47-43E7-A7F3-75F89AB1DCDA@alkaline-solutions.com>
Date: Fri, 22 Jan 2016 15:57:08 -0300
Message-Id: 
References:  <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com>  <80218A07-9D37-42A3-B90A-56AEDBC3A86C@alkaline-solutions.com>   <56A260B6.4060302@aol.com> <478C8683-0E47-43E7-A7F3-75F89AB1DCDA@alkaline-solutions.com>
To: David Waite 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 18:57:16 -0000

--Apple-Mail=_15D6CBDD-FC80-453E-8E89-312FD8DD08A3
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_30901E26-6F86-4636-B197-941B4AD3067C"


--Apple-Mail=_30901E26-6F86-4636-B197-941B4AD3067C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Now that we have a cool name all we need is a logo for the attack and =
per haps an anime character, and we are done with all the hard work:)

John B.
> On Jan 22, 2016, at 2:54 PM, David Waite =
 wrote:
>=20
> It=E2=80=99s pronounced FronkenSTEEN-ian.
>=20
> -DW
>=20
>> On Jan 22, 2016, at 10:02 AM, George Fletcher > wrote:
>>=20
>> "Frankensteinian Amalgamation" -- David Waite
>>=20
>> I like it! :)
>>=20
>> On 1/22/16 8:11 AM, William Denniss wrote:
>>> +1 ;)
>>> On Fri, Jan 22, 2016 at 8:45 PM John Bradley < =
ve7jtb@ve7jtb.com > =
wrote:
>>> Perhaps Frankenstein response is a better name than cut and paste =
attack.
>>>=20
>>> John B. =20
>>>=20
>>> On Jan 22, 2016 1:22 AM, "David Waite" > wrote:
>>>> On Jan 21, 2016, at 2:50 PM, John Bradley < =
ve7jtb@ve7jtb.com > =
wrote:
>>>>=20
>>>> In that case you probably would put a hash of the state in the code =
to manage size.  The alg would be up to the AS, as long as it used the =
same hash both places it would work.
>>> Yes, true.=20
>>>>=20
>>>> Sending the state to the token endpoint is like having nonce and =
c_hash in the id_token, it binds the issued code to the browser =
instance.
>>> I think I understand what you are saying. Someone won=E2=80=99t be =
able to frankenstein up a state and a token from two different responses =
from an AS, and have a client successfully fetch an access token based =
on the amalgamation.
>>> =20
>>>> This protects against codes that leak via redirect uri pattern =
matching. failures etc.  It prevents an attacker from being able to =
replay a code from a different browser.
>>> Yes, if a party intercepts the redirect_url, or the AS fails to =
enforce one time use (which even for a compliant implementation could =
just mean the attacker was faster than the state propagated within the =
AS)
>>>=20
>>> Makes sense. Thanks John.
>>>=20
>>> -DW
>>>=20
>>>> If the client implements the other mitigations on the authorization =
endpoint, then it wouldn't be leaking the code via the token endpoint.=20=

>>>>=20
>>>> The two mitigations are for different attacks, however some of the =
attacks combined both vulnerabilities.
>>>>=20
>>>> Sending the iss and client_id is enough to stop the confused client =
attacks, but sending state on its own would not have stopped all of =
them.
>>>>=20
>>>> We discussed having them in separate drafts, and may still do that. =
  However for discussion having them in one document is I think better =
in the short run.
>>>>=20
>>>> John B.
>>>>=20
>>>>> On Jan 21, 2016, at 4:48 PM, David Waite =
> =
wrote:
>>>>>=20
>>>>> Question:=20
>>>>>=20
>>>>> I understand how =E2=80=9Ciss" helps mitigate this attack (client =
knows response was from the appropriate issuer and not an attack where =
the request was answered by another issuer).=20
>>>>>=20
>>>>> However, how does passing =E2=80=9Cstate=E2=80=9D on the =
authorization_code grant token request help once you have the above in =
place? Is this against some alternate flow of this attack I don=E2=80=99t =
see, or is it meant to mitigate some entirely separate attack?
>>>>>=20
>>>>> If one is attempting to work statelessly (e.g. your =E2=80=9Cstate=E2=
=80=9D parameter is actual state and not just a randomly generated =
value), a client would have always needed some way to differentiate =
which issuer the authorization_code grant token request would be sent =
to.
>>>>>=20
>>>>> However, if an AS was treating =E2=80=9Ccode=E2=80=9D as a token =
(for instance, encoding: client, user, consent time and approved =
scopes), the AS now has to include the client=E2=80=99s state as well. =
This would effectively double (likely more with encoding) the state sent =
in the authorization response back to the client redirect URL, adding =
more pressure against maximum URL sizes.
>>>>>=20
>>>>> -DW
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

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

>>=20
>> --=20
>> Chief Architect                  =20
>> Identity Services Engineering     Work: george.fletcher@teamaol.com =

>> AOL Inc.                          AIM:  gffletch
>> Mobile: +1-703-462-3494           Twitter: =
http://twitter.com/gffletch 
>> Office: +1-703-265-2544           Photos: =
http://georgefletcher.photography 
>=20


--Apple-Mail=_30901E26-6F86-4636-B197-941B4AD3067C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Now that we have a cool name all we need is a logo for the =
attack and per haps an anime character, and we are done with all the =
hard work:)

John =
B.
On Jan 22, 2016, at 2:54 PM, David Waite <david@alkaline-solutions.com> wrote:

It=E2=80=99s =
pronounced FronkenSTEEN-ian.

-DW

On Jan 22, 2016, at 10:02 AM, George Fletcher <gffletch@aol.com> =
wrote:


 =20
    
 =20
  

    "Frankensteinian Amalgamation"
      -- David Waite

      

      I like it! :)

    

    
On 1/22/16 8:11 AM, William Denniss
      wrote:

    

    
+1 ;)

      

        
On Fri, Jan 22, 2016 at 8:45 PM John =
Bradley <ve7jtb@ve7jtb.com>
          wrote:

        

        
Perhaps Frankenstein response is a better name
            than cut and paste attack. 
John =
B.   

          
On Jan 22, 2016 1:22 AM, "David
            Waite" <david@alkaline-solutions.com>
            wrote:

            

              

                

                  

                    
On Jan 21, 2016, at 2:50 PM, John =
Bradley <ve7jtb@ve7jtb.com>
                      wrote:

                    

                    

                      

                        
In that case you probably would =
put a hash
                          of the state in the code to manage size.  =
The
                          alg would be up to the AS, as long as it used
                          the same hash both places it would work.

                      

                    

                  

                  Yes, true. 

                  

                    

                      

                        


                        

                        
Sending the state to the token =
endpoint is
                          like having nonce and c_hash in the id_token,
                          it binds the issued code to the browser
                          instance.

                      

                    

                  

                  I think I understand what you are saying. Someone
                  won=E2=80=99t be able to frankenstein up a state and a =
token
                  from two different responses from an AS, and have a
                  client successfully fetch an access token based on the
                  amalgamation.

                
 

                

                  

                    

                      
This protects against codes that =
leak via
                        redirect uri pattern matching. failures =
etc.  It
                        prevents an attacker from being able to replay a
                        code from a different browser.

                    

                  

                  Yes, if a party intercepts the redirect_url, or the AS
                  fails to enforce one time use (which even for a
                  compliant implementation could just mean the attacker
                  was faster than the state propagated within the =
AS)

                


                

                
Makes sense. Thanks John.

                


                

                
-DW

                


                

                

                  

                    

                      
If the client implements the other
                        mitigations on the authorization endpoint, then
                        it wouldn't be leaking the code via the token
                        endpoint. 

                      


                      

                      
The two mitigations are for =
different
                        attacks, however some of the attacks combined
                        both vulnerabilities.

                      


                      

                      
Sending the iss and client_id is =
enough to
                        stop the confused client attacks, but sending
                        state on its own would not have stopped all of
                        them.

                      


                      

                      
We discussed having them in =
separate drafts,
                        and may still do that.   However for =
discussion
                        having them in one document is I think better in
                        the short run.

                      


                      

                      
John B.

                      


                      

                      

                        

                          

                            
On Jan 21, 2016, at 4:48 PM, =
David
                              Waite <david@alkaline-solutions.com>
                              wrote:

                            

                            

                              
Question: 
                                


                                

                                
I understand how =E2=80=9C=
iss" helps
                                  mitigate this attack (client knows
                                  response was from the appropriate
                                  issuer and not an attack where the
                                  request was answered by another
                                  issuer). 
                                  


                                  

                                  
However, how does =
passing =E2=80=9Cstate=E2=80=9D
                                    on the authorization_code grant
                                    token request help once you have the
                                    above in place? Is this against some
                                    alternate flow of this attack I
                                    don=E2=80=99t see, or is it meant to
                                    mitigate some entirely separate
                                    attack?

                                  


                                  

                                  
If one is attempting =
to work
                                    statelessly (e.g. your =E2=80=9Cstate=E2=
=80=9D
                                    parameter is actual state and not
                                    just a randomly generated value), a
                                    client would have always needed some
                                    way to differentiate which issuer
                                    the authorization_code grant token
                                    request would be sent to.

                                  


                                  

                                  
However, if an AS was =
treating
                                    =E2=80=9Ccode=E2=80=9D as a token =
(for instance,
                                    encoding: client, user, consent time
                                    and approved scopes), the AS now has
                                    to include the client=E2=80=99s =
state as
                                    well. This would effectively double
                                    (likely more with encoding) the
                                    state sent in the authorization
                                    response back to the client redirect
                                    URL, adding more pressure against
                                    maximum URL sizes.

                                  


                                  

                                  
-DW

                                

                              

                            

                          

                        

                      

                    

                  

                

              

            

          

          _______________________________________________

          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
Chief Architect                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photogra=
phy


  





=

--Apple-Mail=_30901E26-6F86-4636-B197-941B4AD3067C--

--Apple-Mail=_15D6CBDD-FC80-453E-8E89-312FD8DD08A3
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjIxODU3MDhaMCMGCSqGSIb3DQEJBDEWBBRsk9sePtVF3KLLHhHpEkLF
fA9cgzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBR7s37Vt4GtGeSgGDkBU5Vws33iaH0ORtOWHtiHb6mhOwTWx0WeMPh
XpztRp7Dtl27tDIpZD/2/H9yUa4EbXu5eVceZcNMwYWHeO9ngAqouaFx+EwOYWjKCcFbUOZhJrCI
02xBOXzcMdqgwTx+GxTI/4Yynt7D0k3OafSC64uph2lQUVT7+hmkrhAUb3jmzHE086OVq4W0HhLo
vlL7pvWQlfSLc3XzNhyJlrCfllaDdpP3WId54vJQGvjzBfkrzCNvk4cRvhfF3w1VPfBxJBpQkXrk
ChVzaVpjJ0bRrO3c6539moDAMGmAuWgnB+6jrvQfcvLafZ+H8gHuj53ePHZgAAAAAAAA
--Apple-Mail=_15D6CBDD-FC80-453E-8E89-312FD8DD08A3--


From nobody Fri Jan 22 11:00:21 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4011B2BFB for ; Fri, 22 Jan 2016 11:00:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P_DIZEKWwaph for ; Fri, 22 Jan 2016 11:00:17 -0800 (PST)
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 449531B2BFE for ; Fri, 22 Jan 2016 11:00:17 -0800 (PST)
Received: by mail-qk0-x22a.google.com with SMTP id o6so32420464qkc.2 for ; Fri, 22 Jan 2016 11:00:17 -0800 (PST)
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-type; bh=Cg/1+af7bPE+NR61I5gDjaupPKAvTncTNNush9n82pc=; b=qAdhVhc3dRwiFIZGs/9ZMlpBudT8Xp2lOD6U4WNm951D6jrmpnnWEZrhVDni2jC3X5 947fhR9O5P6YcDAImB79ZBAYotcEYeb+VPOozZ1rgd4wEktqgmZF+onrCc70lzRfBH2U 4hPDMNvJQ/Y4wyk9Pkm+Vrz+HSKDIed4O2usw1i46FXG7b+iLmFY9zjvFV3K8zc0UVFY D2N7nvp4BmQnPeuLiNv60Ng3MCxkwZSXxDncsNHOHiE6+lNxf/7bmN+CPhT2fi3CXvha RcuXE4uuL40VS6p2tgyiM4t9fYu/zCvhuTrhWzsyP1kgMAIno5w05TG/MLyqaSvcBiKj 02ug==
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-type; bh=Cg/1+af7bPE+NR61I5gDjaupPKAvTncTNNush9n82pc=; b=j0n1qvOeuUNf6GzZynKV71lvKGn5RXI1tNnRg1UYMCzZext2IZUdDuF0/0e43I5rfi s3RqJnsA0EXCt+W40Gq0AL9j9NAeVLor7IxOxONL8LZN+5sbSKIgUD9sxOfTkz9dlpgV Wri8ljAHiqrjtY4ShNVF1T75GETKRPOpq4RJJ49km+UWmKr3WaVBRcnEWJt3fXvlpjD7 ylT5YWTEWA+MwjkkJAfXNTFW0zBcbjPNAfJTtESkqd/1QVKf8zHQqrE8YcGki41loduE b1YB8zlQu+XcByZpKTJi1jMsSnPeczFq/w+4TDvGL6G0Aso88QLe4pq50J/lA7IORRck vKPQ==
X-Gm-Message-State: AG10YOQy7bdG/gV7RXf3Kt45qcuzyxvZiJhCGBFQIkktly0cZ76Jhx6+InUYbi0zvIbONg==
X-Received: by 10.55.73.85 with SMTP id w82mr5792066qka.52.1453489216334; Fri, 22 Jan 2016 11:00:16 -0800 (PST)
Received: from [192.168.1.65] (CPE84948c5cbf81-CM84948c5cbf80.cpe.net.cable.rogers.com. [99.224.83.138]) by smtp.googlemail.com with ESMTPSA id 136sm3292116qhx.49.2016.01.22.11.00.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jan 2016 11:00:15 -0800 (PST)
To: John Bradley , David Waite 
References:  <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com>  <80218A07-9D37-42A3-B90A-56AEDBC3A86C@alkaline-solutions.com>   <56A260B6.4060302@aol.com> <478C8683-0E47-43E7-A7F3-75F89AB1DCDA@alkaline-solutions.com> 
From: Paul Madsen 
Message-ID: <56A27C3E.2070301@gmail.com>
Date: Fri, 22 Jan 2016 14:00:14 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030507090708020407090103"
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 19:00:20 -0000

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

tshirt or it didnt happen

On 1/22/16 1:57 PM, John Bradley wrote:
> Now that we have a cool name all we need is a logo for the attack and 
> per haps an anime character, and we are done with all the hard work:)
>
> John B.
>> On Jan 22, 2016, at 2:54 PM, David Waite 
>> > 
>> wrote:
>>
>> It’s pronounced FronkenSTEEN-ian.
>>
>> -DW
>>
>>> On Jan 22, 2016, at 10:02 AM, George Fletcher >> > wrote:
>>>
>>> "Frankensteinian Amalgamation" -- David Waite
>>>
>>> I like it! :)
>>>
>>> On 1/22/16 8:11 AM, William Denniss wrote:
>>>> +1 ;)
>>>> On Fri, Jan 22, 2016 at 8:45 PM John Bradley  wrote:
>>>>
>>>>     Perhaps Frankenstein response is a better name than cut and
>>>>     paste attack.
>>>>
>>>>     John B.
>>>>
>>>>     On Jan 22, 2016 1:22 AM, "David Waite"
>>>>     >>>     > wrote:
>>>>
>>>>>         On Jan 21, 2016, at 2:50 PM, John Bradley
>>>>>          wrote:
>>>>>
>>>>>         In that case you probably would put a hash of the state in
>>>>>         the code to manage size.  The alg would be up to the AS,
>>>>>         as long as it used the same hash both places it would work.
>>>>         Yes, true.
>>>>>
>>>>>         Sending the state to the token endpoint is like having
>>>>>         nonce and c_hash in the id_token, it binds the issued code
>>>>>         to the browser instance.
>>>>         I think I understand what you are saying. Someone won’t be
>>>>         able to frankenstein up a state and a token from two
>>>>         different responses from an AS, and have a client
>>>>         successfully fetch an access token based on the amalgamation.
>>>>>         This protects against codes that leak via redirect uri
>>>>>         pattern matching. failures etc.  It prevents an attacker
>>>>>         from being able to replay a code from a different browser.
>>>>         Yes, if a party intercepts the redirect_url, or the AS
>>>>         fails to enforce one time use (which even for a compliant
>>>>         implementation could just mean the attacker was faster than
>>>>         the state propagated within the AS)
>>>>
>>>>         Makes sense. Thanks John.
>>>>
>>>>         -DW
>>>>
>>>>>         If the client implements the other mitigations on the
>>>>>         authorization endpoint, then it wouldn't be leaking the
>>>>>         code via the token endpoint.
>>>>>
>>>>>         The two mitigations are for different attacks, however
>>>>>         some of the attacks combined both vulnerabilities.
>>>>>
>>>>>         Sending the iss and client_id is enough to stop the
>>>>>         confused client attacks, but sending state on its own
>>>>>         would not have stopped all of them.
>>>>>
>>>>>         We discussed having them in separate drafts, and may still
>>>>>         do that.   However for discussion having them in one
>>>>>         document is I think better in the short run.
>>>>>
>>>>>         John B.
>>>>>
>>>>>>         On Jan 21, 2016, at 4:48 PM, David Waite
>>>>>>         >>>>>         > wrote:
>>>>>>
>>>>>>         Question:
>>>>>>
>>>>>>         I understand how “iss" helps mitigate this attack (client
>>>>>>         knows response was from the appropriate issuer and not an
>>>>>>         attack where the request was answered by another issuer).
>>>>>>
>>>>>>         However, how does passing “state” on the
>>>>>>         authorization_code grant token request help once you have
>>>>>>         the above in place? Is this against some alternate flow
>>>>>>         of this attack I don’t see, or is it meant to mitigate
>>>>>>         some entirely separate attack?
>>>>>>
>>>>>>         If one is attempting to work statelessly (e.g. your
>>>>>>         “state” parameter is actual state and not just a randomly
>>>>>>         generated value), a client would have always needed some
>>>>>>         way to differentiate which issuer the authorization_code
>>>>>>         grant token request would be sent to.
>>>>>>
>>>>>>         However, if an AS was treating “code” as a token (for
>>>>>>         instance, encoding: client, user, consent time and
>>>>>>         approved scopes), the AS now has to include the client’s
>>>>>>         state as well. This would effectively double (likely more
>>>>>>         with encoding) the state sent in the authorization
>>>>>>         response back to the client redirect URL, adding more
>>>>>>         pressure against maximum URL sizes.
>>>>>>
>>>>>>         -DW
>>>>
>>>>     _______________________________________________
>>>>     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
>>>
>>> -- 
>>> Chief Architect
>>> Identity Services Engineering     Work:george.fletcher@teamaol.com
>>> AOL Inc.                          AIM:  gffletch
>>> Mobile: +1-703-462-3494           Twitter:http://twitter.com/gffletch
>>> Office: +1-703-265-2544           Photos:http://georgefletcher.photography
>>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------030507090708020407090103
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    tshirt or it didnt happen

    

    
On 1/22/16 1:57 PM, John Bradley wrote:

    

    

      
      Now that we have a cool name all we need is a logo for the attack
      and per haps an anime character, and we are done with all the hard
      work:)
      


      

      
John B.

        

          

            
On Jan 22, 2016, at 2:54 PM, David Waite <david@alkaline-solutions.com>
              wrote:

            

            

              
              
It’s
                pronounced FronkenSTEEN-ian.
                

                  


                  

                  
-DW

                  


                    

                      

                        
On Jan 22, 2016, at 10:02 AM,
                          George Fletcher <gffletch@aol.com>
                          wrote:

                        

                        

                          
                          

                            "Frankensteinian Amalgamation"
                              -- David Waite

                              

                              I like it! :)

                            

                            
On 1/22/16 8:11
                              AM, William Denniss wrote:

                            

                            
+1 ;)

                              

                                
On Fri, Jan 22,
                                  2016 at 8:45 PM John Bradley <ve7jtb@ve7jtb.com>

                                  wrote:

                                

                                

                                  
Perhaps
                                    Frankenstein response is a better
                                    name than cut and paste attack. 

                                  
John B.   

                                  
On Jan 22,
                                    2016 1:22 AM, "David Waite" <david@alkaline-solutions.com>

                                    wrote:

                                    

                                      

                                        

                                          

                                            
On Jan 21,
                                              2016, at 2:50 PM, John
                                              Bradley <ve7jtb@ve7jtb.com> wrote:

                                            

                                            

                                              

                                                
In that
                                                  case you probably
                                                  would put a hash of
                                                  the state in the code
                                                  to manage size.  The
                                                  alg would be up to the
                                                  AS, as long as it used
                                                  the same hash both
                                                  places it would work.

                                              

                                            

                                          

                                          Yes, true. 

                                          

                                            

                                              

                                                


                                                

                                                
Sending
                                                  the state to the token
                                                  endpoint is like
                                                  having nonce and
                                                  c_hash in the
                                                  id_token, it binds the
                                                  issued code to the
                                                  browser instance.

                                              

                                            

                                          

                                          I think I understand what you
                                          are saying. Someone won’t be
                                          able to frankenstein up a
                                          state and a token from two
                                          different responses from an
                                          AS, and have a client
                                          successfully fetch an access
                                          token based on the
                                          amalgamation.

                                        
 

                                        

                                          

                                            

                                              
This
                                                protects against codes
                                                that leak via redirect
                                                uri pattern matching.
                                                failures etc.  It
                                                prevents an attacker
                                                from being able to
                                                replay a code from a
                                                different browser.

                                            

                                          

                                          Yes, if a party intercepts the
                                          redirect_url, or the AS fails
                                          to enforce one time use (which
                                          even for a compliant
                                          implementation could just mean
                                          the attacker was faster than
                                          the state propagated within
                                          the AS)

                                        


                                        

                                        
Makes sense.
                                          Thanks John.

                                        


                                        

                                        
-DW

                                        


                                        

                                        

                                          

                                            

                                              
If the
                                                client implements the
                                                other mitigations on the
                                                authorization endpoint,
                                                then it wouldn't be
                                                leaking the code via the
                                                token endpoint. 

                                              


                                              

                                              
The two
                                                mitigations are for
                                                different attacks,
                                                however some of the
                                                attacks combined both
                                                vulnerabilities.

                                              


                                              

                                              
Sending the
                                                iss and client_id is
                                                enough to stop the
                                                confused client attacks,
                                                but sending state on its
                                                own would not have
                                                stopped all of them.

                                              


                                              

                                              
We discussed
                                                having them in separate
                                                drafts, and may still do
                                                that.   However for
                                                discussion having them
                                                in one document is I
                                                think better in the
                                                short run.

                                              


                                              

                                              
John B.

                                              


                                              

                                              

                                                

                                                  

                                                    
On Jan
                                                      21, 2016, at 4:48
                                                      PM, David Waite
                                                      <david@alkaline-solutions.com>

                                                      wrote:

                                                    

                                                    

                                                      
Question: 

                                                        


                                                        

                                                        
I
                                                          understand how
                                                          “iss" helps
                                                          mitigate this
                                                          attack (client
                                                          knows response
                                                          was from the
                                                          appropriate
                                                          issuer and not
                                                          an attack
                                                          where the
                                                          request was
                                                          answered by
                                                          another
                                                          issuer). 
                                                          


                                                          

                                                          
However,
                                                          how does
                                                          passing
                                                          “state” on the
                                                          authorization_code
                                                          grant token
                                                          request help
                                                          once you have
                                                          the above in
                                                          place? Is this
                                                          against some
                                                          alternate flow
                                                          of this attack
                                                          I don’t see,
                                                          or is it meant
                                                          to mitigate
                                                          some entirely
                                                          separate
                                                          attack?

                                                          


                                                          

                                                          
If
                                                          one is
                                                          attempting to
                                                          work
                                                          statelessly
                                                          (e.g. your
                                                          “state”
                                                          parameter is
                                                          actual state
                                                          and not just a
                                                          randomly
                                                          generated
                                                          value), a
                                                          client would
                                                          have always
                                                          needed some
                                                          way to
                                                          differentiate
                                                          which issuer
                                                          the
                                                          authorization_code
                                                          grant token
                                                          request would
                                                          be sent to.

                                                          


                                                          

                                                          
However,
                                                          if an AS was
                                                          treating
                                                          “code” as a
                                                          token (for
                                                          instance,
                                                          encoding:
                                                          client, user,
                                                          consent time
                                                          and approved
                                                          scopes), the
                                                          AS now has to
                                                          include the
                                                          client’s state
                                                          as well. This
                                                          would
                                                          effectively
                                                          double (likely
                                                          more with
                                                          encoding) the
                                                          state sent in
                                                          the
                                                          authorization
                                                          response back
                                                          to the client
                                                          redirect URL,
                                                          adding more
                                                          pressure
                                                          against
                                                          maximum URL
                                                          sizes.

                                                          


                                                          

                                                          
-DW

                                                        

                                                      

                                                    

                                                  

                                                

                                              

                                            

                                          

                                        

                                      

                                    

                                  

_______________________________________________

                                  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


                            

                            

                            
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


                          

                        

                      

                    

                    

                  

                

              

            

          

        

        

      

      

      

      

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


    

    

  


--------------030507090708020407090103--


From nobody Fri Jan 22 11:05:54 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664421B2C50 for ; Fri, 22 Jan 2016 11:05:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1tvmKFsYHRw for ; Fri, 22 Jan 2016 11:05:49 -0800 (PST)
Received: from omr-m001e.mx.aol.com (omr-m001e.mx.aol.com [204.29.186.1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBF4A1B2C47 for ; Fri, 22 Jan 2016 11:05:48 -0800 (PST)
Received: from mtaout-mbd01.mx.aol.com (mtaout-mbd01.mx.aol.com [172.26.252.13]) by omr-m001e.mx.aol.com (Outbound Mail Relay) with ESMTP id 0DBFA380008F; Fri, 22 Jan 2016 14:05:48 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mbd01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 4E7C538000098; Fri, 22 Jan 2016 14:05:47 -0500 (EST)
To: Paul Madsen , John Bradley , David Waite 
References:  <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com>  <80218A07-9D37-42A3-B90A-56AEDBC3A86C@alkaline-solutions.com>   <56A260B6.4060302@aol.com> <478C8683-0E47-43E7-A7F3-75F89AB1DCDA@alkaline-solutions.com>  <56A27C3E.2070301@gmail.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56A27D8A.3040804@aol.com>
Date: Fri, 22 Jan 2016 14:05:46 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56A27C3E.2070301@gmail.com>
Content-Type: multipart/alternative; boundary="------------010007060602050505060904"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453489547; bh=ZCM/t7g0BBDOXo4l81jScMH/qlakBuDlhcUrbgdGcuI=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=sGwgCG5D6EboO+FwUjEHhsqHkgsPkBB2u4HfkvCNoanK1511IPAG1fDG15zlO9PfV 2h7/H+gWfu0uJhXlqvCSguE+EnFJgIjzIPfUMIZIADhxiFIoEg55abn7kph1MyIus8 gL5HXAXVaUwe0tqoYdm1pBST56I6JgeEU7O8rcc4=
x-aol-sid: 3039ac1afc0d56a27d8b1956
X-AOL-IP: 10.172.102.124
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 19:05:52 -0000

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

Isn't that your department Paul? I have high expectations!

On 1/22/16 2:00 PM, Paul Madsen wrote:
> tshirt or it didnt happen
>
> On 1/22/16 1:57 PM, John Bradley wrote:
>> Now that we have a cool name all we need is a logo for the attack and 
>> per haps an anime character, and we are done with all the hard work:)
>>
>> John B.
>>> On Jan 22, 2016, at 2:54 PM, David Waite 
>>>  wrote:
>>>
>>> It’s pronounced FronkenSTEEN-ian.
>>>
>>> -DW
>>>
>>>> On Jan 22, 2016, at 10:02 AM, George Fletcher >>> > wrote:
>>>>
>>>> "Frankensteinian Amalgamation" -- David Waite
>>>>
>>>> I like it! :)
>>>>
>>>> On 1/22/16 8:11 AM, William Denniss wrote:
>>>>> +1 ;)
>>>>> On Fri, Jan 22, 2016 at 8:45 PM John Bradley  
>>>>> wrote:
>>>>>
>>>>>     Perhaps Frankenstein response is a better name than cut and
>>>>>     paste attack.
>>>>>
>>>>>     John B.
>>>>>
>>>>>     On Jan 22, 2016 1:22 AM, "David Waite"
>>>>>      wrote:
>>>>>
>>>>>>         On Jan 21, 2016, at 2:50 PM, John Bradley
>>>>>>          wrote:
>>>>>>
>>>>>>         In that case you probably would put a hash of the state
>>>>>>         in the code to manage size.  The alg would be up to the
>>>>>>         AS, as long as it used the same hash both places it would
>>>>>>         work.
>>>>>         Yes, true.
>>>>>>
>>>>>>         Sending the state to the token endpoint is like having
>>>>>>         nonce and c_hash in the id_token, it binds the issued
>>>>>>         code to the browser instance.
>>>>>         I think I understand what you are saying. Someone won’t be
>>>>>         able to frankenstein up a state and a token from two
>>>>>         different responses from an AS, and have a client
>>>>>         successfully fetch an access token based on the amalgamation.
>>>>>>         This protects against codes that leak via redirect uri
>>>>>>         pattern matching. failures etc.  It prevents an attacker
>>>>>>         from being able to replay a code from a different browser.
>>>>>         Yes, if a party intercepts the redirect_url, or the AS
>>>>>         fails to enforce one time use (which even for a compliant
>>>>>         implementation could just mean the attacker was faster
>>>>>         than the state propagated within the AS)
>>>>>
>>>>>         Makes sense. Thanks John.
>>>>>
>>>>>         -DW
>>>>>
>>>>>>         If the client implements the other mitigations on the
>>>>>>         authorization endpoint, then it wouldn't be leaking the
>>>>>>         code via the token endpoint.
>>>>>>
>>>>>>         The two mitigations are for different attacks, however
>>>>>>         some of the attacks combined both vulnerabilities.
>>>>>>
>>>>>>         Sending the iss and client_id is enough to stop the
>>>>>>         confused client attacks, but sending state on its own
>>>>>>         would not have stopped all of them.
>>>>>>
>>>>>>         We discussed having them in separate drafts, and may
>>>>>>         still do that.   However for discussion having them in
>>>>>>         one document is I think better in the short run.
>>>>>>
>>>>>>         John B.
>>>>>>
>>>>>>>         On Jan 21, 2016, at 4:48 PM, David Waite
>>>>>>>          wrote:
>>>>>>>
>>>>>>>         Question:
>>>>>>>
>>>>>>>         I understand how “iss" helps mitigate this attack
>>>>>>>         (client knows response was from the appropriate issuer
>>>>>>>         and not an attack where the request was answered by
>>>>>>>         another issuer).
>>>>>>>
>>>>>>>         However, how does passing “state†on the
>>>>>>>         authorization_code grant token request help once you
>>>>>>>         have the above in place? Is this against some alternate
>>>>>>>         flow of this attack I don’t see, or is it meant to
>>>>>>>         mitigate some entirely separate attack?
>>>>>>>
>>>>>>>         If one is attempting to work statelessly (e.g. your
>>>>>>>         “state†parameter is actual state and not just a
>>>>>>>         randomly generated value), a client would have always
>>>>>>>         needed some way to differentiate which issuer the
>>>>>>>         authorization_code grant token request would be sent to.
>>>>>>>
>>>>>>>         However, if an AS was treating “code†as a token (for
>>>>>>>         instance, encoding: client, user, consent time and
>>>>>>>         approved scopes), the AS now has to include the client’s
>>>>>>>         state as well. This would effectively double (likely
>>>>>>>         more with encoding) the state sent in the authorization
>>>>>>>         response back to the client redirect URL, adding more
>>>>>>>         pressure against maximum URL sizes.
>>>>>>>
>>>>>>>         -DW
>>>>>
>>>>>     _______________________________________________
>>>>>     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
>>>>
>>>> -- 
>>>> Chief Architect
>>>> Identity Services Engineering     Work:george.fletcher@teamaol.com
>>>> AOL Inc.                          AIM:  gffletch
>>>> Mobile: +1-703-462-3494           Twitter:http://twitter.com/gffletch
>>>> Office: +1-703-265-2544           Photos:http://georgefletcher.photography
>>>
>>
>>
>>
>> _______________________________________________
>> 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

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


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


  
    
  
  
    Isn't that your department
      Paul? I have high expectations!

    

    
On 1/22/16 2:00 PM, Paul Madsen wrote:

    

    

      
      tshirt or it didnt happen

      

      
On 1/22/16 1:57 PM, John Bradley
        wrote:

      

      

        
        Now that we have a cool name all we need is a logo for the
        attack and per haps an anime character, and we are done with all
        the hard work:)
        


        

        
John B.

          

            

              
On Jan 22, 2016, at 2:54 PM, David Waite
                <david@alkaline-solutions.com>

                wrote:

              

              

                
                
It’s pronounced FronkenSTEEN-ian.
                  

                    


                    

                    
-DW

                    


                      

                        

                          
On Jan 22, 2016, at 10:02 AM,
                            George Fletcher <gffletch@aol.com>

                            wrote:

                          

                          

                            
                            
 "Frankensteinian
                                Amalgamation" -- David Waite

                                

                                I like it! :)

                              

                              
On 1/22/16
                                8:11 AM, William Denniss wrote:

                              

                              
+1 ;)

                                

                                  
On Fri, Jan
                                    22, 2016 at 8:45 PM John Bradley
                                    <ve7jtb@ve7jtb.com>


                                    wrote:

                                  

                                  

                                    
Perhaps
                                      Frankenstein response is a better
                                      name than cut and paste attack. 

                                    
John B.   

                                    
On Jan 22,
                                      2016 1:22 AM, "David Waite" <david@alkaline-solutions.com>


                                      wrote:

                                      

                                        

                                          

                                            

                                              
On Jan 21,
                                                2016, at 2:50 PM, John
                                                Bradley <ve7jtb@ve7jtb.com>
                                                wrote:

                                              

                                              

                                                

                                                  
In that
                                                    case you probably
                                                    would put a hash of
                                                    the state in the
                                                    code to manage
                                                    size.  The alg would
                                                    be up to the AS, as
                                                    long as it used the
                                                    same hash both
                                                    places it would
                                                    work.

                                                

                                              

                                            

                                            Yes, true. 

                                            

                                              

                                                

                                                  


                                                  

                                                  
Sending
                                                    the state to the
                                                    token endpoint is
                                                    like having nonce
                                                    and c_hash in the
                                                    id_token, it binds
                                                    the issued code to
                                                    the browser
                                                    instance.

                                                

                                              

                                            

                                            I think I understand what
                                            you are saying. Someone
                                            won’t be able to
                                            frankenstein up a state and
                                            a token from two different
                                            responses from an AS, and
                                            have a client successfully
                                            fetch an access token based
                                            on the amalgamation.

                                          
 

                                          

                                            

                                              

                                                
This
                                                  protects against codes
                                                  that leak via redirect
                                                  uri pattern matching.
                                                  failures etc.  It
                                                  prevents an attacker
                                                  from being able to
                                                  replay a code from a
                                                  different browser.

                                              

                                            

                                            Yes, if a party intercepts
                                            the redirect_url, or the AS
                                            fails to enforce one time
                                            use (which even for a
                                            compliant implementation
                                            could just mean the attacker
                                            was faster than the state
                                            propagated within the AS)

                                          


                                          

                                          
Makes sense.
                                            Thanks John.

                                          


                                          

                                          
-DW

                                          


                                          

                                          

                                            

                                              

                                                
If the
                                                  client implements the
                                                  other mitigations on
                                                  the authorization
                                                  endpoint, then it
                                                  wouldn't be leaking
                                                  the code via the token
                                                  endpoint. 

                                                


                                                

                                                
The two
                                                  mitigations are for
                                                  different attacks,
                                                  however some of the
                                                  attacks combined both
                                                  vulnerabilities.

                                                


                                                

                                                
Sending
                                                  the iss and client_id
                                                  is enough to stop the
                                                  confused client
                                                  attacks, but sending
                                                  state on its own would
                                                  not have stopped all
                                                  of them.

                                                


                                                

                                                
We
                                                  discussed having them
                                                  in separate drafts,
                                                  and may still do that.
                                                    However for
                                                  discussion having them
                                                  in one document is I
                                                  think better in the
                                                  short run.

                                                


                                                

                                                
John B.

                                                


                                                

                                                

                                                  

                                                    

                                                      
On
                                                        Jan 21, 2016, at
                                                        4:48 PM, David
                                                        Waite <david@alkaline-solutions.com>


                                                        wrote:

                                                      

                                                      

                                                        
Question: 


                                                          


                                                          

                                                          
I
                                                          understand how
                                                          “iss" helps
                                                          mitigate this
                                                          attack (client
                                                          knows response
                                                          was from the
                                                          appropriate
                                                          issuer and not
                                                          an attack
                                                          where the
                                                          request was
                                                          answered by
                                                          another
                                                          issuer). 
                                                          


                                                          

                                                          
However,

                                                          how does
                                                          passing
                                                          “state†on the
                                                          authorization_code

                                                          grant token
                                                          request help
                                                          once you have
                                                          the above in
                                                          place? Is this
                                                          against some
                                                          alternate flow
                                                          of this attack
                                                          I don’t see,
                                                          or is it meant
                                                          to mitigate
                                                          some entirely
                                                          separate
                                                          attack?

                                                          


                                                          

                                                          
If

                                                          one is
                                                          attempting to
                                                          work
                                                          statelessly
                                                          (e.g. your
                                                          “stateâ€
                                                          parameter is
                                                          actual state
                                                          and not just a
                                                          randomly
                                                          generated
                                                          value), a
                                                          client would
                                                          have always
                                                          needed some
                                                          way to
                                                          differentiate
                                                          which issuer
                                                          the
                                                          authorization_code
                                                          grant token
                                                          request would
                                                          be sent to.

                                                          


                                                          

                                                          
However,

                                                          if an AS was
                                                          treating
                                                          “code†as a
                                                          token (for
                                                          instance,
                                                          encoding:
                                                          client, user,
                                                          consent time
                                                          and approved
                                                          scopes), the
                                                          AS now has to
                                                          include the
                                                          client’s state
                                                          as well. This
                                                          would
                                                          effectively
                                                          double (likely
                                                          more with
                                                          encoding) the
                                                          state sent in
                                                          the
                                                          authorization
                                                          response back
                                                          to the client
                                                          redirect URL,
                                                          adding more
                                                          pressure
                                                          against
                                                          maximum URL
                                                          sizes.

                                                          


                                                          

                                                          
-DW

                                                          

                                                        

                                                      

                                                    

                                                  

                                                

                                              

                                            

                                          

                                        

                                      

                                    

_______________________________________________

                                    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


                              

                              

                              
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


                            

                          

                        

                      

                      

                    

                  

                

              

            

          

          

        

        

        

        

        
_______________________________________________
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


    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------010007060602050505060904--


From nobody Fri Jan 22 12:02:25 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 083341B2D00; Fri, 22 Jan 2016 12:02:24 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160122200224.16618.88091.idtracker@ietfa.amsl.com>
Date: Fri, 22 Jan 2016 12:02:24 -0800
Archived-At: 
Cc: oauth@ietf.org, The IESG , oauth-chairs@ietf.org
Subject: [OAUTH-WG] WG Action: Rechartered Web Authorization Protocol (oauth)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 20:02:24 -0000

The Web Authorization Protocol (oauth) WG in the Security Area of the
IETF has been rechartered. For additional information, please contact the
Area Directors or the WG Chairs.

Web Authorization Protocol (oauth)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Hannes Tschofenig 
  Derek Atkins 

Assigned Area Director:
  Kathleen Moriarty 

Mailing list:
  Address: oauth@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/oauth
  Archive: https://mailarchive.ietf.org/arch/browse/oauth/

Charter: https://datatracker.ietf.org/doc/charter-ietf-oauth/

The Web Authorization (OAuth) protocol allows a user to grant a
third-party web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite already includes

* a procedure for enabling a client to register with an authorization
  server,
* a protocol for obtaining authorization tokens from an authorization
  server with the resource owner's consent, and
* protocols for presenting these authorization tokens to protected
  resources for access to a resource.

This protocol suite has been enhanced with functionality for
interworking with legacy identity infrastructure (such as SAML), token
revocation, token exchange, dynamic client registration, token
introspection, a standardized token format with the JSON Web Token, and
specifications that mitigate security attacks, such as Proof Key for
Code Exchange.

The ongoing standardization efforts within the OAuth working group
focus on increasing interoperability of OAuth deployments and to
improve security. More specifically, the working group is defining proof
of possession tokens, developing a discovery mechanism, providing
guidance for the use of OAuth with native apps, re-introducing
the device flow used by devices with limited user interfaces, additional
security enhancements for clients communicating with multiple service
providers, definition of claims used with JSON Web Tokens, techniques to
mitigate open redirector attacks, as well as guidance on encoding state
information.

For feedback and discussion about our specifications please
subscribe to our public mailing list at .

For security related bug reports that relate to our specifications
please contact . If the reported
bug report turns out to be implementation-specific we will attempt
to forward it to the appropriate developers.

Milestones:
  Feb 2016 - Submit 'Request by JWS ver.1.0 for OAuth 2.0' to the IESG
for consideration as a Proposed Standard
  Apr 2016 - Submit 'Proof-of-Possession OAuth Security' document bundle
for consideration as a Proposed Standard
  Jul 2016 - Submit 'OAuth 2.0 Token Exchange' to the IESG for
consideration as a Proposed Standard



From nobody Fri Jan 22 12:23:45 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C181A8709 for ; Fri, 22 Jan 2016 12:23:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-BT9mYK-x_v for ; Fri, 22 Jan 2016 12:23:39 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::700]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90821A86FF for ; Fri, 22 Jan 2016 12:23:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TRorbpyTt4KZCq92J6lq4wsQSfIVSToRn6Xmqzy82G0=; b=Q0GC923oSYiZtkroiabvMG/SzbH6+Ig5XIt/GOcK5A9MG3szAR1nhCVTrVtxzzqXlSonc36oOHnp2stbb9Gc9H1q7LsKrxn6dS3U/fdjvQm9kq7XmF7exhoyAJQzgF0tWfAClC3GrFau6+b6KzUDpinU8rzOSQwilJm4jAe7g7o=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 22 Jan 2016 20:23:20 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Fri, 22 Jan 2016 20:23:20 +0000
From: Mike Jones 
To: "" 
Thread-Topic: [OAUTH-WG] WG Action: Rechartered Web Authorization Protocol (oauth)
Thread-Index: AQHRVU/Up16E8qHUxUO0INjGf/MmGp8H+tjN
Date: Fri, 22 Jan 2016 20:23:20 +0000
Message-ID: 
References: <20160122200224.16618.88091.idtracker@ietfa.amsl.com>
In-Reply-To: <20160122200224.16618.88091.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [166.176.185.74]
x-ms-office365-filtering-correlation-id: 4b542ede-2fc5-4f93-db09-08d32369dec9
x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:3bk57RnFvf6koVEzJSyQ8CDRFIp69fcqRB/vo3v1/DJ7UEYsZG7UW9NFDBeTt8YVgckwLpHgLQVEMuNGl3XNZ7KawnOnLS9qys5NUDuT6EOMnmauTSyqgHmKz/VtuKT22LxeM98VMi4Hi4FdovnjfQ==; 24:sbrMrjSIeHncXx6GiXrdYhUp4nUSKuj6Z4DUEzz9944/CInsbvuqrJ1G8a6hWVQLUDoHU8kTfTDVDMZomqCeMjTDLmwmZaWhBUMNYKhcjhs=
x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; UriScan:; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; 
x-forefront-prvs: 08296C9B35
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(45074003)(377454003)(199003)(19580395003)(74316001)(450100001)(87936001)(106356001)(106116001)(66066001)(105586002)(8990500004)(5004730100002)(19580405001)(107886002)(92566002)(5001960100002)(54356999)(5008740100001)(10090500001)(19617315012)(15975445007)(11100500001)(110136002)(77096005)(2906002)(1096002)(76576001)(586003)(10400500002)(81156007)(50986999)(19625215002)(2900100001)(97736004)(16236675004)(76176999)(5002640100001)(5005710100001)(99286002)(33656002)(1220700001)(102836003)(2950100001)(10290500002)(6116002)(3846002)(40100003)(86612001)(1600100001)(5003600100002)(189998001)(101416001)(122556002)(86362001)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442F3A62AFAE7004A4CD1F0F5C40BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2016 20:23:20.3180 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444
Archived-At: 
Subject: Re: [OAUTH-WG] WG Action: Rechartered Web Authorization Protocol (oauth)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 20:23:43 -0000

--_000_BY2PR03MB442F3A62AFAE7004A4CD1F0F5C40BY2PR03MB442namprd_
Content-Type: text/plain; charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

+1
________________________________
From: The IESG
Sent: =FD1/=FD22/=FD2016 12:02 PM
To: IETF-Announce
Cc: oauth@ietf.org; The IESG; =
oauth-chairs@ietf.org
Subject: [OAUTH-WG] WG Action: Rechartered Web Authorization Protocol (oaut=
h)

The Web Authorization Protocol (oauth) WG in the Security Area of the
IETF has been rechartered. For additional information, please contact the
Area Directors or the WG Chairs.

Web Authorization Protocol (oauth)
-----------------------------------------------------------------------
Current status: Active WG

Chairs:
  Hannes Tschofenig 
  Derek Atkins 

Assigned Area Director:
  Kathleen Moriarty 

Mailing list:
  Address: oauth@ietf.org
  To subscribe: https://www.ietf.org/mailman/listinfo/oauth
  Archive: https://mailarchive.ietf.org/arch/browse/oauth/

Charter: https://datatracker.ietf.org/doc/charter-ietf-oauth/

The Web Authorization (OAuth) protocol allows a user to grant a
third-party web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that
supports OAuth could allow its users to use a third-party printing web
site to print their private pictures, without allowing the printing
site to gain full control of the user's account and without having the
user share his or her photo-sharing sites' long-term credential with
the printing site.

The OAuth 2.0 protocol suite already includes

* a procedure for enabling a client to register with an authorization
  server,
* a protocol for obtaining authorization tokens from an authorization
  server with the resource owner's consent, and
* protocols for presenting these authorization tokens to protected
  resources for access to a resource.

This protocol suite has been enhanced with functionality for
interworking with legacy identity infrastructure (such as SAML), token
revocation, token exchange, dynamic client registration, token
introspection, a standardized token format with the JSON Web Token, and
specifications that mitigate security attacks, such as Proof Key for
Code Exchange.

The ongoing standardization efforts within the OAuth working group
focus on increasing interoperability of OAuth deployments and to
improve security. More specifically, the working group is defining proof
of possession tokens, developing a discovery mechanism, providing
guidance for the use of OAuth with native apps, re-introducing
the device flow used by devices with limited user interfaces, additional
security enhancements for clients communicating with multiple service
providers, definition of claims used with JSON Web Tokens, techniques to
mitigate open redirector attacks, as well as guidance on encoding state
information.

For feedback and discussion about our specifications please
subscribe to our public mailing list at .

For security related bug reports that relate to our specifications
please contact . If the reported
bug report turns out to be implementation-specific we will attempt
to forward it to the appropriate developers.

Milestones:
  Feb 2016 - Submit 'Request by JWS ver.1.0 for OAuth 2.0' to the IESG
for consideration as a Proposed Standard
  Apr 2016 - Submit 'Proof-of-Possession OAuth Security' document bundle
for consideration as a Proposed Standard
  Jul 2016 - Submit 'OAuth 2.0 Token Exchange' to the IESG for
consideration as a Proposed Standard


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

--_000_BY2PR03MB442F3A62AFAE7004A4CD1F0F5C40BY2PR03MB442namprd_
Content-Type: text/html; charset="windows-1256"
Content-Transfer-Encoding: quoted-printable













+1







From:
The IESG

Sent:
=FD1/=
=FD22/=FD2016 12:02 PM

To:
IETF-Announce

Cc:
oauth@ietf.org;
The IESG; 
oauth-chairs@ietf.org

Subject:
[OAUT=
H-WG] WG Action: Rechartered Web Authorization Protocol (oauth)









The Web Authorization Protocol (oauth) WG in the S=
ecurity Area of the

IETF has been rechartered. For additional information, please contact the
Area Directors or the WG Chairs.



Web Authorization Protocol (oauth)

-----------------------------------------------------------------------

Current status: Active WG



Chairs:

  Hannes Tschofenig <Hannes.Tschofenig@gmx.net>

  Derek Atkins <derek@ihtfp.com>



Assigned Area Director:

  Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>



Mailing list:

  Address: oauth@ietf.org

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

  Archive: https://mailarchive.ietf.org/arch/browse/oauth/



Charter: h=
ttps://datatracker.ietf.org/doc/charter-ietf-oauth/



The Web Authorization (OAuth) protocol allows a user to grant a

third-party web site or application access to the user's protected

resources, without necessarily revealing their long-term credentials,

or even their identity. For example, a photo-sharing site that

supports OAuth could allow its users to use a third-party printing web

site to print their private pictures, without allowing the printing

site to gain full control of the user's account and without having the

user share his or her photo-sharing sites' long-term credential with

the printing site.



The OAuth 2.0 protocol suite already includes



* a procedure for enabling a client to register with an authorization

  server,

* a protocol for obtaining authorization tokens from an authorization

  server with the resource owner's consent, and

* protocols for presenting these authorization tokens to protected

  resources for access to a resource.



This protocol suite has been enhanced with functionality for

interworking with legacy identity infrastructure (such as SAML), token

revocation, token exchange, dynamic client registration, token

introspection, a standardized token format with the JSON Web Token, and

specifications that mitigate security attacks, such as Proof Key for

Code Exchange.



The ongoing standardization efforts within the OAuth working group

focus on increasing interoperability of OAuth deployments and to

improve security. More specifically, the working group is defining proof
of possession tokens, developing a discovery mechanism, providing

guidance for the use of OAuth with native apps, re-introducing

the device flow used by devices with limited user interfaces, additional
security enhancements for clients communicating with multiple service

providers, definition of claims used with JSON Web Tokens, techniques to
mitigate open redirector attacks, as well as guidance on encoding state

information.



For feedback and discussion about our specifications please

subscribe to our public mailing list at <oauth AT ietf.org>.



For security related bug reports that relate to our specifications

please contact <oauth-security-reports AT ietf.org>. If the reported<=
br>
bug report turns out to be implementation-specific we will attempt

to forward it to the appropriate developers.



Milestones:

  Feb 2016 - Submit 'Request by JWS ver.1.0 for OAuth 2.0' to the IESG=


for consideration as a Proposed Standard

  Apr 2016 - Submit 'Proof-of-Possession OAuth Security' document bund=
le

for consideration as a Proposed Standard

  Jul 2016 - Submit 'OAuth 2.0 Token Exchange' to the IESG for

consideration as a Proposed Standard





_______________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth







--_000_BY2PR03MB442F3A62AFAE7004A4CD1F0F5C40BY2PR03MB442namprd_--


From nobody Fri Jan 22 15:26:47 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08781A92E1 for ; Fri, 22 Jan 2016 15:26:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KT5RJiUr8ZP6 for ; Fri, 22 Jan 2016 15:26:40 -0800 (PST)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::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 45C811A92AB for ; Fri, 22 Jan 2016 15:26:40 -0800 (PST)
Received: by mail-ig0-x233.google.com with SMTP id h5so1723237igh.0 for ; Fri, 22 Jan 2016 15:26:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9q6MkJMde0srx1jJyMT/CSyxfWMVh46jP41yWBM/eMo=; b=ARMNlzUDEiiUMcJpbQ1fM8AJjUyNOf03vA23/doudIFMwqpWfnFZqZR4lkLaCIiKCT ObgFJ6qFEKXMqp5gV+zXhdRO/TYcEEsHVZYiSZ9M38vVFEQ833YcYwJ1tMAtqTDjh/51 TGLgnSYc6Mg8lASfDcR91zg0nVSgnujy/qBus=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=9q6MkJMde0srx1jJyMT/CSyxfWMVh46jP41yWBM/eMo=; b=UHFnr90iEcdzQZzFSyYgz9AT7hKer9HHykKQCYKz8lOcQuPh56tzj8fy0m6uw2iC/y mbjrI5apVijtJk1sJVJXX39uGkKXexhv/5EsWK0adOrwynrRvlroCmaS3lOL0xCBUEzf 7zi8TsQOQat0wmmrNSkjCTO44DQKwTCfStVwNCDMsebC1/A5PpxlSANQdVQIubnFanLt aiCChRSlTJI7apJtYDsORVKt2UyLQ7jbkVO62etFWL4U55oN7S6eTAZxd53AY8EGLUck wikP/3dt0Kz8x54aX+H2cJ00k7ItW7F4RpXMSMjrBghJAzkJVzVuWZ/2jSs5Xs1LMG8J 9haQ==
X-Gm-Message-State: AG10YOQS5MN1joGLKXjCRaszZFPwWGteZ6CxcvLlK7mKu9raVqy3Md+HANeAk9h130k9oztyBQPH/Tb0lxLES/a9
X-Received: by 10.50.18.112 with SMTP id v16mr5906052igd.57.1453505199502; Fri, 22 Jan 2016 15:26:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.212.69 with HTTP; Fri, 22 Jan 2016 15:26:09 -0800 (PST)
In-Reply-To: 
References: <569E2076.2090405@gmx.net>   <569F915D.8020806@mit.edu>        
From: Brian Campbell 
Date: Fri, 22 Jan 2016 16:26:09 -0700
Message-ID: 
To: Nat Sakimura 
Content-Type: multipart/alternative; boundary=089e0149bd9218a0320529f48dd9
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 23:26:46 -0000

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

I agree that the language describing OAuth issuer could and should be
improved. The text now reads like it is the exact and full URL where the
metadata/discovery document is located. Perhaps something more like "the
URL from which the authorization server's configuration information
location can be derived" and explain that adding the .well-known bits to
the issuer is where the configuration information can actually be found.



On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura  wrote:

> Re: iss. I discussed this a bit with Nov in more details. It probably is =
a
> sloppy language of the specs that is making it difficult to read what you
> wanted to achieve.
>
> In mix-up-mitigation draft, OAuth issuer is "the URL of the authorization
> server's configuration information location". In OAuth discovery draft,
> there is something called "OAuth 2.0 Configuration Information Location
> URL", which is equal to "OpenID Connect Issuer".
>
> When I wrote the statement, I thought you were pointing to the URL that
> you can actually pull the configuration information by "the URL of the
> authorizaiton server's configuration information location" since otherwis=
e
> you would have used the term "OAuth 2.0 Configuration Information Locatio=
n
> URL". But after all, you probably meant these two are the same. Then I
> would strongly recommend to fix the language.
>
> Now, even If that is the case, the relationship like
>
>    - iss + .well-know/openid-configuration =3D Connect OP config endoint
>    - OAuth config endpoint - .well-known/openid-configuration =3D OAuth i=
ss
>
> is very confusing.
>
> You also claim that your approach is simpler, but to me, your approach
> seem to be overly complex. It requires discovery and the check for the
> value of the discovered config information to work as the mitigation.
> (Right. Draft -01 does not have it, so it does not solve the mix-up issue=
.)
> With oauth-meta, you do not need it.
>
> Finally, your point that HATEOAS reminds you of WSDL, it is not. If you
> want to have something similar to WSDL in REST API area, it is Swagger.
> (Actually, it is gaining a lot of momentum recently, but that's beside th=
e
> fact ;-). And the point here is not the format but the fact that we need =
to
> have a way to associate metadata to the data. The root cause of this mix-=
up
> attack is that the metadata and data is not associated properly. We have =
a
> standard way of associating the data and metadata with link-rel such as
> RFC5988 so why not use it? Link-rel-href pattern is used a lot now. Most
> modern web pages actually have it. Using a proper way to associate metada=
ta
> with data will save you from a lot of other attacks in the future. Instea=
d
> of doing patch works, we should solve it architecturally.
>
> Nat
>
>
>
> 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 10:34 Mike Jones :
>
>> Nat, I=E2=80=99m confused by this statement in the message you reference=
 =E2=80=9CUnfortunately,
>> this does not match the value of OAuth issuer defined in Section 2
>> of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as
>> specified in 3.1. As such, validation as specified in bullet 1 of Sectio=
n 4
>> fails in Google's case -- OR it means that the document is internally
>> inconsistent.=E2=80=9D.  The issuer definition in draft-jones-oauth-disc=
overy is
>> 100% compatible with the one in OpenID Connect Discovery, by design.  In
>> the Google example, both the OpenID issuer and the OAuth issuer values
>> would be the string =E2=80=9Chttps://accounts.google.com=E2=80=9D.  What=
 is the
>> inconsistency that you perceive?
>>
>>
>>
>> The discussion of the duplication problem happened in the private
>> meetings in Yokohama.
>>
>>
>>
>> I will admit, in Yokohama, I didn=E2=80=99t speak up in the public meeti=
ngs to
>> point out that a simpler alternative to oauth-meta was already being
>> discussed there in private, because then I would have had to talk about =
the
>> security issues, which we=E2=80=99d decided not to publicly do at that p=
oint.  So I
>> stayed silent during the poll, out of politeness.  Perhaps I should have
>> found a way to say something then anyway, but that=E2=80=99s water under=
 the bridge
>> now.
>>
>>
>>
>> Finally, for what it=E2=80=99s worth, the HATEOAS stuff reminds me far t=
oo much
>> of Web Services Description Language (WSDL) =E2=80=93 part of the comple=
xity
>> baggage that helped sink Web Services.  The use of =E2=80=9Clink rel=E2=
=80=9D to define an
>> interaction vocabulary and publish endpoints for that vocabulary seems
>> pretty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=
=93 another cute =E2=80=9CWebby=E2=80=9D
>> innovation that never caught on.  The industry has pretty much voted wit=
h
>> its feet and is using JSON for publishing discovery data structures =E2=
=80=93 not
>> =E2=80=9Clink rel=E2=80=9D.  I am against us reverting to the =E2=80=9Cl=
ink rel=E2=80=9D proposal from 2008
>> that never caught on when JSON is simpler and does a better job.
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> *From:* Nat Sakimura [mailto:sakimura@gmail.com]
>> *Sent:* Thursday, January 21, 2016 6:24 AM
>> *To:* Justin Richer ; Mike Jones <
>> Michael.Jones@microsoft.com>
>> *Cc:* William Denniss ;  <
>> oauth@ietf.org>
>>
>>
>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>
>>
>> Mike,
>>
>>
>>
>> You just criticize my draft. That's ok, but I would really like to get
>> some response to my questions stated in
>> https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To
>> me, it just does not seem to work, and the combination of the oauth-meta
>> and PKCE seems to be much more elegan, nicer, and much simpler to
>> implement. If you just give up the dynamic response at the authorization
>> endpoint, then you even do not have to touch the code but just change a
>> config file.
>>
>>
>>
>> Please convince me by answering to my questions.
>>
>>
>>
>> For the record of Yokohama, I do not recall much about duplication in
>> OAuth session. The poll in the room was 19 for / zero against / 4
>> persons need more information. Indeed, it is not duplicating much. And i=
f
>> you move to a new model without pre-configured discovery, it is not
>> duplicating any but the resource endpoint URI, which is optional and is =
for
>> the cases where the client did not know the concrete resource endpoint t=
o
>> start with.
>>
>>
>>
>> I understand your usecases always start from a concrete endpoint
>> location. Mine do not. In a four party model, it is likely not. The user
>> just want to have the service to fetch his data from some resource
>> endpoint. He just hits the service. He does not hit the resource endpoin=
t
>> directly. For example, in the case of a consumer using a personal financ=
e
>> platform (PFP)to manage his pension fund, he hits the PFP and not the
>> Pension fund. Assuming that the pension fund has delegated the
>> authorization control to the authorization server, then, the authorizati=
on
>> server should return both the access token and the endpoint of the pensi=
on
>> fund so that the PFP can pull the data using them. A similar model holds
>> for personal health service and health care providers.
>>
>>
>>
>> Best,
>>
>>
>>
>> Nat
>>
>>
>>
>>
>>
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 21:18 Justin Richer :
>>
>> Convergence is exactly what I=E2=80=99m arguing for, though. These thing=
s ought
>> to work together.
>>
>>
>>
>>  =E2=80=94 Justin
>>
>>
>>
>> On Jan 21, 2016, at 2:55 AM, Mike Jones 
>> wrote:
>>
>>
>>
>> My memory of the discussions of the oauth-meta draft in Yokohama were
>> that many people felt that it was unnecessarily dynamically duplicating =
a
>> lot of information that the client already had.  Most of us that were aw=
are
>> of the attacks then were in favor of a more targeted, minimal approach.
>> You were listened to in Yokohama, but that didn=E2=80=99t necessarily me=
an that
>> people agreed with the approach.  Participants were already aware of the
>> oauth-meta proposal in Darmstadt but no one spoke up in favor of it that=
 I
>> can recall.  Rather, I think people were thinking that =E2=80=9Cless is =
more=E2=80=9D.
>>
>>
>>
>> There have also been discussions in the last day about how dynamically
>> returning a resource URL, which oauth-meta does, is both unnecessary (si=
nce
>> the client initiated the resource authorization already knowing what
>> resource it wants to access) and often problematic, since many
>> authorization servers can authorize access to multiple resources.  If
>> anything, the client should be telling the authorization server what
>> resource it wants to access =E2=80=93 not the other way around.
>>
>>
>>
>> I=E2=80=99m not saying that there aren=E2=80=99t some good ideas in the =
oauth-meta draft
>> =E2=80=93 I=E2=80=99m sure there are, just as there are in the approach =
designed by the
>> participants in Darmstadt.  While I volunteered to write the first draft=
 of
>> the mix-up-mitigation approach, it really reflects something a lot of
>> people have already bought into =E2=80=93 as evidenced in the passion in=
 the
>> high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D thread,=
 and not just my
>> personal project.
>>
>>
>>
>> If you think there are things missing or wrong in the mix-up-mitigation
>> draft, please say what they are.  That will help us quickly converge on =
a
>> solution that will work for everyone.
>>
>>
>>
>>                                                           Sincerely,
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* Nat Sakimura [mailto:sakimura@gmail.com ]
>> *Sent:* Wednesday, January 20, 2016 11:17 PM
>> *To:* Mike Jones ; William Denniss <
>> wdenniss@google.com>; Justin Richer 
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>
>>
>> Hi Mike.
>>
>>
>>
>> Conversely, I would like to ask why this approach does not work for
>> Mix-up attack. As Nov stated, we in fact have discussed the approach in
>> quite a length back in Yokohama. I really would like to know why it does
>> not work.
>>
>>
>>
>> Besides, for oauth-meta approach, mix-up attack is only one of the thing
>> it solves.
>>
>>
>>
>> Nat Sakimura
>>
>>
>>
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones :
>>
>> Not to be negative, but I disagree with adopting
>> draft-sakimura-oauth-meta.  We should define and promote one mitigation
>> approach to the mix-up attacks.  Having two would confuse implementers a=
nd
>> cause compatibility problems =E2=80=93 reducing overall security.
>>
>>
>>
>> The approach defined in draft-jones-oauth-mix-up-mitigation was created
>> in collaboration with the security researchers who identified the proble=
ms
>> in the first place, was vigorously discussed in the security meeting Han=
nes
>> and Torsten held in Darmstadt, and has been since refined based on
>> substantial input from the working group.  And at least three implemente=
rs
>> have already stated that they=E2=80=99ve implemented it.  I=E2=80=99m no=
t saying that it=E2=80=99s,
>> but if there are things missing or things that need to be improved in ou=
r
>> approach, we should do it there, rather introducing a competing approach=
.
>>
>>
>>
>> Also, standard OAuth deployments register the client and then use the
>> information gathered at registration time for subsequent protocol
>> interactions.  They do not need all the configuration information for th=
e
>> authorization server to be retransmitted at runtime.  The oauth-meta dra=
ft
>> goes too far in that direction, at least as I see it.  Returning things =
two
>> ways creates its own problems, as discussed in the Duplicate Information
>> Attacks security considerations section (7.2) of the mix-up-mitigation
>> draft.
>>
>>
>>
>> I=E2=80=99ll note that the mix-up-mitigation approach is compatible with=
 existing
>> practice in both static and dynamic metadata discovery.  Replying to
>> Justin=E2=80=99s comment that =E2=80=9CIt's the pre-configured discovery=
 document that's
>> at the root of the mix-up attack in the first place=E2=80=9D =E2=80=93 t=
his is not the
>> case.  The attacks can be performed without either discovery or dynamic
>> registration.
>>
>>
>>
>> I would be interested in hearing a technical discussion on whether there
>> are aspects of the oauth-meta approach that mitigate aspects of the atta=
cks
>> that the mix-up-mitigation approach does not.  That could help inform
>> whether there are additional things we should add to or change in the
>> mix-up draft.
>>
>>
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William
>> Denniss
>> *Sent:* Wednesday, January 20, 2016 10:37 PM
>> *To:* Justin Richer 
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>
>>
>> +1 to adopt this, and I agree with Justin's comments.
>>
>>
>>
>> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer  wrote:
>>
>> +1
>>
>> Inline discovery and pre-configured discovery (ie, .well-known) should a=
t
>> the very least be compatible and developed together. It's the
>> pre-configured discovery document that's at the root of the mix-up attac=
k
>> in the first place.
>>
>>  -- Justin
>>
>>
>>
>> On 1/19/2016 10:30 PM, Nat Sakimura wrote:
>>
>> Just to give more context, at IETF 94, I have done a presentation on
>> discovery.
>>
>>
>>
>> According to the minutes,
>>
>>
>>
>>     (f) Discovery (Nat)
>>
>>
>>
>>              Nat explains his document as an example of the work that ha=
s to be done
>>
>>              in the area of discovery, which is a topic that has been id=
entified
>>
>>              as necessary for interoperability since many years but so f=
ar there
>>
>>              was not time to work on it. Mike, John and Nat are working =
on a new
>>
>>              document that describes additional discovery-relevant compo=
nents.
>>
>>
>>
>>              Poll: 19 for / zero against / 4 persons need more informati=
on.
>>
>>
>>
>> The document discussed there was
>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
>> simple (only 1-page!) but a very powerful document that nudges towards
>> HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-=
up
>> attack without introducing the concept of issuer which is not in RFC6749=
.
>> It is also good for selecting different endpoints depending on the user
>> authentication and authorization results and more privacy sensitive than
>> pre-announced Discovery document. It also allows you to find to which
>> protected resource endpoint you can use the access token against.
>>
>>
>>
>> In the last sentence of the minutes, it talks about "a new document that
>> describes additional discovery-relevant components". This is
>> https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went for
>> the call for adoption. However, it is only a half of the story. I believ=
e
>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was
>> discussed at IETF 94 and had support there should be adopted as well.
>>
>>
>>
>> Nat Sakimura
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura :
>>
>> Thanks Hannes.
>>
>>
>>
>> I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05,=
 which
>> was discussed in Yokohama, and was largely in agreement if my recollecti=
on
>> is correct. Why is it not in the call for adoption?
>>
>>
>>
>>
>>
>>
>>
>> 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig :
>>
>> Hi all,
>>
>> we have submitted our new charter to the IESG (see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
>> since some IESG members like to see an updated list of milestones as
>> well. For this reason, based on a suggestion from Barry, we are also
>> starting a call for adoption concurrently with the review of the charter
>> text by the IESG.
>>
>> We will post separate mails on the individual documents. Your feedback
>> is important! Please take the time to look at the documents and provide
>> your feedback.
>>
>> Ciao
>> Hannes & Derek
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>>
>> OAuth mailing list
>>
>> OAuth@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


I agree that the language describing OAuth issuer could an=
d should be improved. The text now reads like it is the exact and full URL =
where the metadata/discovery document is located. Perhaps something more li=
ke "the URL from which the authorization server's configuration in=
formation location can be derived" and explain that adding the .well-k=
nown bits to the issuer is where the configuration information can actually=
 be found.



On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura =
<sakimura@gmail.=
com> wrote:
Re: iss. I discussed this a bit with Nov in more details. It probably is =
a sloppy language of the specs that is making it difficult to read what you=
 wanted to achieve.=C2=A0

In mix-up-mitigation draft, OAuth=
 issuer is "the URL of the authorization server's configuration in=
formation location". In OAuth discovery draft, there is something call=
ed "OAuth 2.0 Configuration Information Location URL", which is e=
qual to "OpenID Connect Issuer".=C2=A0
When I wrote the statement=
, I thought you were pointing to the URL that you can actually pull the con=
figuration information by "the URL of the authorizaiton server's c=
onfiguration information location" since otherwise you would have used=
 the term "OAuth 2.0 Configuration Information Location URL". But=
 after all, you probably meant these two are the same. Then I would strongl=
y recommend to fix the language.=C2=A0
Now, even If that is the case, the r=
elationship like=C2=A0
  • iss + .well-know/openid-configuration =3D Connect=
 OP config endoint
  • OAuth config endp=
oint - .well-known/openid-configuration =3D OAuth iss
is very confusing.=C2=A0

Y=
ou also claim that your approach is simpler, but to me, your approach seem =
to be overly complex. It requires discovery and the check for the value of =
the discovered config information to work as the mitigation. (Right. Draft =
-01 does not have it, so it does not solve the mix-up issue.) With oauth-me=
ta, you do not need it.=C2=A0

Finally, your point=
 that HATEOAS reminds you of WSDL, it is not. If you want to have something=
 similar to WSDL in REST API area, it is Swagger. (Actually, it is gaining =
a lot of momentum recently, but that's beside the fact ;-). And the poi=
nt here is not the format but the fact that we need to have a way to associ=
ate metadata to the data. The root cause of this mix-up attack is that the =
metadata and data is not associated properly. We have a standard way of ass=
ociating the data and metadata with link-rel such as RFC5988 so why not use=
 it? Link-rel-href pattern is used a lot now. Most modern web pages actuall=
y have it. Using a proper way to associate metadata with data will save you=
 from a lot of other attacks in the future. Instead of doing patch works, w=
e should solve it=C2=A0architecturally.=C2=A0

Nat=




2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91)=
 10:34 Mike Jones <Michael.Jones@microsoft.com>:











Nat, I=E2=80=99m confused by this sta=
tement in the message you reference =E2=80=9CUnfortunately, this does not match the value
 of OAuth issuer defined in Section 2 of=C2=A0draft-jones-oauth-mix-up-miti=
gation-01 nor the 'iss' returned as specified in 3.1.=C2=A0As such,=
 validation as specified in bullet 1 of Section 4 fails in Google's cas=
e -- OR it means that the document is internally inconsistent.=E2=80=9D.=C2=A0
 The issuer definition in draft-jones-oauth-discovery is 100% compatible wi=
th the one in OpenID Connect Discovery, by design.=C2=A0 In the Google exam=
ple, both the OpenID issuer and the OAuth issuer values would be the string=
 =E2=80=9Chttps:/=
/accounts.google.com=E2=80=9D.=C2=A0 What
 is the inconsistency that you perceive?


=C2=A0


The discussion of the duplication pro=
blem happened in the private meetings in Yokohama.


=C2=A0


I will admit, in Yokohama, I didn=E2=
=80=99t speak up in the public meetings to point out that a simpler alterna=
tive to oauth-meta was already being discussed there in
 private, because then I would have had to talk about the security issues, =
which we=E2=80=99d decided not to publicly do at that point.=C2=A0 So I sta=
yed silent during the poll, out of politeness.=C2=A0 Perhaps I should have =
found a way to say something then anyway, but that=E2=80=99s
 water under the bridge now.


=C2=A0


Finally, for what it=E2=80=99s worth,=
 the HATEOAS stuff reminds me far too much of Web Services Description Lang=
uage (WSDL) =E2=80=93 part of the complexity baggage that helped
 sink Web Services.=C2=A0 The use of =E2=80=9Clink rel=E2=80=9D to define a=
n interaction vocabulary and publish endpoints for that vocabulary seems pr=
etty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=93 an=
other cute =E2=80=9CWebby=E2=80=9D innovation that never caught on.=C2=A0 T=
he industry has pretty
 much voted with its feet and is using JSON for publishing discovery data s=
tructures =E2=80=93 not =E2=80=9Clink rel=E2=80=9D.=C2=A0 I am against us r=
everting to the =E2=80=9Clink rel=E2=80=9D proposal from 2008 that never ca=
ught on when JSON is simpler and does a better job.

=C2=A0


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


=C2=A0


From: Nat Sakimura [mailto:sakimura@gmail.com]


Sent: Thursday, January 21, 2016 6:24 AM

To: Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>
Cc: William Denniss <wdenniss@google.com>; <oauth@ietf.org> <oauth@ietf.org>


Subject: Re: [OAUTH-WG] Call for Adoption


=C2=A0




Mike,=C2=A0




=C2=A0






You just criticize my draft. That's ok, but I wo=
uld really like to get some response to my questions stated in=C2=A0https://www.ietf.org/mail-archive/web/oauth/current/msg15483.=
html=C2=A0.
 To me, it just does not seem to work, and the combination of the oauth-met=
a and PKCE seems to be much more elegan, nicer, and much simpler to impleme=
nt. If you just give up the dynamic response at the authorization endpoint,=
 then you even do not have to touch
 the code but just change a config file.=C2=A0






=C2=A0






Please convince me by answering to my questions.=C2=
=A0






=C2=A0






For the record of Yokohama, I do not recall much abo=
ut duplication in OAuth session. The poll in the room was=C2=A019 for / zero against / 4 persons need mor=
e information. Indeed, it is not duplicating
 much. And if you move to a new model without pre-configured discovery, it =
is not duplicating any but the resource endpoint URI, which is optional and=
 is for the cases where the client did not know the concrete resource endpo=
int to start with.=C2=A0






=C2=A0






I unders=
tand your usecases always start from a concrete endpoint location. Mine do =
not. In a four party model, it is likely not. The user just want to have th=
e service to fetch his data from some
 resource endpoint. He just hits the service. He does not hit the resource =
endpoint directly. For example, in the case of a consumer using a personal =
finance platform (PFP)to manage his pension fund, he hits the PFP and not t=
he Pension fund. Assuming that the
 pension fund has delegated the authorization control to the authorization =
server, then, the authorization server should return both the access token =
and the endpoint of the pension fund so that the PFP can pull the data usin=
g them. A similar model holds for
 personal health service and health care providers.=C2=A0<=
/u>






=C2=A0






Best,=C2=
=A0






=C2=A0






Nat






=C2=A0






=C2=A0






2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
 21:18 Justin Richer <jricher@mit.edu>:








Convergence is exactly what I=E2=80=99m arguing for,=
 though. These things ought to work together.








=C2=A0






=C2=A0=E2=80=94 Justin










=C2=A0








On Jan 21, 2016, at 2:55 AM, Mike Jones <Michael.Jones@mic=
rosoft.com> wrote:




=C2=A0








My memory of the discussions of the o=
auth-meta draft in Yokohama were that many people felt that it
 was unnecessarily dynamically duplicating a lot of information that the cl=
ient already had.=C2=A0 Most of us that were aware of the attacks then were=
 in favor of a more targeted, minimal approach.=C2=A0 You were listened to =
in Yokohama, but that didn=E2=80=99t necessarily mean
 that people agreed with the approach.=C2=A0 Participants were already awar=
e of the oauth-meta proposal in Darmstadt but no one spoke up in favor of i=
t that I can recall.=C2=A0 Rather, I think people were thinking that =E2=80=
=9Cless is more=E2=80=9D.


=C2=A0


There have also been discussions in t=
he last day about how dynamically returning a resource URL, which
 oauth-meta does, is both unnecessary (since the client initiated the resou=
rce authorization already knowing what resource it wants to access) and oft=
en problematic, since many authorization servers can authorize access to mu=
ltiple resources.=C2=A0 If anything,
 the client should be telling the authorization server what resource it wan=
ts to access =E2=80=93 not the other way around.


=C2=A0


I=E2=80=99m not saying that there are=
n=E2=80=99t some good ideas in the oauth-meta draft =E2=80=93 I=E2=80=99m s=
ure there are, just
 as there are in the approach designed by the participants in Darmstadt.=C2=
=A0 While I volunteered to write the first draft of the mix-up-mitigation a=
pproach, it really reflects something a lot of people have already bought i=
nto =E2=80=93 as evidenced in the passion in
 the high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D threa=
d, and not just my personal project.


=C2=A0


If you think there are things missing=
 or wrong in the mix-up-mitigation draft, please say what they
 are.=C2=A0 That will help us quickly converge on a solution that will work=
 for everyone.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Sincerely,


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


=C2=A0


From: Nat Sakimura [mailto:sakimura@gmail.com]


Sent: Wednesday, January 20, 2016 11:17 PM

To: Mike Jones <Michael.Jones@microsoft.com>; William Denniss <wdenniss@google.com<=
/a>>; Justin Richer <jricher@mit.edu>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Call for Adoption


=C2=A0




Hi Mike.=C2=A0




=C2=A0






Conversely, I would like to ask why this approach do=
es not work for Mix-up attack.=C2=A0As Nov stated, we in fact have discusse=
d the approach in quite a length back in Yokohama. I really
 would like to know why it does not work.=C2=A0






=C2=A0






Besides, for oauth-meta approach, mix-up attack is o=
nly one of the thing it solves.=C2=A0






=C2=A0






Nat Sakimura






=C2=A0






2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
 16:02 Mike Jones <Michael.Jones@microsoft.com>:










Not to be negative, but I disagree wi=
th adopting draft-sakimura-oauth-meta.=C2=A0 We should define and promote
 one mitigation approach to the mix-up attacks.=C2=A0 Having two would conf=
use implementers and cause compatibility problems =E2=80=93 reducing overal=
l security.


=C2=A0


The approach defined in draft-jones-o=
auth-mix-up-mitigation was created in collaboration with the security
 researchers who identified the problems in the first place, was vigorously=
 discussed in the security meeting Hannes and Torsten held in Darmstadt, an=
d has been since refined based on substantial input from the working group.=
=C2=A0 And at least three implementers
 have already stated that they=E2=80=99ve implemented it.=C2=A0 I=E2=80=99m=
 not saying that it=E2=80=99s, but if there are things missing or things th=
at need to be improved in our approach, we should do it there, rather intro=
ducing a competing approach.


=C2=A0


Also, standard OAuth deployments regi=
ster the client and then use the information gathered at registration
 time for subsequent protocol interactions.=C2=A0 They do not need all the =
configuration information for the authorization server to be retransmitted =
at runtime.=C2=A0 The oauth-meta draft goes too far in that direction, at l=
east as I see it.=C2=A0 Returning things two ways
 creates its own problems, as discussed in the Duplicate Information Attack=
s security considerations section (7.2) of the mix-up-mitigation draft.


=C2=A0


I=E2=80=99ll note that the mix-up-mit=
igation approach is compatible with existing practice in both static and
 dynamic metadata discovery.=C2=A0 Replying to Justin=E2=80=99s comment tha=
t =E2=80=9CIt's the pre-configured discovery document that's=
 at the root of the mix-up attack in the first place=E2=80=
=9D =E2=80=93 this
 is not the case.=C2=A0 The attacks can be performed without either discove=
ry or dynamic registration.


=C2=A0


I would be interested in hearing a te=
chnical discussion on whether there are aspects of the oauth-meta
 approach that mitigate aspects of the attacks that the mix-up-mitigation a=
pproach does not.=C2=A0 That could help inform whether there are additional=
 things we should add to or change in the mix-up draft.


=C2=A0


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


=C2=A0


From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of William Denniss

Sent: Wednesday, January 20, 2016 10:37 PM

To: Justin Richer <jricher@mit.edu>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Call for Adoption










=C2=A0




+1 to adopt this, and I agree with Justin's comm=
ents.




=C2=A0




On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer <<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>=
 wrote:






+1



Inline discovery and pre-configured discovery (ie, .well-known) should at t=
he very least be compatible and developed together. It's the pre-config=
ured discovery document that's at the root of the mix-up attack in the =
first place.



=C2=A0-- Justin






=C2=A0<=
/p>



On 1/19/2016 10:30 PM, Nat Sakimura wrote:=









Just to give more context, at IETF 94, I have done a=
 presentation on discovery.=C2=A0





=C2=A0






According to the minutes,=C2=A0






=C2=A0






=C2=A0=C2=A0=C2=A0 (f) Discovery (Nat)=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Nat explains his document as an e=
xample of the work that has to be done


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the area of discovery, which is a t=
opic that has been identified


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as necessary for interoperability sinc=
e many years but so far there


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was not time to work on it. Mike, John=
 and Nat are working on a new


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document that describes additional dis=
covery-relevant components.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Poll: 19 for / zero against / 4 p=
ersons need more information.


=C2=A0


The document discussed there was

https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a sim=
ple (only 1-page!) but a very powerful document that nudges towards HATEOAS=
 which is at the core of RESTful-ness. It also mitigates the Mix-up attack =
without introducing the concept
 of issuer which is not in RFC6749. It is also good for selecting different=
 endpoints depending on the user authentication and authorization results a=
nd more privacy sensitive than pre-announced Discovery document. It also al=
lows you to find to which protected
 resource endpoint you can use the access token against.=C2=A0






=C2=A0




In the last sentence of the minutes, it talks about =
"a new document that describes additional discovery-relevant component=
s". This is=C2=A0https://tools.ietf.org/html/draft-jones=
-oauth-discovery-00.=C2=A0
 It went for the call for adoption. However, it is only a half of the story=
. I believe=C2=A0https://tools.ietf.org/html/draft-sakimura-oau=
th-meta-05=C2=A0that was discussed at IETF
 94 and had support there=C2=A0should be adopted as well.=C2=A0 <=
/u>




=C2=A0






Nat Sakimura




=C2=A0






=C2=A0






=C2=A0








=C2=A0






2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4)
 12:05 Nat Sakimura <sakimura@gmail.com>:








Thanks Hannes.=C2=A0





=C2=A0






I did not find=C2=A0https://tools.ietf.o=
rg/html/draft-sakimura-oauth-meta-05,=C2=A0which was discussed
 in Yokohama, and was largely in agreement if my recollection is correct. W=
hy is it not in the call for adoption?=C2=A0






=C2=A0






=C2=A0






=C2=A0






2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB)
 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:










Hi all,



we have submitted our new charter to the IESG (see

http://www.ietf.org/mail-archive/web/oauth/current/msg1=
5379.html) and

since some IESG members like to see an updated list of milestones as

well. For this reason, based on a suggestion from Barry, we are also

starting a call for adoption concurrently with the review of the charter
text by the IESG.



We will post separate mails on the individual documents. Your feedback

is important! Please take the time to look at the documents and provide

your feedback.



Ciao

Hannes & Derek



_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth










=C2=A0<=
/p>

_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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




=C2=A0










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth






=C2=A0










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth
















=C2=A0












_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--089e0149bd9218a0320529f48dd9--


From nobody Fri Jan 22 15:32:52 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553FF1ACD27 for ; Fri, 22 Jan 2016 15:32:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2qZhrCmfBsV for ; Fri, 22 Jan 2016 15:32:44 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0104.outbound.protection.outlook.com [65.55.169.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672B71ACD18 for ; Fri, 22 Jan 2016 15:32:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bunXQUC0TMOOLXIsozBWupUhdoThgowAXZRD1A3YEB0=; b=RCaTdsBhjBnc5ul7tV8ya1rO18H+CFNuQSVKiieIBirle+71kJeH/W2wn8c3GDMa4ZVk2CzHug1m/1N4Wxr/H5eTuDVZb/Xi8jKSLVMu7uPszc29IApllwWc5Its+EIF4YwtPmgeVBpPdqyxrPzVPIYPuTrgXA663sJJgk/sQrU=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.365.19; Fri, 22 Jan 2016 23:32:39 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Fri, 22 Jan 2016 23:32:39 +0000
From: Mike Jones 
To: Brian Campbell , Nat Sakimura 
Thread-Topic: [OAUTH-WG] Call for Adoption
Thread-Index: AQHRUq7PwpSsQC2NpkCHuu6CK/uboJ8DuV2AgAAG9YCAAK43gIABGG0AgAABNnCAAAnOAIAABVcwgABO44CAACMRAIAAtS5ggAAPmgCAAWUhgIAAAZEg
Date: Fri, 22 Jan 2016 23:32:39 +0000
Message-ID: 
References: <569E2076.2090405@gmx.net>   <569F915D.8020806@mit.edu>         
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [2001:4898:80e8:3::650]
x-ms-office365-filtering-correlation-id: 140ad65b-1703-4eb8-9cab-08d323845142
x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:eYv+9aPPBeR3tk7sb6wbymAmwxhTTFMbC1rJ9PC42G5l2VfWW/fUyQES+EHwVoDMd0rmyS7UmJbpLO/Om1W+5E+MS+IVPqCOj+TkqZZoJwhVwN6j3vaag7StnXu30GG4EaJGiOz9qsHyBZwoQLpzEA==; 24:lH6hoEb56BZSAvzRjUx1madwXVFHWdCLjEqfnDcky6c4VcOFA/daXYmgB4hx48LSWvPNvUX678oQB02GIJV10/Yy9QN/c+C8jHv+t1EM0kQ=
x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; UriScan:; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442; 
x-forefront-prvs: 08296C9B35
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(189002)(479174004)(199003)(52314003)(53754006)(377454003)(99286002)(16236675004)(5005710100001)(1096002)(5008740100001)(1220700001)(86612001)(586003)(102836003)(790700001)(6116002)(86362001)(76576001)(8990500004)(19617315012)(10400500002)(10290500002)(97736004)(93886004)(106356001)(10090500001)(106116001)(81156007)(105586002)(19609705001)(5001960100002)(5001770100001)(189998001)(74316001)(54356999)(19580405001)(561944003)(19580395003)(101416001)(87936001)(50986999)(19625215002)(33656002)(76176999)(19300405004)(5003600100002)(4326007)(5004730100002)(92566002)(2906002)(11100500001)(5002640100001)(122556002)(2900100001)(77096005)(15975445007)(40100003)(2950100001)(3826002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4422882B74ED659DB47CECDF5C40BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2016 23:32:39.3003 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 23:32:50 -0000

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

SSBsaWtlIHRoZSDigJxmcm9tIHdoaWNoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcidzIGNvbmZp
Z3VyYXRpb24gaW5mb3JtYXRpb24gbG9jYXRpb24gY2FuIGJlIGRlcml2ZWTigJ0gbGFuZ3VhZ2Uu
ICBUaGFua3MuICBJ4oCZbGwgcGxhbiB0byBpbmNvcnBvcmF0ZSB0aGF0IHRoZSBuZXh0IHRpbWUg
dGhlIGRyYWZ0IGlzIHJldmlzZWQuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IEJyaWFuIENh
bXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQpTZW50OiBGcmlkYXks
IEphbnVhcnkgMjIsIDIwMTYgMzoyNiBQTQ0KVG86IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21h
aWwuY29tPg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT47IEp1
c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdT47IDxvYXV0aEBpZXRmLm9yZz4gPG9hdXRoQGll
dGYub3JnPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgQWRvcHRpb24NCg0KSSBh
Z3JlZSB0aGF0IHRoZSBsYW5ndWFnZSBkZXNjcmliaW5nIE9BdXRoIGlzc3VlciBjb3VsZCBhbmQg
c2hvdWxkIGJlIGltcHJvdmVkLiBUaGUgdGV4dCBub3cgcmVhZHMgbGlrZSBpdCBpcyB0aGUgZXhh
Y3QgYW5kIGZ1bGwgVVJMIHdoZXJlIHRoZSBtZXRhZGF0YS9kaXNjb3ZlcnkgZG9jdW1lbnQgaXMg
bG9jYXRlZC4gUGVyaGFwcyBzb21ldGhpbmcgbW9yZSBsaWtlICJ0aGUgVVJMIGZyb20gd2hpY2gg
dGhlIGF1dGhvcml6YXRpb24gc2VydmVyJ3MgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBsb2Nh
dGlvbiBjYW4gYmUgZGVyaXZlZCIgYW5kIGV4cGxhaW4gdGhhdCBhZGRpbmcgdGhlIC53ZWxsLWtu
b3duIGJpdHMgdG8gdGhlIGlzc3VlciBpcyB3aGVyZSB0aGUgY29uZmlndXJhdGlvbiBpbmZvcm1h
dGlvbiBjYW4gYWN0dWFsbHkgYmUgZm91bmQuDQoNCg0KT24gVGh1LCBKYW4gMjEsIDIwMTYgYXQg
NzowNyBQTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJh
QGdtYWlsLmNvbT4+IHdyb3RlOg0KUmU6IGlzcy4gSSBkaXNjdXNzZWQgdGhpcyBhIGJpdCB3aXRo
IE5vdiBpbiBtb3JlIGRldGFpbHMuIEl0IHByb2JhYmx5IGlzIGEgc2xvcHB5IGxhbmd1YWdlIG9m
IHRoZSBzcGVjcyB0aGF0IGlzIG1ha2luZyBpdCBkaWZmaWN1bHQgdG8gcmVhZCB3aGF0IHlvdSB3
YW50ZWQgdG8gYWNoaWV2ZS4NCg0KDQpJbiBtaXgtdXAtbWl0aWdhdGlvbiBkcmFmdCwgT0F1dGgg
aXNzdWVyIGlzICJ0aGUgVVJMIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcidzIGNvbmZpZ3Vy
YXRpb24gaW5mb3JtYXRpb24gbG9jYXRpb24iLiBJbiBPQXV0aCBkaXNjb3ZlcnkgZHJhZnQsIHRo
ZXJlIGlzIHNvbWV0aGluZyBjYWxsZWQgIk9BdXRoIDIuMCBDb25maWd1cmF0aW9uIEluZm9ybWF0
aW9uIExvY2F0aW9uIFVSTCIsIHdoaWNoIGlzIGVxdWFsIHRvICJPcGVuSUQgQ29ubmVjdCBJc3N1
ZXIiLg0KDQpXaGVuIEkgd3JvdGUgdGhlIHN0YXRlbWVudCwgSSB0aG91Z2h0IHlvdSB3ZXJlIHBv
aW50aW5nIHRvIHRoZSBVUkwgdGhhdCB5b3UgY2FuIGFjdHVhbGx5IHB1bGwgdGhlIGNvbmZpZ3Vy
YXRpb24gaW5mb3JtYXRpb24gYnkgInRoZSBVUkwgb2YgdGhlIGF1dGhvcml6YWl0b24gc2VydmVy
J3MgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBsb2NhdGlvbiIgc2luY2Ugb3RoZXJ3aXNlIHlv
dSB3b3VsZCBoYXZlIHVzZWQgdGhlIHRlcm0gIk9BdXRoIDIuMCBDb25maWd1cmF0aW9uIEluZm9y
bWF0aW9uIExvY2F0aW9uIFVSTCIuIEJ1dCBhZnRlciBhbGwsIHlvdSBwcm9iYWJseSBtZWFudCB0
aGVzZSB0d28gYXJlIHRoZSBzYW1lLiBUaGVuIEkgd291bGQgc3Ryb25nbHkgcmVjb21tZW5kIHRv
IGZpeCB0aGUgbGFuZ3VhZ2UuDQoNCk5vdywgZXZlbiBJZiB0aGF0IGlzIHRoZSBjYXNlLCB0aGUg
cmVsYXRpb25zaGlwIGxpa2UNCsK3ICAgICAgICAgaXNzICsgLndlbGwta25vdy9vcGVuaWQtY29u
ZmlndXJhdGlvbiA9IENvbm5lY3QgT1AgY29uZmlnIGVuZG9pbnQNCsK3ICAgICAgICAgT0F1dGgg
Y29uZmlnIGVuZHBvaW50IC0gLndlbGwta25vd24vb3BlbmlkLWNvbmZpZ3VyYXRpb24gPSBPQXV0
aCBpc3MNCmlzIHZlcnkgY29uZnVzaW5nLg0KDQpZb3UgYWxzbyBjbGFpbSB0aGF0IHlvdXIgYXBw
cm9hY2ggaXMgc2ltcGxlciwgYnV0IHRvIG1lLCB5b3VyIGFwcHJvYWNoIHNlZW0gdG8gYmUgb3Zl
cmx5IGNvbXBsZXguIEl0IHJlcXVpcmVzIGRpc2NvdmVyeSBhbmQgdGhlIGNoZWNrIGZvciB0aGUg
dmFsdWUgb2YgdGhlIGRpc2NvdmVyZWQgY29uZmlnIGluZm9ybWF0aW9uIHRvIHdvcmsgYXMgdGhl
IG1pdGlnYXRpb24uIChSaWdodC4gRHJhZnQgLTAxIGRvZXMgbm90IGhhdmUgaXQsIHNvIGl0IGRv
ZXMgbm90IHNvbHZlIHRoZSBtaXgtdXAgaXNzdWUuKSBXaXRoIG9hdXRoLW1ldGEsIHlvdSBkbyBu
b3QgbmVlZCBpdC4NCg0KRmluYWxseSwgeW91ciBwb2ludCB0aGF0IEhBVEVPQVMgcmVtaW5kcyB5
b3Ugb2YgV1NETCwgaXQgaXMgbm90LiBJZiB5b3Ugd2FudCB0byBoYXZlIHNvbWV0aGluZyBzaW1p
bGFyIHRvIFdTREwgaW4gUkVTVCBBUEkgYXJlYSwgaXQgaXMgU3dhZ2dlci4gKEFjdHVhbGx5LCBp
dCBpcyBnYWluaW5nIGEgbG90IG9mIG1vbWVudHVtIHJlY2VudGx5LCBidXQgdGhhdCdzIGJlc2lk
ZSB0aGUgZmFjdCA7LSkuIEFuZCB0aGUgcG9pbnQgaGVyZSBpcyBub3QgdGhlIGZvcm1hdCBidXQg
dGhlIGZhY3QgdGhhdCB3ZSBuZWVkIHRvIGhhdmUgYSB3YXkgdG8gYXNzb2NpYXRlIG1ldGFkYXRh
IHRvIHRoZSBkYXRhLiBUaGUgcm9vdCBjYXVzZSBvZiB0aGlzIG1peC11cCBhdHRhY2sgaXMgdGhh
dCB0aGUgbWV0YWRhdGEgYW5kIGRhdGEgaXMgbm90IGFzc29jaWF0ZWQgcHJvcGVybHkuIFdlIGhh
dmUgYSBzdGFuZGFyZCB3YXkgb2YgYXNzb2NpYXRpbmcgdGhlIGRhdGEgYW5kIG1ldGFkYXRhIHdp
dGggbGluay1yZWwgc3VjaCBhcyBSRkM1OTg4IHNvIHdoeSBub3QgdXNlIGl0PyBMaW5rLXJlbC1o
cmVmIHBhdHRlcm4gaXMgdXNlZCBhIGxvdCBub3cuIE1vc3QgbW9kZXJuIHdlYiBwYWdlcyBhY3R1
YWxseSBoYXZlIGl0LiBVc2luZyBhIHByb3BlciB3YXkgdG8gYXNzb2NpYXRlIG1ldGFkYXRhIHdp
dGggZGF0YSB3aWxsIHNhdmUgeW91IGZyb20gYSBsb3Qgb2Ygb3RoZXIgYXR0YWNrcyBpbiB0aGUg
ZnV0dXJlLiBJbnN0ZWFkIG9mIGRvaW5nIHBhdGNoIHdvcmtzLCB3ZSBzaG91bGQgc29sdmUgaXQg
YXJjaGl0ZWN0dXJhbGx5Lg0KDQpOYXQNCg0KDQoNCjIwMTblubQx5pyIMjLml6Uo6YeRKSAxMDoz
NCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwu
Sm9uZXNAbWljcm9zb2Z0LmNvbT4+Og0KTmF0LCBJ4oCZbSBjb25mdXNlZCBieSB0aGlzIHN0YXRl
bWVudCBpbiB0aGUgbWVzc2FnZSB5b3UgcmVmZXJlbmNlIOKAnFVuZm9ydHVuYXRlbHksIHRoaXMg
ZG9lcyBub3QgbWF0Y2ggdGhlIHZhbHVlIG9mIE9BdXRoIGlzc3VlciBkZWZpbmVkIGluIFNlY3Rp
b24gMiBvZiBkcmFmdC1qb25lcy1vYXV0aC1taXgtdXAtbWl0aWdhdGlvbi0wMSBub3IgdGhlICdp
c3MnIHJldHVybmVkIGFzIHNwZWNpZmllZCBpbiAzLjEuIEFzIHN1Y2gsIHZhbGlkYXRpb24gYXMg
c3BlY2lmaWVkIGluIGJ1bGxldCAxIG9mIFNlY3Rpb24gNCBmYWlscyBpbiBHb29nbGUncyBjYXNl
IC0tIE9SIGl0IG1lYW5zIHRoYXQgdGhlIGRvY3VtZW50IGlzIGludGVybmFsbHkgaW5jb25zaXN0
ZW50LuKAnS4gIFRoZSBpc3N1ZXIgZGVmaW5pdGlvbiBpbiBkcmFmdC1qb25lcy1vYXV0aC1kaXNj
b3ZlcnkgaXMgMTAwJSBjb21wYXRpYmxlIHdpdGggdGhlIG9uZSBpbiBPcGVuSUQgQ29ubmVjdCBE
aXNjb3ZlcnksIGJ5IGRlc2lnbi4gIEluIHRoZSBHb29nbGUgZXhhbXBsZSwgYm90aCB0aGUgT3Bl
bklEIGlzc3VlciBhbmQgdGhlIE9BdXRoIGlzc3VlciB2YWx1ZXMgd291bGQgYmUgdGhlIHN0cmlu
ZyDigJxodHRwczovL2FjY291bnRzLmdvb2dsZS5jb23igJ0uICBXaGF0IGlzIHRoZSBpbmNvbnNp
c3RlbmN5IHRoYXQgeW91IHBlcmNlaXZlPw0KDQpUaGUgZGlzY3Vzc2lvbiBvZiB0aGUgZHVwbGlj
YXRpb24gcHJvYmxlbSBoYXBwZW5lZCBpbiB0aGUgcHJpdmF0ZSBtZWV0aW5ncyBpbiBZb2tvaGFt
YS4NCg0KSSB3aWxsIGFkbWl0LCBpbiBZb2tvaGFtYSwgSSBkaWRu4oCZdCBzcGVhayB1cCBpbiB0
aGUgcHVibGljIG1lZXRpbmdzIHRvIHBvaW50IG91dCB0aGF0IGEgc2ltcGxlciBhbHRlcm5hdGl2
ZSB0byBvYXV0aC1tZXRhIHdhcyBhbHJlYWR5IGJlaW5nIGRpc2N1c3NlZCB0aGVyZSBpbiBwcml2
YXRlLCBiZWNhdXNlIHRoZW4gSSB3b3VsZCBoYXZlIGhhZCB0byB0YWxrIGFib3V0IHRoZSBzZWN1
cml0eSBpc3N1ZXMsIHdoaWNoIHdl4oCZZCBkZWNpZGVkIG5vdCB0byBwdWJsaWNseSBkbyBhdCB0
aGF0IHBvaW50LiAgU28gSSBzdGF5ZWQgc2lsZW50IGR1cmluZyB0aGUgcG9sbCwgb3V0IG9mIHBv
bGl0ZW5lc3MuICBQZXJoYXBzIEkgc2hvdWxkIGhhdmUgZm91bmQgYSB3YXkgdG8gc2F5IHNvbWV0
aGluZyB0aGVuIGFueXdheSwgYnV0IHRoYXTigJlzIHdhdGVyIHVuZGVyIHRoZSBicmlkZ2Ugbm93
Lg0KDQpGaW5hbGx5LCBmb3Igd2hhdCBpdOKAmXMgd29ydGgsIHRoZSBIQVRFT0FTIHN0dWZmIHJl
bWluZHMgbWUgZmFyIHRvbyBtdWNoIG9mIFdlYiBTZXJ2aWNlcyBEZXNjcmlwdGlvbiBMYW5ndWFn
ZSAoV1NETCkg4oCTIHBhcnQgb2YgdGhlIGNvbXBsZXhpdHkgYmFnZ2FnZSB0aGF0IGhlbHBlZCBz
aW5rIFdlYiBTZXJ2aWNlcy4gIFRoZSB1c2Ugb2Yg4oCcbGluayByZWzigJ0gdG8gZGVmaW5lIGFu
IGludGVyYWN0aW9uIHZvY2FidWxhcnkgYW5kIHB1Ymxpc2ggZW5kcG9pbnRzIGZvciB0aGF0IHZv
Y2FidWxhcnkgc2VlbXMgcHJldHR5IGJhcm9xdWUgYW5kIHJlbWluaXNjZW50IG9mIOKAnG1pY3Jv
Zm9ybWF0c+KAnSDigJMgYW5vdGhlciBjdXRlIOKAnFdlYmJ54oCdIGlubm92YXRpb24gdGhhdCBu
ZXZlciBjYXVnaHQgb24uICBUaGUgaW5kdXN0cnkgaGFzIHByZXR0eSBtdWNoIHZvdGVkIHdpdGgg
aXRzIGZlZXQgYW5kIGlzIHVzaW5nIEpTT04gZm9yIHB1Ymxpc2hpbmcgZGlzY292ZXJ5IGRhdGEg
c3RydWN0dXJlcyDigJMgbm90IOKAnGxpbmsgcmVs4oCdLiAgSSBhbSBhZ2FpbnN0IHVzIHJldmVy
dGluZyB0byB0aGUg4oCcbGluayByZWzigJ0gcHJvcG9zYWwgZnJvbSAyMDA4IHRoYXQgbmV2ZXIg
Y2F1Z2h0IG9uIHdoZW4gSlNPTiBpcyBzaW1wbGVyIGFuZCBkb2VzIGEgYmV0dGVyIGpvYi4NCg0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTmF0IFNha2ltdXJhIFttYWlsdG86c2FraW11cmFAZ21h
aWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+XQ0KU2VudDogVGh1cnNkYXksIEphbnVh
cnkgMjEsIDIwMTYgNjoyNCBBTQ0KVG86IEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxt
YWlsdG86anJpY2hlckBtaXQuZWR1Pj47IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9z
b2Z0LmNvbTxtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj4NCkNjOiBXaWxsaWFt
IERlbm5pc3MgPHdkZW5uaXNzQGdvb2dsZS5jb208bWFpbHRvOndkZW5uaXNzQGdvb2dsZS5jb20+
PjsgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+IDxvYXV0aEBpZXRmLm9y
ZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBDYWxs
IGZvciBBZG9wdGlvbg0KDQpNaWtlLA0KDQpZb3UganVzdCBjcml0aWNpemUgbXkgZHJhZnQuIFRo
YXQncyBvaywgYnV0IEkgd291bGQgcmVhbGx5IGxpa2UgdG8gZ2V0IHNvbWUgcmVzcG9uc2UgdG8g
bXkgcXVlc3Rpb25zIHN0YXRlZCBpbiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv
d2ViL29hdXRoL2N1cnJlbnQvbXNnMTU0ODMuaHRtbCAuIFRvIG1lLCBpdCBqdXN0IGRvZXMgbm90
IHNlZW0gdG8gd29yaywgYW5kIHRoZSBjb21iaW5hdGlvbiBvZiB0aGUgb2F1dGgtbWV0YSBhbmQg
UEtDRSBzZWVtcyB0byBiZSBtdWNoIG1vcmUgZWxlZ2FuLCBuaWNlciwgYW5kIG11Y2ggc2ltcGxl
ciB0byBpbXBsZW1lbnQuIElmIHlvdSBqdXN0IGdpdmUgdXAgdGhlIGR5bmFtaWMgcmVzcG9uc2Ug
YXQgdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIHRoZW4geW91IGV2ZW4gZG8gbm90IGhhdmUg
dG8gdG91Y2ggdGhlIGNvZGUgYnV0IGp1c3QgY2hhbmdlIGEgY29uZmlnIGZpbGUuDQoNClBsZWFz
ZSBjb252aW5jZSBtZSBieSBhbnN3ZXJpbmcgdG8gbXkgcXVlc3Rpb25zLg0KDQpGb3IgdGhlIHJl
Y29yZCBvZiBZb2tvaGFtYSwgSSBkbyBub3QgcmVjYWxsIG11Y2ggYWJvdXQgZHVwbGljYXRpb24g
aW4gT0F1dGggc2Vzc2lvbi4gVGhlIHBvbGwgaW4gdGhlIHJvb20gd2FzIDE5IGZvciAvIHplcm8g
YWdhaW5zdCAvIDQgcGVyc29ucyBuZWVkIG1vcmUgaW5mb3JtYXRpb24uIEluZGVlZCwgaXQgaXMg
bm90IGR1cGxpY2F0aW5nIG11Y2guIEFuZCBpZiB5b3UgbW92ZSB0byBhIG5ldyBtb2RlbCB3aXRo
b3V0IHByZS1jb25maWd1cmVkIGRpc2NvdmVyeSwgaXQgaXMgbm90IGR1cGxpY2F0aW5nIGFueSBi
dXQgdGhlIHJlc291cmNlIGVuZHBvaW50IFVSSSwgd2hpY2ggaXMgb3B0aW9uYWwgYW5kIGlzIGZv
ciB0aGUgY2FzZXMgd2hlcmUgdGhlIGNsaWVudCBkaWQgbm90IGtub3cgdGhlIGNvbmNyZXRlIHJl
c291cmNlIGVuZHBvaW50IHRvIHN0YXJ0IHdpdGguDQoNCkkgdW5kZXJzdGFuZCB5b3VyIHVzZWNh
c2VzIGFsd2F5cyBzdGFydCBmcm9tIGEgY29uY3JldGUgZW5kcG9pbnQgbG9jYXRpb24uIE1pbmUg
ZG8gbm90LiBJbiBhIGZvdXIgcGFydHkgbW9kZWwsIGl0IGlzIGxpa2VseSBub3QuIFRoZSB1c2Vy
IGp1c3Qgd2FudCB0byBoYXZlIHRoZSBzZXJ2aWNlIHRvIGZldGNoIGhpcyBkYXRhIGZyb20gc29t
ZSByZXNvdXJjZSBlbmRwb2ludC4gSGUganVzdCBoaXRzIHRoZSBzZXJ2aWNlLiBIZSBkb2VzIG5v
dCBoaXQgdGhlIHJlc291cmNlIGVuZHBvaW50IGRpcmVjdGx5LiBGb3IgZXhhbXBsZSwgaW4gdGhl
IGNhc2Ugb2YgYSBjb25zdW1lciB1c2luZyBhIHBlcnNvbmFsIGZpbmFuY2UgcGxhdGZvcm0gKFBG
UCl0byBtYW5hZ2UgaGlzIHBlbnNpb24gZnVuZCwgaGUgaGl0cyB0aGUgUEZQIGFuZCBub3QgdGhl
IFBlbnNpb24gZnVuZC4gQXNzdW1pbmcgdGhhdCB0aGUgcGVuc2lvbiBmdW5kIGhhcyBkZWxlZ2F0
ZWQgdGhlIGF1dGhvcml6YXRpb24gY29udHJvbCB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIs
IHRoZW4sIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQgcmV0dXJuIGJvdGggdGhlIGFj
Y2VzcyB0b2tlbiBhbmQgdGhlIGVuZHBvaW50IG9mIHRoZSBwZW5zaW9uIGZ1bmQgc28gdGhhdCB0
aGUgUEZQIGNhbiBwdWxsIHRoZSBkYXRhIHVzaW5nIHRoZW0uIEEgc2ltaWxhciBtb2RlbCBob2xk
cyBmb3IgcGVyc29uYWwgaGVhbHRoIHNlcnZpY2UgYW5kIGhlYWx0aCBjYXJlIHByb3ZpZGVycy4N
Cg0KQmVzdCwNCg0KTmF0DQoNCg0KMjAxNuW5tDHmnIgyMeaXpSjmnKgpIDIxOjE4IEp1c3RpbiBS
aWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj46DQpDb252ZXJn
ZW5jZSBpcyBleGFjdGx5IHdoYXQgSeKAmW0gYXJndWluZyBmb3IsIHRob3VnaC4gVGhlc2UgdGhp
bmdzIG91Z2h0IHRvIHdvcmsgdG9nZXRoZXIuDQoNCiDigJQgSnVzdGluDQoNCk9uIEphbiAyMSwg
MjAxNiwgYXQgMjo1NSBBTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t
PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KTXkgbWVtb3J5
IG9mIHRoZSBkaXNjdXNzaW9ucyBvZiB0aGUgb2F1dGgtbWV0YSBkcmFmdCBpbiBZb2tvaGFtYSB3
ZXJlIHRoYXQgbWFueSBwZW9wbGUgZmVsdCB0aGF0IGl0IHdhcyB1bm5lY2Vzc2FyaWx5IGR5bmFt
aWNhbGx5IGR1cGxpY2F0aW5nIGEgbG90IG9mIGluZm9ybWF0aW9uIHRoYXQgdGhlIGNsaWVudCBh
bHJlYWR5IGhhZC4gIE1vc3Qgb2YgdXMgdGhhdCB3ZXJlIGF3YXJlIG9mIHRoZSBhdHRhY2tzIHRo
ZW4gd2VyZSBpbiBmYXZvciBvZiBhIG1vcmUgdGFyZ2V0ZWQsIG1pbmltYWwgYXBwcm9hY2guICBZ
b3Ugd2VyZSBsaXN0ZW5lZCB0byBpbiBZb2tvaGFtYSwgYnV0IHRoYXQgZGlkbuKAmXQgbmVjZXNz
YXJpbHkgbWVhbiB0aGF0IHBlb3BsZSBhZ3JlZWQgd2l0aCB0aGUgYXBwcm9hY2guICBQYXJ0aWNp
cGFudHMgd2VyZSBhbHJlYWR5IGF3YXJlIG9mIHRoZSBvYXV0aC1tZXRhIHByb3Bvc2FsIGluIERh
cm1zdGFkdCBidXQgbm8gb25lIHNwb2tlIHVwIGluIGZhdm9yIG9mIGl0IHRoYXQgSSBjYW4gcmVj
YWxsLiAgUmF0aGVyLCBJIHRoaW5rIHBlb3BsZSB3ZXJlIHRoaW5raW5nIHRoYXQg4oCcbGVzcyBp
cyBtb3Jl4oCdLg0KDQpUaGVyZSBoYXZlIGFsc28gYmVlbiBkaXNjdXNzaW9ucyBpbiB0aGUgbGFz
dCBkYXkgYWJvdXQgaG93IGR5bmFtaWNhbGx5IHJldHVybmluZyBhIHJlc291cmNlIFVSTCwgd2hp
Y2ggb2F1dGgtbWV0YSBkb2VzLCBpcyBib3RoIHVubmVjZXNzYXJ5IChzaW5jZSB0aGUgY2xpZW50
IGluaXRpYXRlZCB0aGUgcmVzb3VyY2UgYXV0aG9yaXphdGlvbiBhbHJlYWR5IGtub3dpbmcgd2hh
dCByZXNvdXJjZSBpdCB3YW50cyB0byBhY2Nlc3MpIGFuZCBvZnRlbiBwcm9ibGVtYXRpYywgc2lu
Y2UgbWFueSBhdXRob3JpemF0aW9uIHNlcnZlcnMgY2FuIGF1dGhvcml6ZSBhY2Nlc3MgdG8gbXVs
dGlwbGUgcmVzb3VyY2VzLiAgSWYgYW55dGhpbmcsIHRoZSBjbGllbnQgc2hvdWxkIGJlIHRlbGxp
bmcgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHdoYXQgcmVzb3VyY2UgaXQgd2FudHMgdG8gYWNj
ZXNzIOKAkyBub3QgdGhlIG90aGVyIHdheSBhcm91bmQuDQoNCknigJltIG5vdCBzYXlpbmcgdGhh
dCB0aGVyZSBhcmVu4oCZdCBzb21lIGdvb2QgaWRlYXMgaW4gdGhlIG9hdXRoLW1ldGEgZHJhZnQg
4oCTIEnigJltIHN1cmUgdGhlcmUgYXJlLCBqdXN0IGFzIHRoZXJlIGFyZSBpbiB0aGUgYXBwcm9h
Y2ggZGVzaWduZWQgYnkgdGhlIHBhcnRpY2lwYW50cyBpbiBEYXJtc3RhZHQuICBXaGlsZSBJIHZv
bHVudGVlcmVkIHRvIHdyaXRlIHRoZSBmaXJzdCBkcmFmdCBvZiB0aGUgbWl4LXVwLW1pdGlnYXRp
b24gYXBwcm9hY2gsIGl0IHJlYWxseSByZWZsZWN0cyBzb21ldGhpbmcgYSBsb3Qgb2YgcGVvcGxl
IGhhdmUgYWxyZWFkeSBib3VnaHQgaW50byDigJMgYXMgZXZpZGVuY2VkIGluIHRoZSBwYXNzaW9u
IGluIHRoZSBoaWdoLXZvbHVtZSDigJxNaXgtVXAgQWJvdXQgVGhlIE1peC1VcCBNaXRpZ2F0aW9u
4oCdIHRocmVhZCwgYW5kIG5vdCBqdXN0IG15IHBlcnNvbmFsIHByb2plY3QuDQoNCklmIHlvdSB0
aGluayB0aGVyZSBhcmUgdGhpbmdzIG1pc3Npbmcgb3Igd3JvbmcgaW4gdGhlIG1peC11cC1taXRp
Z2F0aW9uIGRyYWZ0LCBwbGVhc2Ugc2F5IHdoYXQgdGhleSBhcmUuICBUaGF0IHdpbGwgaGVscCB1
cyBxdWlja2x5IGNvbnZlcmdlIG9uIGEgc29sdXRpb24gdGhhdCB3aWxsIHdvcmsgZm9yIGV2ZXJ5
b25lLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgU2luY2VyZWx5LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogTmF0IFNha2ltdXJhIFttYWls
dG86c2FraW11cmFAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIwLCAyMDE2
IDExOjE3IFBNDQpUbzogTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1h
aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PjsgV2lsbGlhbSBEZW5uaXNzIDx3ZGVu
bmlzc0Bnb29nbGUuY29tPG1haWx0bzp3ZGVubmlzc0Bnb29nbGUuY29tPj47IEp1c3RpbiBSaWNo
ZXIgPGpyaWNoZXJAbWl0LmVkdTxtYWlsdG86anJpY2hlckBtaXQuZWR1Pj4NCkNjOiBvYXV0aEBp
ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBD
YWxsIGZvciBBZG9wdGlvbg0KDQpIaSBNaWtlLg0KDQpDb252ZXJzZWx5LCBJIHdvdWxkIGxpa2Ug
dG8gYXNrIHdoeSB0aGlzIGFwcHJvYWNoIGRvZXMgbm90IHdvcmsgZm9yIE1peC11cCBhdHRhY2su
IEFzIE5vdiBzdGF0ZWQsIHdlIGluIGZhY3QgaGF2ZSBkaXNjdXNzZWQgdGhlIGFwcHJvYWNoIGlu
IHF1aXRlIGEgbGVuZ3RoIGJhY2sgaW4gWW9rb2hhbWEuIEkgcmVhbGx5IHdvdWxkIGxpa2UgdG8g
a25vdyB3aHkgaXQgZG9lcyBub3Qgd29yay4NCg0KQmVzaWRlcywgZm9yIG9hdXRoLW1ldGEgYXBw
cm9hY2gsIG1peC11cCBhdHRhY2sgaXMgb25seSBvbmUgb2YgdGhlIHRoaW5nIGl0IHNvbHZlcy4N
Cg0KTmF0IFNha2ltdXJhDQoNCjIwMTblubQx5pyIMjHml6Uo5pyoKSAxNjowMiBNaWtlIEpvbmVz
IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z
b2Z0LmNvbT4+Og0KTm90IHRvIGJlIG5lZ2F0aXZlLCBidXQgSSBkaXNhZ3JlZSB3aXRoIGFkb3B0
aW5nIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEuICBXZSBzaG91bGQgZGVmaW5lIGFuZCBwcm9t
b3RlIG9uZSBtaXRpZ2F0aW9uIGFwcHJvYWNoIHRvIHRoZSBtaXgtdXAgYXR0YWNrcy4gIEhhdmlu
ZyB0d28gd291bGQgY29uZnVzZSBpbXBsZW1lbnRlcnMgYW5kIGNhdXNlIGNvbXBhdGliaWxpdHkg
cHJvYmxlbXMg4oCTIHJlZHVjaW5nIG92ZXJhbGwgc2VjdXJpdHkuDQoNClRoZSBhcHByb2FjaCBk
ZWZpbmVkIGluIGRyYWZ0LWpvbmVzLW9hdXRoLW1peC11cC1taXRpZ2F0aW9uIHdhcyBjcmVhdGVk
IGluIGNvbGxhYm9yYXRpb24gd2l0aCB0aGUgc2VjdXJpdHkgcmVzZWFyY2hlcnMgd2hvIGlkZW50
aWZpZWQgdGhlIHByb2JsZW1zIGluIHRoZSBmaXJzdCBwbGFjZSwgd2FzIHZpZ29yb3VzbHkgZGlz
Y3Vzc2VkIGluIHRoZSBzZWN1cml0eSBtZWV0aW5nIEhhbm5lcyBhbmQgVG9yc3RlbiBoZWxkIGlu
IERhcm1zdGFkdCwgYW5kIGhhcyBiZWVuIHNpbmNlIHJlZmluZWQgYmFzZWQgb24gc3Vic3RhbnRp
YWwgaW5wdXQgZnJvbSB0aGUgd29ya2luZyBncm91cC4gIEFuZCBhdCBsZWFzdCB0aHJlZSBpbXBs
ZW1lbnRlcnMgaGF2ZSBhbHJlYWR5IHN0YXRlZCB0aGF0IHRoZXnigJl2ZSBpbXBsZW1lbnRlZCBp
dC4gIEnigJltIG5vdCBzYXlpbmcgdGhhdCBpdOKAmXMsIGJ1dCBpZiB0aGVyZSBhcmUgdGhpbmdz
IG1pc3Npbmcgb3IgdGhpbmdzIHRoYXQgbmVlZCB0byBiZSBpbXByb3ZlZCBpbiBvdXIgYXBwcm9h
Y2gsIHdlIHNob3VsZCBkbyBpdCB0aGVyZSwgcmF0aGVyIGludHJvZHVjaW5nIGEgY29tcGV0aW5n
IGFwcHJvYWNoLg0KDQpBbHNvLCBzdGFuZGFyZCBPQXV0aCBkZXBsb3ltZW50cyByZWdpc3RlciB0
aGUgY2xpZW50IGFuZCB0aGVuIHVzZSB0aGUgaW5mb3JtYXRpb24gZ2F0aGVyZWQgYXQgcmVnaXN0
cmF0aW9uIHRpbWUgZm9yIHN1YnNlcXVlbnQgcHJvdG9jb2wgaW50ZXJhY3Rpb25zLiAgVGhleSBk
byBub3QgbmVlZCBhbGwgdGhlIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gZm9yIHRoZSBhdXRo
b3JpemF0aW9uIHNlcnZlciB0byBiZSByZXRyYW5zbWl0dGVkIGF0IHJ1bnRpbWUuICBUaGUgb2F1
dGgtbWV0YSBkcmFmdCBnb2VzIHRvbyBmYXIgaW4gdGhhdCBkaXJlY3Rpb24sIGF0IGxlYXN0IGFz
IEkgc2VlIGl0LiAgUmV0dXJuaW5nIHRoaW5ncyB0d28gd2F5cyBjcmVhdGVzIGl0cyBvd24gcHJv
YmxlbXMsIGFzIGRpc2N1c3NlZCBpbiB0aGUgRHVwbGljYXRlIEluZm9ybWF0aW9uIEF0dGFja3Mg
c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbiAoNy4yKSBvZiB0aGUgbWl4LXVwLW1pdGln
YXRpb24gZHJhZnQuDQoNCknigJlsbCBub3RlIHRoYXQgdGhlIG1peC11cC1taXRpZ2F0aW9uIGFw
cHJvYWNoIGlzIGNvbXBhdGlibGUgd2l0aCBleGlzdGluZyBwcmFjdGljZSBpbiBib3RoIHN0YXRp
YyBhbmQgZHluYW1pYyBtZXRhZGF0YSBkaXNjb3ZlcnkuICBSZXBseWluZyB0byBKdXN0aW7igJlz
IGNvbW1lbnQgdGhhdCDigJxJdCdzIHRoZSBwcmUtY29uZmlndXJlZCBkaXNjb3ZlcnkgZG9jdW1l
bnQgdGhhdCdzIGF0IHRoZSByb290IG9mIHRoZSBtaXgtdXAgYXR0YWNrIGluIHRoZSBmaXJzdCBw
bGFjZeKAnSDigJMgdGhpcyBpcyBub3QgdGhlIGNhc2UuICBUaGUgYXR0YWNrcyBjYW4gYmUgcGVy
Zm9ybWVkIHdpdGhvdXQgZWl0aGVyIGRpc2NvdmVyeSBvciBkeW5hbWljIHJlZ2lzdHJhdGlvbi4N
Cg0KSSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIGhlYXJpbmcgYSB0ZWNobmljYWwgZGlzY3Vzc2lv
biBvbiB3aGV0aGVyIHRoZXJlIGFyZSBhc3BlY3RzIG9mIHRoZSBvYXV0aC1tZXRhIGFwcHJvYWNo
IHRoYXQgbWl0aWdhdGUgYXNwZWN0cyBvZiB0aGUgYXR0YWNrcyB0aGF0IHRoZSBtaXgtdXAtbWl0
aWdhdGlvbiBhcHByb2FjaCBkb2VzIG5vdC4gIFRoYXQgY291bGQgaGVscCBpbmZvcm0gd2hldGhl
ciB0aGVyZSBhcmUgYWRkaXRpb25hbCB0aGluZ3Mgd2Ugc2hvdWxkIGFkZCB0byBvciBjaGFuZ2Ug
aW4gdGhlIG1peC11cCBkcmFmdC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogT0F1dGggW21haWx0bzpv
YXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0gT24g
QmVoYWxmIE9mIFdpbGxpYW0gRGVubmlzcw0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDIwLCAy
MDE2IDEwOjM3IFBNDQpUbzogSnVzdGluIFJpY2hlciA8anJpY2hlckBtaXQuZWR1PG1haWx0bzpq
cmljaGVyQG1pdC5lZHU+Pg0KQ2M6IG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9y
Zz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9uDQoNCisxIHRvIGFk
b3B0IHRoaXMsIGFuZCBJIGFncmVlIHdpdGggSnVzdGluJ3MgY29tbWVudHMuDQoNCk9uIFdlZCwg
SmFuIDIwLCAyMDE2IGF0IDk6NTMgUE0sIEp1c3RpbiBSaWNoZXIgPGpyaWNoZXJAbWl0LmVkdTxt
YWlsdG86anJpY2hlckBtaXQuZWR1Pj4gd3JvdGU6DQorMQ0KDQpJbmxpbmUgZGlzY292ZXJ5IGFu
ZCBwcmUtY29uZmlndXJlZCBkaXNjb3ZlcnkgKGllLCAud2VsbC1rbm93bikgc2hvdWxkIGF0IHRo
ZSB2ZXJ5IGxlYXN0IGJlIGNvbXBhdGlibGUgYW5kIGRldmVsb3BlZCB0b2dldGhlci4gSXQncyB0
aGUgcHJlLWNvbmZpZ3VyZWQgZGlzY292ZXJ5IGRvY3VtZW50IHRoYXQncyBhdCB0aGUgcm9vdCBv
ZiB0aGUgbWl4LXVwIGF0dGFjayBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNCiAtLSBKdXN0aW4NCg0K
T24gMS8xOS8yMDE2IDEwOjMwIFBNLCBOYXQgU2FraW11cmEgd3JvdGU6DQpKdXN0IHRvIGdpdmUg
bW9yZSBjb250ZXh0LCBhdCBJRVRGIDk0LCBJIGhhdmUgZG9uZSBhIHByZXNlbnRhdGlvbiBvbiBk
aXNjb3ZlcnkuDQoNCkFjY29yZGluZyB0byB0aGUgbWludXRlcywNCg0KDQogICAgKGYpIERpc2Nv
dmVyeSAoTmF0KQ0KDQoNCg0KICAgICAgICAgICAgIE5hdCBleHBsYWlucyBoaXMgZG9jdW1lbnQg
YXMgYW4gZXhhbXBsZSBvZiB0aGUgd29yayB0aGF0IGhhcyB0byBiZSBkb25lDQoNCiAgICAgICAg
ICAgICBpbiB0aGUgYXJlYSBvZiBkaXNjb3ZlcnksIHdoaWNoIGlzIGEgdG9waWMgdGhhdCBoYXMg
YmVlbiBpZGVudGlmaWVkDQoNCiAgICAgICAgICAgICBhcyBuZWNlc3NhcnkgZm9yIGludGVyb3Bl
cmFiaWxpdHkgc2luY2UgbWFueSB5ZWFycyBidXQgc28gZmFyIHRoZXJlDQoNCiAgICAgICAgICAg
ICB3YXMgbm90IHRpbWUgdG8gd29yayBvbiBpdC4gTWlrZSwgSm9obiBhbmQgTmF0IGFyZSB3b3Jr
aW5nIG9uIGEgbmV3DQoNCiAgICAgICAgICAgICBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyBhZGRp
dGlvbmFsIGRpc2NvdmVyeS1yZWxldmFudCBjb21wb25lbnRzLg0KDQoNCg0KICAgICAgICAgICAg
IFBvbGw6IDE5IGZvciAvIHplcm8gYWdhaW5zdCAvIDQgcGVyc29ucyBuZWVkIG1vcmUgaW5mb3Jt
YXRpb24uDQoNCg0KVGhlIGRvY3VtZW50IGRpc2N1c3NlZCB0aGVyZSB3YXMgaHR0cHM6Ly90b29s
cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9hdXRoLW1ldGEtMDUuIFRoaXMgaXMgYSBz
aW1wbGUgKG9ubHkgMS1wYWdlISkgYnV0IGEgdmVyeSBwb3dlcmZ1bCBkb2N1bWVudCB0aGF0IG51
ZGdlcyB0b3dhcmRzIEhBVEVPQVMgd2hpY2ggaXMgYXQgdGhlIGNvcmUgb2YgUkVTVGZ1bC1uZXNz
LiBJdCBhbHNvIG1pdGlnYXRlcyB0aGUgTWl4LXVwIGF0dGFjayB3aXRob3V0IGludHJvZHVjaW5n
IHRoZSBjb25jZXB0IG9mIGlzc3VlciB3aGljaCBpcyBub3QgaW4gUkZDNjc0OS4gSXQgaXMgYWxz
byBnb29kIGZvciBzZWxlY3RpbmcgZGlmZmVyZW50IGVuZHBvaW50cyBkZXBlbmRpbmcgb24gdGhl
IHVzZXIgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcmVzdWx0cyBhbmQgbW9yZSBw
cml2YWN5IHNlbnNpdGl2ZSB0aGFuIHByZS1hbm5vdW5jZWQgRGlzY292ZXJ5IGRvY3VtZW50LiBJ
dCBhbHNvIGFsbG93cyB5b3UgdG8gZmluZCB0byB3aGljaCBwcm90ZWN0ZWQgcmVzb3VyY2UgZW5k
cG9pbnQgeW91IGNhbiB1c2UgdGhlIGFjY2VzcyB0b2tlbiBhZ2FpbnN0Lg0KDQpJbiB0aGUgbGFz
dCBzZW50ZW5jZSBvZiB0aGUgbWludXRlcywgaXQgdGFsa3MgYWJvdXQgImEgbmV3IGRvY3VtZW50
IHRoYXQgZGVzY3JpYmVzIGFkZGl0aW9uYWwgZGlzY292ZXJ5LXJlbGV2YW50IGNvbXBvbmVudHMi
LiBUaGlzIGlzIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1vYXV0aC1k
aXNjb3ZlcnktMDAuICBJdCB3ZW50IGZvciB0aGUgY2FsbCBmb3IgYWRvcHRpb24uIEhvd2V2ZXIs
IGl0IGlzIG9ubHkgYSBoYWxmIG9mIHRoZSBzdG9yeS4gSSBiZWxpZXZlIGh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA1IHRoYXQgd2FzIGRpc2N1
c3NlZCBhdCBJRVRGIDk0IGFuZCBoYWQgc3VwcG9ydCB0aGVyZSBzaG91bGQgYmUgYWRvcHRlZCBh
cyB3ZWxsLg0KDQpOYXQgU2FraW11cmENCg0KDQoNCg0KMjAxNuW5tDHmnIgyMOaXpSjmsLQpIDEy
OjA1IE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFp
bC5jb20+PjoNClRoYW5rcyBIYW5uZXMuDQoNCkkgZGlkIG5vdCBmaW5kIGh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA1LCB3aGljaCB3YXMgZGlz
Y3Vzc2VkIGluIFlva29oYW1hLCBhbmQgd2FzIGxhcmdlbHkgaW4gYWdyZWVtZW50IGlmIG15IHJl
Y29sbGVjdGlvbiBpcyBjb3JyZWN0LiBXaHkgaXMgaXQgbm90IGluIHRoZSBjYWxsIGZvciBhZG9w
dGlvbj8NCg0KDQoNCjIwMTblubQx5pyIMTnml6Uo54GrKSAyMDozOSBIYW5uZXMgVHNjaG9mZW5p
ZyA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214
Lm5ldD4+Og0KSGkgYWxsLA0KDQp3ZSBoYXZlIHN1Ym1pdHRlZCBvdXIgbmV3IGNoYXJ0ZXIgdG8g
dGhlIElFU0cgKHNlZQ0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRo
L2N1cnJlbnQvbXNnMTUzNzkuaHRtbCkgYW5kDQpzaW5jZSBzb21lIElFU0cgbWVtYmVycyBsaWtl
IHRvIHNlZSBhbiB1cGRhdGVkIGxpc3Qgb2YgbWlsZXN0b25lcyBhcw0Kd2VsbC4gRm9yIHRoaXMg
cmVhc29uLCBiYXNlZCBvbiBhIHN1Z2dlc3Rpb24gZnJvbSBCYXJyeSwgd2UgYXJlIGFsc28NCnN0
YXJ0aW5nIGEgY2FsbCBmb3IgYWRvcHRpb24gY29uY3VycmVudGx5IHdpdGggdGhlIHJldmlldyBv
ZiB0aGUgY2hhcnRlcg0KdGV4dCBieSB0aGUgSUVTRy4NCg0KV2Ugd2lsbCBwb3N0IHNlcGFyYXRl
IG1haWxzIG9uIHRoZSBpbmRpdmlkdWFsIGRvY3VtZW50cy4gWW91ciBmZWVkYmFjaw0KaXMgaW1w
b3J0YW50ISBQbGVhc2UgdGFrZSB0aGUgdGltZSB0byBsb29rIGF0IHRoZSBkb2N1bWVudHMgYW5k
IHByb3ZpZGUNCnlvdXIgZmVlZGJhY2suDQoNCkNpYW8NCkhhbm5lcyAmIERlcmVrDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n
IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1
dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8
bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0
Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1h
aWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7
fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy
IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN
CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZh
Y2UNCgl7Zm9udC1mYW1pbHk6Ik1hbGd1biBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIg
MCAwIDIgMCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWFsZ3VuIEdvdGhpYyI7
DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAwIDAgMiAwIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg
Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh
bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r
DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv
bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu
ZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ow0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU
aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ
bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3Jt
YWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h
cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl
LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv
bGFzO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7DQoJ
Zm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlv
bjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u
bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm
aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjgxMDMyODQzOw0KCW1zby1saXN0
LXRlbXBsYXRlLWlkczozNzY5ODQxNzQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5
bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu
c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1i
aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z
by1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7
DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u
dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy
LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv
cDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp
bmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h
bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww
OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl
eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox
MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s
ZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m
YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0
LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y
NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz
O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2
ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp
LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp
bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk
bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+
DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0
YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi
b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9
IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzAwMjA2MCI+SSBsaWtlIHRoZSDigJw8L3NwYW4+ZnJvbSB3aGljaCB0aGUgYXV0aG9yaXph
dGlvbiBzZXJ2ZXIncyBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGxvY2F0aW9uIGNhbiBiZSBk
ZXJpdmVkPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPuKAnQ0KIGxhbmd1YWdlLiZuYnNw
OyBUaGFua3MuJm5ic3A7IEnigJlsbCBwbGFuIHRvIGluY29ycG9yYXRlIHRoYXQgdGhlIG5leHQg
dGltZSB0aGUgZHJhZnQgaXMgcmV2aXNlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtl
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl
cmlmO2NvbG9yOiMwMDIwNjAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZiI+IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j
b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDIyLCAyMDE2IDM6MjYgUE08
YnI+DQo8Yj5Ubzo8L2I+IE5hdCBTYWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29tJmd0Ozxi
cj4NCjxiPkNjOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t
Jmd0OzsgSnVzdGluIFJpY2hlciAmbHQ7anJpY2hlckBtaXQuZWR1Jmd0OzsgJmx0O29hdXRoQGll
dGYub3JnJmd0OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl
OiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGFncmVlIHRoYXQgdGhl
IGxhbmd1YWdlIGRlc2NyaWJpbmcgT0F1dGggaXNzdWVyIGNvdWxkIGFuZCBzaG91bGQgYmUgaW1w
cm92ZWQuIFRoZSB0ZXh0IG5vdyByZWFkcyBsaWtlIGl0IGlzIHRoZSBleGFjdCBhbmQgZnVsbCBV
Ukwgd2hlcmUgdGhlIG1ldGFkYXRhL2Rpc2NvdmVyeSBkb2N1bWVudCBpcyBsb2NhdGVkLiBQZXJo
YXBzIHNvbWV0aGluZyBtb3JlIGxpa2UNCiAmcXVvdDt0aGUgVVJMIGZyb20gd2hpY2ggdGhlIGF1
dGhvcml6YXRpb24gc2VydmVyJ3MgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBsb2NhdGlvbiBj
YW4gYmUgZGVyaXZlZCZxdW90OyBhbmQgZXhwbGFpbiB0aGF0IGFkZGluZyB0aGUgLndlbGwta25v
d24gYml0cyB0byB0aGUgaXNzdWVyIGlzIHdoZXJlIHRoZSBjb25maWd1cmF0aW9uIGluZm9ybWF0
aW9uIGNhbiBhY3R1YWxseSBiZSBmb3VuZC48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgSmFuIDIxLCAyMDE2IGF0IDc6MDcg
UE0sIE5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v
OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw
dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZTogaXNz
LiBJIGRpc2N1c3NlZCB0aGlzIGEgYml0IHdpdGggTm92IGluIG1vcmUgZGV0YWlscy4gSXQgcHJv
YmFibHkgaXMgYSBzbG9wcHkgbGFuZ3VhZ2Ugb2YgdGhlIHNwZWNzIHRoYXQgaXMgbWFraW5nIGl0
IGRpZmZpY3VsdCB0byByZWFkIHdoYXQgeW91IHdhbnRlZCB0byBhY2hpZXZlLiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo3LjVwdDtt
YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjBpbjttYXJnaW4t
Ym90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6MTUuMHB0O3dvcmQtd3JhcDpicmVhay13b3JkIj4N
CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+SW4gbWl4LXVwLW1pdGlnYXRpb24gZHJhZnQs
IE9BdXRoIGlzc3VlciBpcyAmcXVvdDt0aGUgVVJMIG9mIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl
cidzIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24gbG9jYXRpb24mcXVvdDsuIEluIE9BdXRoIGRp
c2NvdmVyeSBkcmFmdCwgdGhlcmUgaXMgc29tZXRoaW5nIGNhbGxlZCAmcXVvdDtPQXV0aCAyLjAN
CiBDb25maWd1cmF0aW9uIEluZm9ybWF0aW9uIExvY2F0aW9uIFVSTCZxdW90Oywgd2hpY2ggaXMg
ZXF1YWwgdG8gJnF1b3Q7T3BlbklEIENvbm5lY3QgSXNzdWVyJnF1b3Q7LiZuYnNwOzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6Ny41cHQ7bWFyZ2lu
LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDowaW47bWFyZ2luLWJvdHRv
bTouMDAwMXB0O2xpbmUtaGVpZ2h0OjE1LjBwdDt3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPldoZW4gSSB3cm90ZSB0aGUgc3RhdGVtZW50LCBJIHRo
b3VnaHQgeW91IHdlcmUgcG9pbnRpbmcgdG8gdGhlIFVSTCB0aGF0IHlvdSBjYW4gYWN0dWFsbHkg
cHVsbCB0aGUgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBieSAmcXVvdDt0aGUgVVJMIG9mIHRo
ZSBhdXRob3JpemFpdG9uIHNlcnZlcidzIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24NCiBsb2Nh
dGlvbiZxdW90OyBzaW5jZSBvdGhlcndpc2UgeW91IHdvdWxkIGhhdmUgdXNlZCB0aGUgdGVybSAm
cXVvdDtPQXV0aCAyLjAgQ29uZmlndXJhdGlvbiBJbmZvcm1hdGlvbiBMb2NhdGlvbiBVUkwmcXVv
dDsuIEJ1dCBhZnRlciBhbGwsIHlvdSBwcm9iYWJseSBtZWFudCB0aGVzZSB0d28gYXJlIHRoZSBz
YW1lLiBUaGVuIEkgd291bGQgc3Ryb25nbHkgcmVjb21tZW5kIHRvIGZpeCB0aGUgbGFuZ3VhZ2Uu
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDo3LjVwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjBp
bjttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bGluZS1oZWlnaHQ6MTUuMHB0O3dvcmQtd3JhcDpicmVh
ay13b3JkIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+Tm93LCBldmVuIElmIHRoYXQg
aXMgdGhlIGNhc2UsIHRoZSByZWxhdGlvbnNoaXAgbGlrZSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47dGV4dC1pbmRlbnQ6
LS4yNWluO2xpbmUtaGVpZ2h0OjE1LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtp
ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpTeW1ib2w7Y29sb3I6IzMzMzMzMyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8
c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh
bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+aXNzICYjNDM7
IC53ZWxsLWtub3cvb3BlbmlkLWNvbmZpZ3VyYXRpb24gPSBDb25uZWN0IE9QIGNvbmZpZyBlbmRv
aW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s
ZWZ0OjBpbjt0ZXh0LWluZGVudDotLjI1aW47bGluZS1oZWlnaHQ6MTUuMHB0O21zby1saXN0Omww
IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMzMzMzMzIj48c3BhbiBzdHlsZT0i
bXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l
dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMzMzMzMzIj5PQXV0aCBjb25maWcgZW5kcG9pbnQgLSAud2VsbC1rbm93bi9vcGVuaWQtY29u
ZmlndXJhdGlvbiA9IE9BdXRoIGlzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPmlzIHZlcnkgY29u
ZnVzaW5nLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPllv
dSBhbHNvIGNsYWltIHRoYXQgeW91ciBhcHByb2FjaCBpcyBzaW1wbGVyLCBidXQgdG8gbWUsIHlv
dXIgYXBwcm9hY2ggc2VlbSB0byBiZSBvdmVybHkgY29tcGxleC4gSXQgcmVxdWlyZXMgZGlzY292
ZXJ5IGFuZCB0aGUgY2hlY2sgZm9yIHRoZSB2YWx1ZSBvZiB0aGUgZGlzY292ZXJlZA0KIGNvbmZp
ZyBpbmZvcm1hdGlvbiB0byB3b3JrIGFzIHRoZSBtaXRpZ2F0aW9uLiAoUmlnaHQuIERyYWZ0IC0w
MSBkb2VzIG5vdCBoYXZlIGl0LCBzbyBpdCBkb2VzIG5vdCBzb2x2ZSB0aGUgbWl4LXVwIGlzc3Vl
LikgV2l0aCBvYXV0aC1tZXRhLCB5b3UgZG8gbm90IG5lZWQgaXQuJm5ic3A7PC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOiMzMzMzMzMiPkZpbmFsbHksIHlvdXIgcG9pbnQgdGhhdCBIQVRFT0FTIHJl
bWluZHMgeW91IG9mIFdTREwsIGl0IGlzIG5vdC4gSWYgeW91IHdhbnQgdG8gaGF2ZSBzb21ldGhp
bmcgc2ltaWxhciB0byBXU0RMIGluIFJFU1QgQVBJIGFyZWEsIGl0IGlzIFN3YWdnZXIuIChBY3R1
YWxseSwgaXQgaXMNCiBnYWluaW5nIGEgbG90IG9mIG1vbWVudHVtIHJlY2VudGx5LCBidXQgdGhh
dCdzIGJlc2lkZSB0aGUgZmFjdCA7LSkuIEFuZCB0aGUgcG9pbnQgaGVyZSBpcyBub3QgdGhlIGZv
cm1hdCBidXQgdGhlIGZhY3QgdGhhdCB3ZSBuZWVkIHRvIGhhdmUgYSB3YXkgdG8gYXNzb2NpYXRl
IG1ldGFkYXRhIHRvIHRoZSBkYXRhLiBUaGUgcm9vdCBjYXVzZSBvZiB0aGlzIG1peC11cCBhdHRh
Y2sgaXMgdGhhdCB0aGUgbWV0YWRhdGEgYW5kIGRhdGEgaXMgbm90IGFzc29jaWF0ZWQNCiBwcm9w
ZXJseS4gV2UgaGF2ZSBhIHN0YW5kYXJkIHdheSBvZiBhc3NvY2lhdGluZyB0aGUgZGF0YSBhbmQg
bWV0YWRhdGEgd2l0aCBsaW5rLXJlbCBzdWNoIGFzIFJGQzU5ODggc28gd2h5IG5vdCB1c2UgaXQ/
IExpbmstcmVsLWhyZWYgcGF0dGVybiBpcyB1c2VkIGEgbG90IG5vdy4gTW9zdCBtb2Rlcm4gd2Vi
IHBhZ2VzIGFjdHVhbGx5IGhhdmUgaXQuIFVzaW5nIGEgcHJvcGVyIHdheSB0byBhc3NvY2lhdGUg
bWV0YWRhdGEgd2l0aCBkYXRhIHdpbGwNCiBzYXZlIHlvdSBmcm9tIGEgbG90IG9mIG90aGVyIGF0
dGFja3MgaW4gdGhlIGZ1dHVyZS4gSW5zdGVhZCBvZiBkb2luZyBwYXRjaCB3b3Jrcywgd2Ugc2hv
dWxkIHNvbHZlIGl0Jm5ic3A7YXJjaGl0ZWN0dXJhbGx5LiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMzMzMzMzIj5OYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5bm0PC9zcGFuPjE8c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7m
nIg8L3NwYW4+MjI8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZx
dW90OyxzYW5zLXNlcmlmIj7ml6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPumHkTwvc3Bhbj4pDQogMTA6MzQgTWlr
ZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIg
dGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw
aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAi
Pk5hdCwgSeKAmW0gY29uZnVzZWQgYnkgdGhpcyBzdGF0ZW1lbnQgaW4gdGhlIG1lc3NhZ2UgeW91
IHJlZmVyZW5jZSDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6
YmxhY2siPlVuZm9ydHVuYXRlbHksDQogdGhpcyBkb2VzIG5vdCBtYXRjaCB0aGUgdmFsdWUgb2Yg
T0F1dGggaXNzdWVyIGRlZmluZWQgaW4gU2VjdGlvbiAyIG9mJm5ic3A7ZHJhZnQtam9uZXMtb2F1
dGgtbWl4LXVwLW1pdGlnYXRpb24tMDEgbm9yIHRoZSAnaXNzJyByZXR1cm5lZCBhcyBzcGVjaWZp
ZWQgaW4gMy4xLiZuYnNwO0FzIHN1Y2gsIHZhbGlkYXRpb24gYXMgc3BlY2lmaWVkIGluIGJ1bGxl
dCAxIG9mIFNlY3Rpb24gNCBmYWlscyBpbiBHb29nbGUncyBjYXNlIC0tIE9SIGl0IG1lYW5zIHRo
YXQgdGhlDQogZG9jdW1lbnQgaXMgaW50ZXJuYWxseSBpbmNvbnNpc3RlbnQuPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj7igJ0uJm5ic3A7IFRoZSBpc3N1ZXIgZGVmaW5pdGlv
biBpbiBkcmFmdC1qb25lcy1vYXV0aC1kaXNjb3ZlcnkgaXMgMTAwJSBjb21wYXRpYmxlIHdpdGgg
dGhlIG9uZSBpbiBPcGVuSUQgQ29ubmVjdCBEaXNjb3ZlcnksIGJ5IGRlc2lnbi4mbmJzcDsgSW4g
dGhlDQogR29vZ2xlIGV4YW1wbGUsIGJvdGggdGhlIE9wZW5JRCBpc3N1ZXIgYW5kIHRoZSBPQXV0
aCBpc3N1ZXIgdmFsdWVzIHdvdWxkIGJlIHRoZSBzdHJpbmcg4oCcPGEgaHJlZj0iaHR0cHM6Ly9h
Y2NvdW50cy5nb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9hY2NvdW50cy5nb29n
bGUuY29tPC9hPuKAnS4mbmJzcDsgV2hhdCBpcyB0aGUgaW5jb25zaXN0ZW5jeSB0aGF0IHlvdSBw
ZXJjZWl2ZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5U
aGUgZGlzY3Vzc2lvbiBvZiB0aGUgZHVwbGljYXRpb24gcHJvYmxlbSBoYXBwZW5lZCBpbiB0aGUg
cHJpdmF0ZSBtZWV0aW5ncyBpbiBZb2tvaGFtYS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMDAyMDYwIj5JIHdpbGwgYWRtaXQsIGluIFlva29oYW1hLCBJIGRpZG7igJl0
IHNwZWFrIHVwIGluIHRoZSBwdWJsaWMgbWVldGluZ3MgdG8gcG9pbnQgb3V0IHRoYXQgYSBzaW1w
bGVyIGFsdGVybmF0aXZlDQogdG8gb2F1dGgtbWV0YSB3YXMgYWxyZWFkeSBiZWluZyBkaXNjdXNz
ZWQgdGhlcmUgaW4gcHJpdmF0ZSwgYmVjYXVzZSB0aGVuIEkgd291bGQgaGF2ZSBoYWQgdG8gdGFs
ayBhYm91dCB0aGUgc2VjdXJpdHkgaXNzdWVzLCB3aGljaCB3ZeKAmWQgZGVjaWRlZCBub3QgdG8g
cHVibGljbHkgZG8gYXQgdGhhdCBwb2ludC4mbmJzcDsgU28gSSBzdGF5ZWQgc2lsZW50IGR1cmlu
ZyB0aGUgcG9sbCwgb3V0IG9mIHBvbGl0ZW5lc3MuJm5ic3A7IFBlcmhhcHMgSSBzaG91bGQgaGF2
ZQ0KIGZvdW5kIGEgd2F5IHRvIHNheSBzb21ldGhpbmcgdGhlbiBhbnl3YXksIGJ1dCB0aGF04oCZ
cyB3YXRlciB1bmRlciB0aGUgYnJpZGdlIG5vdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z
ZXJpZjtjb2xvcjojMDAyMDYwIj5GaW5hbGx5LCBmb3Igd2hhdCBpdOKAmXMgd29ydGgsIHRoZSBI
QVRFT0FTIHN0dWZmIHJlbWluZHMgbWUgZmFyIHRvbyBtdWNoIG9mIFdlYiBTZXJ2aWNlcyBEZXNj
cmlwdGlvbg0KIExhbmd1YWdlIChXU0RMKSDigJMgcGFydCBvZiB0aGUgY29tcGxleGl0eSBiYWdn
YWdlIHRoYXQgaGVscGVkIHNpbmsgV2ViIFNlcnZpY2VzLiZuYnNwOyBUaGUgdXNlIG9mIOKAnGxp
bmsgcmVs4oCdIHRvIGRlZmluZSBhbiBpbnRlcmFjdGlvbiB2b2NhYnVsYXJ5IGFuZCBwdWJsaXNo
IGVuZHBvaW50cyBmb3IgdGhhdCB2b2NhYnVsYXJ5IHNlZW1zIHByZXR0eSBiYXJvcXVlIGFuZCBy
ZW1pbmlzY2VudCBvZiDigJxtaWNyb2Zvcm1hdHPigJ0g4oCTIGFub3RoZXIgY3V0ZSDigJxXZWJi
eeKAnQ0KIGlubm92YXRpb24gdGhhdCBuZXZlciBjYXVnaHQgb24uJm5ic3A7IFRoZSBpbmR1c3Ry
eSBoYXMgcHJldHR5IG11Y2ggdm90ZWQgd2l0aCBpdHMgZmVldCBhbmQgaXMgdXNpbmcgSlNPTiBm
b3IgcHVibGlzaGluZyBkaXNjb3ZlcnkgZGF0YSBzdHJ1Y3R1cmVzIOKAkyBub3Qg4oCcbGluayBy
ZWzigJ0uJm5ic3A7IEkgYW0gYWdhaW5zdCB1cyByZXZlcnRpbmcgdG8gdGhlIOKAnGxpbmsgcmVs
4oCdIHByb3Bvc2FsIGZyb20gMjAwOCB0aGF0IG5ldmVyIGNhdWdodCBvbiB3aGVuIEpTT04gaXMN
CiBzaW1wbGVyIGFuZCBkb2VzIGEgYmV0dGVyIGpvYi48L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgLS0gTWlrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh
bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTmF0IFNha2ltdXJhIFttYWlsdG86PGEgaHJlZj0ibWFp
bHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNv
bTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMjEsIDIwMTYgNjoy
NCBBTTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpy
aWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7OyBN
aWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t
IiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+
DQo8Yj5DYzo8L2I+IFdpbGxpYW0gRGVubmlzcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOndkZW5uaXNz
QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj53ZGVubmlzc0Bnb29nbGUuY29tPC9hPiZndDs7
ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0
aEBpZXRmLm9yZzwvYT4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5vcmciIHRh
cmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBDYWxs
IGZvciBBZG9wdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NaWtlLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPllvdSBqdXN0IGNyaXRpY2l6ZSBteSBk
cmFmdC4gVGhhdCdzIG9rLCBidXQgSSB3b3VsZCByZWFsbHkgbGlrZSB0byBnZXQgc29tZSByZXNw
b25zZSB0byBteSBxdWVzdGlvbnMgc3RhdGVkIGluJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1NDgzLmh0bWwiIHRh
cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRo
L2N1cnJlbnQvbXNnMTU0ODMuaHRtbDwvYT4mbmJzcDsuDQogVG8gbWUsIGl0IGp1c3QgZG9lcyBu
b3Qgc2VlbSB0byB3b3JrLCBhbmQgdGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBvYXV0aC1tZXRhIGFu
ZCBQS0NFIHNlZW1zIHRvIGJlIG11Y2ggbW9yZSBlbGVnYW4sIG5pY2VyLCBhbmQgbXVjaCBzaW1w
bGVyIHRvIGltcGxlbWVudC4gSWYgeW91IGp1c3QgZ2l2ZSB1cCB0aGUgZHluYW1pYyByZXNwb25z
ZSBhdCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwgdGhlbiB5b3UgZXZlbiBkbyBub3QgaGF2
ZSB0byB0b3VjaA0KIHRoZSBjb2RlIGJ1dCBqdXN0IGNoYW5nZSBhIGNvbmZpZyBmaWxlLiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+UGxlYXNlIGNvbnZpbmNlIG1lIGJ5IGFuc3dlcmluZyB0byBteSBxdWVzdGlvbnMuJm5ic3A7
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij5Gb3IgdGhlIHJlY29yZCBvZiBZb2tvaGFtYSwgSSBkbyBub3QgcmVjYWxsIG11Y2ggYWJvdXQg
ZHVwbGljYXRpb24gaW4gT0F1dGggc2Vzc2lvbi4gVGhlIHBvbGwgaW4gdGhlIHJvb20gd2FzJm5i
c3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+MTkgZm9yIC8gemVy
byBhZ2FpbnN0IC8gNA0KIHBlcnNvbnMgbmVlZCBtb3JlIGluZm9ybWF0aW9uLiBJbmRlZWQsIGl0
IGlzIG5vdCBkdXBsaWNhdGluZyBtdWNoLiBBbmQgaWYgeW91IG1vdmUgdG8gYSBuZXcgbW9kZWwg
d2l0aG91dCBwcmUtY29uZmlndXJlZCBkaXNjb3ZlcnksIGl0IGlzIG5vdCBkdXBsaWNhdGluZyBh
bnkgYnV0IHRoZSByZXNvdXJjZSBlbmRwb2ludCBVUkksIHdoaWNoIGlzIG9wdGlvbmFsIGFuZCBp
cyBmb3IgdGhlIGNhc2VzIHdoZXJlIHRoZSBjbGllbnQgZGlkIG5vdCBrbm93DQogdGhlIGNvbmNy
ZXRlIHJlc291cmNlIGVuZHBvaW50IHRvIHN0YXJ0IHdpdGguJm5ic3A7PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjpibGFjayI+SSB1bmRlcnN0YW5kIHlvdXIgdXNl
Y2FzZXMgYWx3YXlzIHN0YXJ0IGZyb20gYSBjb25jcmV0ZSBlbmRwb2ludCBsb2NhdGlvbi4gTWlu
ZSBkbyBub3QuIEluIGEgZm91ciBwYXJ0eSBtb2RlbCwgaXQgaXMgbGlrZWx5IG5vdC4gVGhlIHVz
ZXINCiBqdXN0IHdhbnQgdG8gaGF2ZSB0aGUgc2VydmljZSB0byBmZXRjaCBoaXMgZGF0YSBmcm9t
IHNvbWUgcmVzb3VyY2UgZW5kcG9pbnQuIEhlIGp1c3QgaGl0cyB0aGUgc2VydmljZS4gSGUgZG9l
cyBub3QgaGl0IHRoZSByZXNvdXJjZSBlbmRwb2ludCBkaXJlY3RseS4gRm9yIGV4YW1wbGUsIGlu
IHRoZSBjYXNlIG9mIGEgY29uc3VtZXIgdXNpbmcgYSBwZXJzb25hbCBmaW5hbmNlIHBsYXRmb3Jt
IChQRlApdG8gbWFuYWdlIGhpcyBwZW5zaW9uIGZ1bmQsDQogaGUgaGl0cyB0aGUgUEZQIGFuZCBu
b3QgdGhlIFBlbnNpb24gZnVuZC4gQXNzdW1pbmcgdGhhdCB0aGUgcGVuc2lvbiBmdW5kIGhhcyBk
ZWxlZ2F0ZWQgdGhlIGF1dGhvcml6YXRpb24gY29udHJvbCB0byB0aGUgYXV0aG9yaXphdGlvbiBz
ZXJ2ZXIsIHRoZW4sIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzaG91bGQgcmV0dXJuIGJvdGgg
dGhlIGFjY2VzcyB0b2tlbiBhbmQgdGhlIGVuZHBvaW50IG9mIHRoZSBwZW5zaW9uIGZ1bmQgc28g
dGhhdCB0aGUNCiBQRlAgY2FuIHB1bGwgdGhlIGRhdGEgdXNpbmcgdGhlbS4gQSBzaW1pbGFyIG1v
ZGVsIGhvbGRzIGZvciBwZXJzb25hbCBoZWFsdGggc2VydmljZSBhbmQgaGVhbHRoIGNhcmUgcHJv
dmlkZXJzLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Y29sb3I6
YmxhY2siPkJlc3QsJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt
c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TmF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87
bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MjAxNjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuW5tDwvc3Bhbj4x
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1z
ZXJpZiI+5pyIPC9zcGFuPjIxPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBH
b3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5pelPC9zcGFuPig8c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7mnKg8L3NwYW4+KQ0KIDIx
OjE4IEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRh
cmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5lZHU8L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND
Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db252ZXJnZW5jZSBpcyBleGFjdGx5IHdoYXQg
SeKAmW0gYXJndWluZyBmb3IsIHRob3VnaC4gVGhlc2UgdGhpbmdzIG91Z2h0IHRvIHdvcmsgdG9n
ZXRoZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+Jm5ic3A74oCUIEp1c3RpbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEphbiAy
MSwgMjAxNiwgYXQgMjo1NSBBTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hh
ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWlj
cm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+
TXkgbWVtb3J5IG9mIHRoZSBkaXNjdXNzaW9ucyBvZiB0aGUgb2F1dGgtbWV0YSBkcmFmdCBpbiBZ
b2tvaGFtYSB3ZXJlIHRoYXQgbWFueSBwZW9wbGUgZmVsdCB0aGF0IGl0DQogd2FzIHVubmVjZXNz
YXJpbHkgZHluYW1pY2FsbHkgZHVwbGljYXRpbmcgYSBsb3Qgb2YgaW5mb3JtYXRpb24gdGhhdCB0
aGUgY2xpZW50IGFscmVhZHkgaGFkLiZuYnNwOyBNb3N0IG9mIHVzIHRoYXQgd2VyZSBhd2FyZSBv
ZiB0aGUgYXR0YWNrcyB0aGVuIHdlcmUgaW4gZmF2b3Igb2YgYSBtb3JlIHRhcmdldGVkLCBtaW5p
bWFsIGFwcHJvYWNoLiZuYnNwOyBZb3Ugd2VyZSBsaXN0ZW5lZCB0byBpbiBZb2tvaGFtYSwgYnV0
IHRoYXQgZGlkbuKAmXQgbmVjZXNzYXJpbHkgbWVhbg0KIHRoYXQgcGVvcGxlIGFncmVlZCB3aXRo
IHRoZSBhcHByb2FjaC4mbmJzcDsgUGFydGljaXBhbnRzIHdlcmUgYWxyZWFkeSBhd2FyZSBvZiB0
aGUgb2F1dGgtbWV0YSBwcm9wb3NhbCBpbiBEYXJtc3RhZHQgYnV0IG5vIG9uZSBzcG9rZSB1cCBp
biBmYXZvciBvZiBpdCB0aGF0IEkgY2FuIHJlY2FsbC4mbmJzcDsgUmF0aGVyLCBJIHRoaW5rIHBl
b3BsZSB3ZXJlIHRoaW5raW5nIHRoYXQg4oCcbGVzcyBpcyBtb3Jl4oCdLjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw
MDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlRoZXJlIGhhdmUgYWxzbyBiZWVuIGRp
c2N1c3Npb25zIGluIHRoZSBsYXN0IGRheSBhYm91dCBob3cgZHluYW1pY2FsbHkgcmV0dXJuaW5n
IGEgcmVzb3VyY2UgVVJMLCB3aGljaA0KIG9hdXRoLW1ldGEgZG9lcywgaXMgYm90aCB1bm5lY2Vz
c2FyeSAoc2luY2UgdGhlIGNsaWVudCBpbml0aWF0ZWQgdGhlIHJlc291cmNlIGF1dGhvcml6YXRp
b24gYWxyZWFkeSBrbm93aW5nIHdoYXQgcmVzb3VyY2UgaXQgd2FudHMgdG8gYWNjZXNzKSBhbmQg
b2Z0ZW4gcHJvYmxlbWF0aWMsIHNpbmNlIG1hbnkgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIGNhbiBh
dXRob3JpemUgYWNjZXNzIHRvIG11bHRpcGxlIHJlc291cmNlcy4mbmJzcDsgSWYgYW55dGhpbmcs
DQogdGhlIGNsaWVudCBzaG91bGQgYmUgdGVsbGluZyB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg
d2hhdCByZXNvdXJjZSBpdCB3YW50cyB0byBhY2Nlc3Mg4oCTIG5vdCB0aGUgb3RoZXIgd2F5IGFy
b3VuZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5J4oCZ
bSBub3Qgc2F5aW5nIHRoYXQgdGhlcmUgYXJlbuKAmXQgc29tZSBnb29kIGlkZWFzIGluIHRoZSBv
YXV0aC1tZXRhIGRyYWZ0IOKAkyBJ4oCZbSBzdXJlIHRoZXJlIGFyZSwganVzdA0KIGFzIHRoZXJl
IGFyZSBpbiB0aGUgYXBwcm9hY2ggZGVzaWduZWQgYnkgdGhlIHBhcnRpY2lwYW50cyBpbiBEYXJt
c3RhZHQuJm5ic3A7IFdoaWxlIEkgdm9sdW50ZWVyZWQgdG8gd3JpdGUgdGhlIGZpcnN0IGRyYWZ0
IG9mIHRoZSBtaXgtdXAtbWl0aWdhdGlvbiBhcHByb2FjaCwgaXQgcmVhbGx5IHJlZmxlY3RzIHNv
bWV0aGluZyBhIGxvdCBvZiBwZW9wbGUgaGF2ZSBhbHJlYWR5IGJvdWdodCBpbnRvIOKAkyBhcyBl
dmlkZW5jZWQgaW4gdGhlIHBhc3Npb24gaW4NCiB0aGUgaGlnaC12b2x1bWUg4oCcTWl4LVVwIEFi
b3V0IFRoZSBNaXgtVXAgTWl0aWdhdGlvbuKAnSB0aHJlYWQsIGFuZCBub3QganVzdCBteSBwZXJz
b25hbCBwcm9qZWN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIw
NjAiPklmIHlvdSB0aGluayB0aGVyZSBhcmUgdGhpbmdzIG1pc3Npbmcgb3Igd3JvbmcgaW4gdGhl
IG1peC11cC1taXRpZ2F0aW9uIGRyYWZ0LCBwbGVhc2Ugc2F5IHdoYXQgdGhleQ0KIGFyZS4mbmJz
cDsgVGhhdCB3aWxsIGhlbHAgdXMgcXVpY2tseSBjb252ZXJnZSBvbiBhIHNvbHV0aW9uIHRoYXQg
d2lsbCB3b3JrIGZvciBldmVyeW9uZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgU2luY2VyZWx5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPiBOYXQgU2FraW11cmEgWzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5j
b20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86c2FraW11cmFAZ21haWwuY29tPC9hPl0NCjxicj4N
CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjAsIDIwMTYgMTE6MTcgUE08YnI+DQo8
Yj5Ubzo8L2I+IE1pa2UgSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1p
Y3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208
L2E+Jmd0OzsgV2lsbGlhbSBEZW5uaXNzICZsdDs8YSBocmVmPSJtYWlsdG86d2Rlbm5pc3NAZ29v
Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndkZW5uaXNzQGdvb2dsZS5jb208L2E+Jmd0OzsgSnVz
dGluIFJpY2hlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpyaWNoZXJAbWl0LmVkdSIgdGFyZ2V0PSJf
YmxhbmsiPmpyaWNoZXJAbWl0LmVkdTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJt
YWlsdG86b2F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aEBpZXRmLm9yZzwvYT48
YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gQ2FsbCBmb3IgQWRvcHRpb248L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgTWlrZS4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db252ZXJzZWx5
LCBJIHdvdWxkIGxpa2UgdG8gYXNrIHdoeSB0aGlzIGFwcHJvYWNoIGRvZXMgbm90IHdvcmsgZm9y
IE1peC11cCBhdHRhY2suJm5ic3A7QXMgTm92IHN0YXRlZCwgd2UgaW4gZmFjdCBoYXZlIGRpc2N1
c3NlZCB0aGUgYXBwcm9hY2ggaW4gcXVpdGUgYSBsZW5ndGggYmFjayBpbiBZb2tvaGFtYS4gSSBy
ZWFsbHkNCiB3b3VsZCBsaWtlIHRvIGtub3cgd2h5IGl0IGRvZXMgbm90IHdvcmsuJm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5C
ZXNpZGVzLCBmb3Igb2F1dGgtbWV0YSBhcHByb2FjaCwgbWl4LXVwIGF0dGFjayBpcyBvbmx5IG9u
ZSBvZiB0aGUgdGhpbmcgaXQgc29sdmVzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TmF0IFNha2ltdXJhPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4yMDE2PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+
5bm0PC9zcGFuPjE8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZx
dW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+MjE8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7ml6U8L3NwYW4+KDxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuacqDwv
c3Bhbj4pDQogMTY6MDIgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuSm9u
ZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0
LmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw
aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp
Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Tm90IHRvIGJlIG5lZ2F0
aXZlLCBidXQgSSBkaXNhZ3JlZSB3aXRoIGFkb3B0aW5nIGRyYWZ0LXNha2ltdXJhLW9hdXRoLW1l
dGEuJm5ic3A7IFdlIHNob3VsZCBkZWZpbmUgYW5kIHByb21vdGUNCiBvbmUgbWl0aWdhdGlvbiBh
cHByb2FjaCB0byB0aGUgbWl4LXVwIGF0dGFja3MuJm5ic3A7IEhhdmluZyB0d28gd291bGQgY29u
ZnVzZSBpbXBsZW1lbnRlcnMgYW5kIGNhdXNlIGNvbXBhdGliaWxpdHkgcHJvYmxlbXMg4oCTIHJl
ZHVjaW5nIG92ZXJhbGwgc2VjdXJpdHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzAwMjA2MCI+VGhlIGFwcHJvYWNoIGRlZmluZWQgaW4gZHJhZnQtam9uZXMtb2F1dGgt
bWl4LXVwLW1pdGlnYXRpb24gd2FzIGNyZWF0ZWQgaW4gY29sbGFib3JhdGlvbiB3aXRoIHRoZSBz
ZWN1cml0eQ0KIHJlc2VhcmNoZXJzIHdobyBpZGVudGlmaWVkIHRoZSBwcm9ibGVtcyBpbiB0aGUg
Zmlyc3QgcGxhY2UsIHdhcyB2aWdvcm91c2x5IGRpc2N1c3NlZCBpbiB0aGUgc2VjdXJpdHkgbWVl
dGluZyBIYW5uZXMgYW5kIFRvcnN0ZW4gaGVsZCBpbiBEYXJtc3RhZHQsIGFuZCBoYXMgYmVlbiBz
aW5jZSByZWZpbmVkIGJhc2VkIG9uIHN1YnN0YW50aWFsIGlucHV0IGZyb20gdGhlIHdvcmtpbmcg
Z3JvdXAuJm5ic3A7IEFuZCBhdCBsZWFzdCB0aHJlZSBpbXBsZW1lbnRlcnMNCiBoYXZlIGFscmVh
ZHkgc3RhdGVkIHRoYXQgdGhleeKAmXZlIGltcGxlbWVudGVkIGl0LiZuYnNwOyBJ4oCZbSBub3Qg
c2F5aW5nIHRoYXQgaXTigJlzLCBidXQgaWYgdGhlcmUgYXJlIHRoaW5ncyBtaXNzaW5nIG9yIHRo
aW5ncyB0aGF0IG5lZWQgdG8gYmUgaW1wcm92ZWQgaW4gb3VyIGFwcHJvYWNoLCB3ZSBzaG91bGQg
ZG8gaXQgdGhlcmUsIHJhdGhlciBpbnRyb2R1Y2luZyBhIGNvbXBldGluZyBhcHByb2FjaC48L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp
bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMDAyMDYwIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0
b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5BbHNvLCBzdGFuZGFy
ZCBPQXV0aCBkZXBsb3ltZW50cyByZWdpc3RlciB0aGUgY2xpZW50IGFuZCB0aGVuIHVzZSB0aGUg
aW5mb3JtYXRpb24gZ2F0aGVyZWQgYXQgcmVnaXN0cmF0aW9uDQogdGltZSBmb3Igc3Vic2VxdWVu
dCBwcm90b2NvbCBpbnRlcmFjdGlvbnMuJm5ic3A7IFRoZXkgZG8gbm90IG5lZWQgYWxsIHRoZSBj
b25maWd1cmF0aW9uIGluZm9ybWF0aW9uIGZvciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdG8g
YmUgcmV0cmFuc21pdHRlZCBhdCBydW50aW1lLiZuYnNwOyBUaGUgb2F1dGgtbWV0YSBkcmFmdCBn
b2VzIHRvbyBmYXIgaW4gdGhhdCBkaXJlY3Rpb24sIGF0IGxlYXN0IGFzIEkgc2VlIGl0LiZuYnNw
OyBSZXR1cm5pbmcgdGhpbmdzIHR3byB3YXlzDQogY3JlYXRlcyBpdHMgb3duIHByb2JsZW1zLCBh
cyBkaXNjdXNzZWQgaW4gdGhlIER1cGxpY2F0ZSBJbmZvcm1hdGlvbiBBdHRhY2tzIHNlY3VyaXR5
IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gKDcuMikgb2YgdGhlIG1peC11cC1taXRpZ2F0aW9uIGRy
YWZ0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPknigJls
bCBub3RlIHRoYXQgdGhlIG1peC11cC1taXRpZ2F0aW9uIGFwcHJvYWNoIGlzIGNvbXBhdGlibGUg
d2l0aCBleGlzdGluZyBwcmFjdGljZSBpbiBib3RoIHN0YXRpYyBhbmQNCiBkeW5hbWljIG1ldGFk
YXRhIGRpc2NvdmVyeS4mbmJzcDsgUmVwbHlpbmcgdG8gSnVzdGlu4oCZcyBjb21tZW50IHRoYXQg
4oCcPC9zcGFuPkl0J3MgdGhlIHByZS1jb25maWd1cmVkIGRpc2NvdmVyeSBkb2N1bWVudCB0aGF0
J3MgYXQgdGhlIHJvb3Qgb2YgdGhlIG1peC11cCBhdHRhY2sgaW4gdGhlIGZpcnN0IHBsYWNlPHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPuKAnSDigJMgdGhpcw0KIGlzIG5vdCB0aGUgY2Fz
ZS4mbmJzcDsgVGhlIGF0dGFja3MgY2FuIGJlIHBlcmZvcm1lZCB3aXRob3V0IGVpdGhlciBkaXNj
b3Zlcnkgb3IgZHluYW1pYyByZWdpc3RyYXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzAwMjA2MCI+SSB3b3VsZCBiZSBpbnRlcmVzdGVkIGluIGhlYXJpbmcgYSB0
ZWNobmljYWwgZGlzY3Vzc2lvbiBvbiB3aGV0aGVyIHRoZXJlIGFyZSBhc3BlY3RzIG9mIHRoZSBv
YXV0aC1tZXRhDQogYXBwcm9hY2ggdGhhdCBtaXRpZ2F0ZSBhc3BlY3RzIG9mIHRoZSBhdHRhY2tz
IHRoYXQgdGhlIG1peC11cC1taXRpZ2F0aW9uIGFwcHJvYWNoIGRvZXMgbm90LiZuYnNwOyBUaGF0
IGNvdWxkIGhlbHAgaW5mb3JtIHdoZXRoZXIgdGhlcmUgYXJlIGFkZGl0aW9uYWwgdGhpbmdzIHdl
IHNob3VsZCBhZGQgdG8gb3IgY2hhbmdlIGluIHRoZSBtaXgtdXAgZHJhZnQuPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+PG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9IjE3MTYzNjEyODdfbXNn
LWY6MTUyNDAyODEyODYyMTY0MjU1MF9tc2ciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw
Ij4mbmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBP
QXV0aCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg
PC9iPldpbGxpYW0gRGVubmlzczxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkg
MjAsIDIwMTYgMTA6MzcgUE08YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBSaWNoZXIgJmx0OzxhIGhy
ZWY9Im1haWx0bzpqcmljaGVyQG1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIj5qcmljaGVyQG1pdC5l
ZHU8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+
IFJlOiBbT0FVVEgtV0ddIENhbGwgZm9yIEFkb3B0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz
cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiYjNDM7MSB0
byBhZG9wdCB0aGlzLCBhbmQgSSBhZ3JlZSB3aXRoIEp1c3RpbidzIGNvbW1lbnRzLjxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEphbiAyMCwgMjAxNiBh
dCA5OjUzIFBNLCBKdXN0aW4gUmljaGVyICZsdDs8YSBocmVmPSJtYWlsdG86anJpY2hlckBtaXQu
ZWR1IiB0YXJnZXQ9Il9ibGFuayI+anJpY2hlckBtaXQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48
L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s
aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu
OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0
OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiYjNDM7MTxicj4NCjxicj4NCklubGlu
ZSBkaXNjb3ZlcnkgYW5kIHByZS1jb25maWd1cmVkIGRpc2NvdmVyeSAoaWUsIC53ZWxsLWtub3du
KSBzaG91bGQgYXQgdGhlIHZlcnkgbGVhc3QgYmUgY29tcGF0aWJsZSBhbmQgZGV2ZWxvcGVkIHRv
Z2V0aGVyLiBJdCdzIHRoZSBwcmUtY29uZmlndXJlZCBkaXNjb3ZlcnkgZG9jdW1lbnQgdGhhdCdz
IGF0IHRoZSByb290IG9mIHRoZSBtaXgtdXAgYXR0YWNrIGluIHRoZSBmaXJzdCBwbGFjZS48c3Bh
biBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KJm5ic3A7LS0gSnVzdGluPC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gMS8xOS8yMDE2
IDEwOjMwIFBNLCBOYXQgU2FraW11cmEgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0
bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SnVzdCB0byBnaXZlIG1vcmUgY29udGV4dCwg
YXQgSUVURiA5NCwgSSBoYXZlIGRvbmUgYSBwcmVzZW50YXRpb24gb24gZGlzY292ZXJ5LiZuYnNw
Ow0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWNj
b3JkaW5nIHRvIHRoZSBtaW51dGVzLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IChmKSBEaXNjb3ZlcnkgKE5hdCk8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtOYXQgZXhw
bGFpbnMgaGlzIGRvY3VtZW50IGFzIGFuIGV4YW1wbGUgb2YgdGhlIHdvcmsgdGhhdCBoYXMgdG8g
YmUgZG9uZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW4gdGhlIGFyZWEgb2YgZGlzY292ZXJ5LCB3aGlj
aCBpcyBhIHRvcGljIHRoYXQgaGFzIGJlZW4gaWRlbnRpZmllZDwvc3Bhbj48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
YXMgbmVjZXNzYXJ5IGZvciBpbnRlcm9wZXJhYmlsaXR5IHNpbmNlIG1hbnkgeWVhcnMgYnV0IHNv
IGZhciB0aGVyZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2FzIG5vdCB0aW1lIHRvIHdvcmsgb24gaXQu
IE1pa2UsIEpvaG4gYW5kIE5hdCBhcmUgd29ya2luZyBvbiBhIG5ldzwvc3Bhbj48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgYWRkaXRpb25hbCBkaXNjb3ZlcnktcmVsZXZhbnQg
Y29tcG9uZW50cy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtQb2xsOiAxOSBmb3IgLyB6ZXJv
IGFnYWluc3QgLyA0IHBlcnNvbnMgbmVlZCBtb3JlIGluZm9ybWF0aW9uLjwvc3Bhbj48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286
cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGRvY3VtZW50IGRpc2N1c3NlZCB0
aGVyZSB3YXMNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtp
bXVyYS1vYXV0aC1tZXRhLTA1IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0YS0wNTwvYT4uIFRoaXMgaXMgYSBzaW1w
bGUgKG9ubHkgMS1wYWdlISkgYnV0IGEgdmVyeSBwb3dlcmZ1bCBkb2N1bWVudCB0aGF0IG51ZGdl
cyB0b3dhcmRzIEhBVEVPQVMgd2hpY2ggaXMgYXQgdGhlIGNvcmUgb2YgUkVTVGZ1bC1uZXNzLiBJ
dCBhbHNvIG1pdGlnYXRlcyB0aGUgTWl4LXVwIGF0dGFjayB3aXRob3V0IGludHJvZHVjaW5nIHRo
ZSBjb25jZXB0DQogb2YgaXNzdWVyIHdoaWNoIGlzIG5vdCBpbiBSRkM2NzQ5LiBJdCBpcyBhbHNv
IGdvb2QgZm9yIHNlbGVjdGluZyBkaWZmZXJlbnQgZW5kcG9pbnRzIGRlcGVuZGluZyBvbiB0aGUg
dXNlciBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiByZXN1bHRzIGFuZCBtb3JlIHBy
aXZhY3kgc2Vuc2l0aXZlIHRoYW4gcHJlLWFubm91bmNlZCBEaXNjb3ZlcnkgZG9jdW1lbnQuIEl0
IGFsc28gYWxsb3dzIHlvdSB0byBmaW5kIHRvIHdoaWNoIHByb3RlY3RlZA0KIHJlc291cmNlIGVu
ZHBvaW50IHlvdSBjYW4gdXNlIHRoZSBhY2Nlc3MgdG9rZW4gYWdhaW5zdC4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gdGhlIGxhc3Qg
c2VudGVuY2Ugb2YgdGhlIG1pbnV0ZXMsIGl0IHRhbGtzIGFib3V0ICZxdW90O2EgbmV3IGRvY3Vt
ZW50IHRoYXQgZGVzY3JpYmVzIGFkZGl0aW9uYWwgZGlzY292ZXJ5LXJlbGV2YW50IGNvbXBvbmVu
dHMmcXVvdDsuIFRoaXMgaXMmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5LTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvbmVzLW9hdXRoLWRpc2NvdmVyeS0wMDwvYT4u
Jm5ic3A7DQogSXQgd2VudCBmb3IgdGhlIGNhbGwgZm9yIGFkb3B0aW9uLiBIb3dldmVyLCBpdCBp
cyBvbmx5IGEgaGFsZiBvZiB0aGUgc3RvcnkuIEkgYmVsaWV2ZSZuYnNwOzxhIGhyZWY9Imh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWtpbXVyYS1vYXV0aC1tZXRhLTA1IiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNha2ltdXJhLW9h
dXRoLW1ldGEtMDU8L2E+Jm5ic3A7dGhhdCB3YXMgZGlzY3Vzc2VkIGF0IElFVEYNCiA5NCBhbmQg
aGFkIHN1cHBvcnQgdGhlcmUmbmJzcDtzaG91bGQgYmUgYWRvcHRlZCBhcyB3ZWxsLiZuYnNwOyA8
bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z
by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5OYXQgU2Fr
aW11cmE8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp
bi1ib3R0b20tYWx0OmF1dG8iPjIwMTY8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFs
Z3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7lubQ8L3NwYW4+MTxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMtc2VyaWYiPuaciDwvc3Bhbj4y
MDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1b3Q7LHNhbnMt
c2VyaWYiPuaXpTwvc3Bhbj4oPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBH
b3RoaWMmcXVvdDssc2Fucy1zZXJpZiI+5rC0PC9zcGFuPikNCiAxMjowNSBOYXQgU2FraW11cmEg
Jmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5z
YWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7
cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj5UaGFua3MgSGFubmVzLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBkaWQgbm90IGZpbmQmbmJzcDs8YSBo
cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2FraW11cmEtb2F1dGgtbWV0
YS0wNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z
YWtpbXVyYS1vYXV0aC1tZXRhLTA1PC9hPiwmbmJzcDt3aGljaCB3YXMgZGlzY3Vzc2VkDQogaW4g
WW9rb2hhbWEsIGFuZCB3YXMgbGFyZ2VseSBpbiBhZ3JlZW1lbnQgaWYgbXkgcmVjb2xsZWN0aW9u
IGlzIGNvcnJlY3QuIFdoeSBpcyBpdCBub3QgaW4gdGhlIGNhbGwgZm9yIGFkb3B0aW9uPyZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs
dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj4yMDE2PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01hbGd1biBHb3Ro
aWMmcXVvdDssc2Fucy1zZXJpZiI+5bm0PC9zcGFuPjE8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7mnIg8L3NwYW4+MTk8c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OyxzYW5zLXNlcmlmIj7m
l6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNYWxndW4gR290aGljJnF1
b3Q7LHNhbnMtc2VyaWYiPueBqzwvc3Bhbj4pDQogMjA6MzkgSGFubmVzIFRzY2hvZmVuaWcgJmx0
OzxhIGhyZWY9Im1haWx0bzpoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0IiB0YXJnZXQ9Il9ibGFu
ayI+aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp
bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h
bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgYWxsLDxicj4NCjxicj4NCndl
IGhhdmUgc3VibWl0dGVkIG91ciBuZXcgY2hhcnRlciB0byB0aGUgSUVTRyAoc2VlPGJyPg0KPGEg
aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQv
bXNnMTUzNzkuaHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h
cmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzE1Mzc5Lmh0bWw8L2E+KSBhbmQ8YnI+DQpzaW5j
ZSBzb21lIElFU0cgbWVtYmVycyBsaWtlIHRvIHNlZSBhbiB1cGRhdGVkIGxpc3Qgb2YgbWlsZXN0
b25lcyBhczxicj4NCndlbGwuIEZvciB0aGlzIHJlYXNvbiwgYmFzZWQgb24gYSBzdWdnZXN0aW9u
IGZyb20gQmFycnksIHdlIGFyZSBhbHNvPGJyPg0Kc3RhcnRpbmcgYSBjYWxsIGZvciBhZG9wdGlv
biBjb25jdXJyZW50bHkgd2l0aCB0aGUgcmV2aWV3IG9mIHRoZSBjaGFydGVyPGJyPg0KdGV4dCBi
eSB0aGUgSUVTRy48YnI+DQo8YnI+DQpXZSB3aWxsIHBvc3Qgc2VwYXJhdGUgbWFpbHMgb24gdGhl
IGluZGl2aWR1YWwgZG9jdW1lbnRzLiBZb3VyIGZlZWRiYWNrPGJyPg0KaXMgaW1wb3J0YW50ISBQ
bGVhc2UgdGFrZSB0aGUgdGltZSB0byBsb29rIGF0IHRoZSBkb2N1bWVudHMgYW5kIHByb3ZpZGU8
YnI+DQp5b3VyIGZlZWRiYWNrLjxicj4NCjxicj4NCkNpYW88YnI+DQpIYW5uZXMgJmFtcDsgRGVy
ZWs8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBp
ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2Js
YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+
PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn
aW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxw
cmU+T0F1dGggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFp
bHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PG86
cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At
YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0K
PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+T0F1dGhAaWV0
Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxp
c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5P
QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h
cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls
dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+
PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BY2PR03MB4422882B74ED659DB47CECDF5C40BY2PR03MB442namprd_--


From nobody Fri Jan 22 15:45:50 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559661B2BB7 for ; Fri, 22 Jan 2016 15:45:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oIWd0JzDRv1 for ; Fri, 22 Jan 2016 15:45:48 -0800 (PST)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1441B2BB5 for ; Fri, 22 Jan 2016 15:45:47 -0800 (PST)
Received: by mail-ig0-x22a.google.com with SMTP id h5so1902692igh.0 for ; Fri, 22 Jan 2016 15:45:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qOyyXorrp1w6EyqYF2JdrzRm19wIwkqIaimq9yOVzT8=; b=I2BjA/EKhaPEToN5piKJx00N4EIvitWLZv32wT34dOuAECOVEsLwq5SSVtCipdng1t sgGF1USUcM4vB/AgAdjsNlc5L1GP9rPeDUAD54miqC2RmcWSfiX3pzEnRHhacPVzqmd/ M+TAhIpnHmMstIuCwoctcAF66YKViiOUBlKXU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qOyyXorrp1w6EyqYF2JdrzRm19wIwkqIaimq9yOVzT8=; b=FgynqZXSpRoItG0I3oHgrH8fUm4l1DTckBvtJFuQFKBS4qjR5aIyBPGwvirCQget7f 0S/s3+iKF+APSo/7/lj95iWbTUBfGrbrgigQcpAk1yHR72PKGSjaSb8DWwOb0PfA6P/o OFVHLm8E+/+cjXj7dhqISSZhSqW1pWaDdAHgy8fygXa7coLop/LNDKHeb5krAkT+yPYd AKYtrASzacLxEyhxap8PYuTaxrNvRXkxQlqRvKV/DTxHeNDjcg3Btxj5p92HYC9Jr/CR f1csS2nkIQtIR8Vtp9iufo+3RTRln00GIlFgCDm/ElOsS3slfe2q6kozt0/XFfaJxwDl j/LQ==
X-Gm-Message-State: AG10YOQblQ+Nv+Y90fmg0jDPVgsOeG0ZIOVvyJmp5+ZvEiquUlUD4X7T1CM72BsN2a3wNYn6bxFkwKLeXOnYHY12
MIME-Version: 1.0
X-Received: by 10.50.160.43 with SMTP id xh11mr5768345igb.73.1453506347142; Fri, 22 Jan 2016 15:45:47 -0800 (PST)
Received: by 10.64.162.131 with HTTP; Fri, 22 Jan 2016 15:45:47 -0800 (PST)
In-Reply-To: 
References: 
Date: Fri, 22 Jan 2016 15:45:47 -0800
Message-ID: 
From: Chuck Mortimore 
To: William Denniss 
Content-Type: multipart/alternative; boundary=001a11c30c8a8057ef0529f4d1f5
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 23:45:49 -0000

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

We quietly rolled out PKCE support at Salesforce a year ago, as well.
We're on a slightly earlier draft, but look to be compliant with final RFC
with one exception - we default to S256, and do not have support for "plain=
"

Would be interesting to interop test our deployments.

-cmort

On Mon, Jan 18, 2016 at 9:46 PM, William Denniss 
wrote:

> This month we rolled out full PKCE (RFC7636) support on our OAuth
> endpoints.
>
> We'd previously implemented an earlier draft but were not conformant to
> the final spec when it was published =E2=80=93 now we are. Both "plain" a=
nd "S256"
> transforms are supported. As always, get the latest endpoints from our
> discovery document:
> https://accounts.google.com/.well-known/openid-configuration
>
> If you give it a spin, let me know how you go! The team monitors the Stac=
k
> Overflow google-oauth
>  tag too, for any
> implementation questions.
>
> I'm keen to know what we should be putting in our discovery doc to declar=
e
> PKCE support (see the thread "Advertise PKCE support in OAuth 2.0
> Discovery"), hope we can agree on that soon.
>
> One implementation detail not covered in the spec: we error if you
> send code_verifier to the token endpoint when exchanging a code that was
> issued without a code_challenge being present. The assumption being that =
if
> you are sending code_verifier on the token exchange, you are using PKCE a=
nd
> should have sent code_challenge on the authorization request, so somethin=
g
> is amiss.
>
> William
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


We quietly rolled out PKCE support at Salesforce a year ag=
o, as well. =C2=A0 We're on a slightly earlier draft, but look to be co=
mpliant with final RFC with one exception - we default to S256, and do not =
have support for "plain"

Would be interesting =
to interop test our deployments.

-cmort

On Mon, Jan 18, =
2016 at 9:46 PM, William Denniss <wdenniss@google.com> wro=
te:
This month we rolled out full PK=
CE (RFC7636) support on our OAuth endpoints.

We=
9;d previously implemented an earlier draft but were not conformant to the =
final spec when it was published =E2=80=93 now we are. Both "plain&quo=
t; and "S256" transforms are supported. As always, get the latest=
 endpoints from our discovery document:=C2=A0https://accoun=
ts.google.com/.well-known/openid-configuration

If you give it a spin, let me know how you go! The team monitors the Stack=
 Overflow=C2=A0google-oauth=C2=A0tag=C2=A0too, for any implem=
entation questions.

I'm keen to know what we should=
 be putting in our discovery doc to declare PKCE support (see the thread &q=
uot;Advertise PKCE support in OAuth 2.0 Discovery"), hope we can agree=
 on that soon.

One implementation detail not covered in =
the spec: we error if you send=C2=A0code_verifier=C2=A0to the token endpoin=
t when exchanging a code that was issued without a code_challenge being pre=
sent. The assumption being that if you are sending code_verifier on the tok=
en exchange, you are using PKCE and should have sent code_challenge on the =
authorization request, so something is amiss.
<=
font color=3D"#888888">

William






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a11c30c8a8057ef0529f4d1f5--


From nobody Fri Jan 22 16:21:41 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD1E1B2D97 for ; Fri, 22 Jan 2016 16:21:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw0E7LfOIwHm for ; Fri, 22 Jan 2016 16:21:39 -0800 (PST)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1561B2D8E for ; Fri, 22 Jan 2016 16:21:38 -0800 (PST)
Received: by mail-qg0-x229.google.com with SMTP id 6so70100241qgy.1 for ; Fri, 22 Jan 2016 16:21:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UDrarGK7kVDH83CAaA1S0vK+i6zygTY+yjbYw5sQD4k=; b=z7RzyPY+8JrV6c6EL5j/BzYV3qZI39h/PY/9cMyOz2HJexYoyX9hPgDye3fEEa6UNN eWv0yV5XIa4/ArzMejbkS8ODQBI6q8Po4h6HZvhBfvGkperdfrcD0QzN9igZi0OHZF0V /5+fo1b8o1axrUb9LMZZBTrKp4/o+KGtOz9fSbgHc+QO2+6GEWF9zEmL8VdscadBMsxF G92AWdJhFRNBuXV2A1IdnjoY4i4VnlPPkjpqPHEt4gpVvx2zDvxaXCTt9UCC9tNeya3F vT6NWZ6MUGj2ExqdSsGhnZE9+GbVObI5e04GYVbYBqsan1OtyQc/8hwHSJQaK/XdvbjY Rvww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=UDrarGK7kVDH83CAaA1S0vK+i6zygTY+yjbYw5sQD4k=; b=iKI7K8M/fMhgZv/Sae7NXTF7H+fCKLa5NVRTJa+f1cO7nNsisL6HJaICH3KNKk4viX /MHM9Eng16N2ZdTiB7dJwZea7s80z0+gqjbz/B1tQOtbeDcQlaPgoQAniJJc7SjcTol6 xZvlLSB3PiOkUDVg1Eip5eY2NQT3JQVAICUYqVHxvzuvtE0BnSnZTRdgqIZu/9QZcBaG SXnrC6ruKGe4kdjjpzukqJBND4PyY1uyKYzhTTyCldmgAb+UqS+BbX86U/jgdITCm/vE NoyQleYx6C4HwwYyZPYUwJRl/Hyo2SKEPhs+4uccS4GpX2ByGbtRlCWsoBEwMSko4N2E ZGLw==
X-Gm-Message-State: AG10YOQ81oeN9m4HJVTBX3UNV6Z1mr6XayWPCD0dJlhlhXVbgzEYEZjiljSAN3pJv0zlPg==
X-Received: by 10.140.201.20 with SMTP id w20mr7819934qha.10.1453508497868; Fri, 22 Jan 2016 16:21:37 -0800 (PST)
Received: from [192.168.8.100] ([181.202.234.84]) by smtp.gmail.com with ESMTPSA id l18sm3847421qgd.36.2016.01.22.16.21.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 22 Jan 2016 16:21:36 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_2B64CC80-DF04-4541-AE2A-3E8780FEC300"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Fri, 22 Jan 2016 21:21:34 -0300
Message-Id: <0E094321-8A8A-4D94-8BE9-27D49BC6572F@ve7jtb.com>
References:  
To: Chuck Mortimore 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2016 00:21:41 -0000

--Apple-Mail=_2B64CC80-DF04-4541-AE2A-3E8780FEC300
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_44243156-7584-4771-95F1-C73F2A1A1DC8"


--Apple-Mail=_44243156-7584-4771-95F1-C73F2A1A1DC8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

In the final spec plain is not MTI.  S256 is MTI for the server in Sec =
4.2. so you are OK.

The client will default to plain if it doesn=E2=80=99t set a =
code_challenge_method.

That was to be backwards compatible with the people who deployed when =
plain was the only option.

John B.
> On Jan 22, 2016, at 8:45 PM, Chuck Mortimore =
 wrote:
>=20
> We quietly rolled out PKCE support at Salesforce a year ago, as well.  =
 We're on a slightly earlier draft, but look to be compliant with final =
RFC with one exception - we default to S256, and do not have support for =
"plain"
>=20
> Would be interesting to interop test our deployments.
>=20
> -cmort
>=20
> On Mon, Jan 18, 2016 at 9:46 PM, William Denniss > wrote:
> This month we rolled out full PKCE (RFC7636) support on our OAuth =
endpoints.
>=20
> We'd previously implemented an earlier draft but were not conformant =
to the final spec when it was published =E2=80=93 now we are. Both =
"plain" and "S256" transforms are supported. As always, get the latest =
endpoints from our discovery document: =
https://accounts.google.com/.well-known/openid-configuration =

>=20
> If you give it a spin, let me know how you go! The team monitors the =
Stack Overflow google-oauth =
 tag too, for =
any implementation questions.
>=20
> I'm keen to know what we should be putting in our discovery doc to =
declare PKCE support (see the thread "Advertise PKCE support in OAuth =
2.0 Discovery"), hope we can agree on that soon.
>=20
> One implementation detail not covered in the spec: we error if you =
send code_verifier to the token endpoint when exchanging a code that was =
issued without a code_challenge being present. The assumption being that =
if you are sending code_verifier on the token exchange, you are using =
PKCE and should have sent code_challenge on the authorization request, =
so something is amiss.
>=20
> William
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_44243156-7584-4771-95F1-C73F2A1A1DC8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

In the final spec plain is not MTI.  S256 is MTI for the =
server in Sec 4.2. so you are OK.

The client will default to plain if it doesn=E2=80=99t set a =
code_challenge_method.

That was to be backwards compatible with the people who =
deployed when plain was the only option.

John B.
On Jan 22, 2016, at 8:45 PM, =
Chuck Mortimore <cmortimore@salesforce.com> wrote:

We quietly rolled out PKCE support at Salesforce a year ago, =
as well.   We're on a slightly earlier draft, but look to be =
compliant with final RFC with one exception - we default to S256, and do =
not have support for "plain"

Would be interesting to interop test our =
deployments.

-cmort

On Mon, Jan 18, 2016 at 9:46 PM, =
William Denniss <wdenniss@google.com> wrote:
This =
month we rolled out full PKCE (RFC7636) support on our OAuth =
endpoints.

We'd =
previously implemented an earlier draft but were not conformant to the =
final spec when it was published =E2=80=93 now we are. Both "plain" and =
"S256" transforms are supported. As always, get the latest endpoints =
from our discovery document: https://accounts.google.com/.well-known/openid-configuration

If you give =
it a spin, let me know how you go! The team monitors the Stack =
Overflow google-oauth tag too, for any =
implementation questions.

I'm =
keen to know what we should be putting in our discovery doc to declare =
PKCE support (see the thread "Advertise PKCE support in OAuth 2.0 =
Discovery"), hope we can agree on that soon.

One implementation detail not covered =
in the spec: we error if you send code_verifier to the token =
endpoint when exchanging a code that was issued without a code_challenge =
being present. The assumption being that if you are sending =
code_verifier on the token exchange, you are using PKCE and should have =
sent code_challenge on the authorization request, so something is =
amiss.

William






_______________________________________________

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=_44243156-7584-4771-95F1-C73F2A1A1DC8--

--Apple-Mail=_2B64CC80-DF04-4541-AE2A-3E8780FEC300
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjMwMDIxMzRaMCMGCSqGSIb3DQEJBDEWBBTnerAVkDFf9MS5KqzytAj+
OFUd8zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBRlEM+S0W+kVGbvuKVpqv559vYGR1mHbJI4ciLBRLvRqdaotntqZ5A
bDOnZ/pw1lJsvmf9aaxzutCv32CpvESH8ZHPKLs2yfWaOUGNAtqFUhbL4gb4WGZ+R138AjvPDtRD
jJqigA6AtdVVy5FYiXukUz98mQGXQIueBZv3K5OekSaUstSJCWNam2UDDPFtQrtQzzsXecK0Wxlh
qawc0jtlNw6joiNmJa+yU1w/r/4+hJkzDa565fnJB0aeTfqaqhfMyM703qQjwWtwZd1HyxKBiyUB
qZNJCHubmb8WcK9kAdwV2T7R0X6wq3nmB77FIXva6arYJTmcTcHJv/VIHky2AAAAAAAA
--Apple-Mail=_2B64CC80-DF04-4541-AE2A-3E8780FEC300--


From nobody Fri Jan 22 16:43:27 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1111B2E0F for ; Fri, 22 Jan 2016 16:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoLc9g05oqdN for ; Fri, 22 Jan 2016 16:43:24 -0800 (PST)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A28D1B2DFD for ; Fri, 22 Jan 2016 16:43:24 -0800 (PST)
Received: by mail-ig0-x229.google.com with SMTP id z14so2654224igp.1 for ; Fri, 22 Jan 2016 16:43:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salesforce.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AAyc1Ts0QS+FZTyFIJ2lNr20lKK/jFwwEnFZ4W2WIBY=; b=OEwbeq6/lqpovyNSqMYnmvAX5dvKYEZqhAQYaRfOSwUIi76E/OLU2kY8rh5ZV4rv9e NpvDqdBZeJ9HpSnNBmbA1H8V7tFkdxX6adOxu7DymXZhjOeDz7RgDeXRmJnagoIt1e87 sEFqGm00R3bMpRcMo32rVKPDA75mEuSCv9nI8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AAyc1Ts0QS+FZTyFIJ2lNr20lKK/jFwwEnFZ4W2WIBY=; b=UCNbHqddw27Alyay2HtWf8ZmhbQ4WOnaa62Peyvr3wdLmZ+xkPyrxgBeZyUKtTYISj WzNsQniF6hLFdSiI07qvrFBvVVixbRrGOSvTS3NdqKIKU2NkgWY9SO296lk+5KyQe45e G7+Gk1LQRg2sBb3LbaHaRmt+pCoZHBq1MqsT+qVQq1Rs6Nt0wIa4P4aZiyKQt7D1kWV/ fxORYHqPyIMi8/Ict2iDE1ZE27nMtH7fJPXQcXXVYx8KjU4tvJZs+4X3ybyLxKBKatVt ScfPNBWAGl87VSVAW/nDuu625ROmshTB2qTmdKntM+hSlKdLr3oSYHp9X3AiyYO6tDEb i78A==
X-Gm-Message-State: AG10YORI5B4DSZ1bsY/ZD9y3iBrFp1CPsPGRiD2NgQzcV0Ga0cy5guhjBtzn7uqLNyLHNhO9ad97JvdW89Rzk4P3
MIME-Version: 1.0
X-Received: by 10.50.36.74 with SMTP id o10mr5912246igj.73.1453509803888; Fri, 22 Jan 2016 16:43:23 -0800 (PST)
Received: by 10.64.162.131 with HTTP; Fri, 22 Jan 2016 16:43:23 -0800 (PST)
In-Reply-To: <0E094321-8A8A-4D94-8BE9-27D49BC6572F@ve7jtb.com>
References:   <0E094321-8A8A-4D94-8BE9-27D49BC6572F@ve7jtb.com>
Date: Fri, 22 Jan 2016 16:43:23 -0800
Message-ID: 
From: Chuck Mortimore 
To: John Bradley 
Content-Type: multipart/alternative; boundary=089e013a00208a12130529f59f16
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2016 00:43:26 -0000

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

Thanks - we'll fail if the client defaults to plain, as we didn't
implement.    Will take a look in the future though.

I am curious if an implementing client can move back and forth between
Salesforce and Google implementations.    If someone tries, please let us
know!

On Fri, Jan 22, 2016 at 4:21 PM, John Bradley  wrote:

> In the final spec plain is not MTI.  S256 is MTI for the server in Sec
> 4.2. so you are OK.
>
> The client will default to plain if it doesn=E2=80=99t set a code_challen=
ge_method.
>
> That was to be backwards compatible with the people who deployed when
> plain was the only option.
>
> John B.
>
> On Jan 22, 2016, at 8:45 PM, Chuck Mortimore 
> wrote:
>
> We quietly rolled out PKCE support at Salesforce a year ago, as well.
> We're on a slightly earlier draft, but look to be compliant with final RF=
C
> with one exception - we default to S256, and do not have support for "pla=
in"
>
> Would be interesting to interop test our deployments.
>
> -cmort
>
> On Mon, Jan 18, 2016 at 9:46 PM, William Denniss 
> wrote:
>
>> This month we rolled out full PKCE (RFC7636) support on our OAuth
>> endpoints.
>>
>> We'd previously implemented an earlier draft but were not conformant to
>> the final spec when it was published =E2=80=93 now we are. Both "plain" =
and "S256"
>> transforms are supported. As always, get the latest endpoints from our
>> discovery document:
>> https://accounts.google.com/.well-known/openid-configuration
>>
>> If you give it a spin, let me know how you go! The team monitors the
>> Stack Overflow google-oauth
>>  tag too, for
>> any implementation questions.
>>
>> I'm keen to know what we should be putting in our discovery doc to
>> declare PKCE support (see the thread "Advertise PKCE support in OAuth 2.=
0
>> Discovery"), hope we can agree on that soon.
>>
>> One implementation detail not covered in the spec: we error if you
>> send code_verifier to the token endpoint when exchanging a code that was
>> issued without a code_challenge being present. The assumption being that=
 if
>> you are sending code_verifier on the token exchange, you are using PKCE =
and
>> should have sent code_challenge on the authorization request, so somethi=
ng
>> is amiss.
>>
>> William
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
>

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


Thanks - we'll fail if the client defaults to plain, a=
s we didn't implement. =C2=A0 =C2=A0Will take a look in the future thou=
gh. =C2=A0 =C2=A0=C2=A0

I am curious if an implementing =
client can move back and forth between Salesforce and Google implementation=
s. =C2=A0 =C2=A0If someone tries, please let us know!

On Fri, Jan 22, 2016 at 4:2=
1 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
In the final spec p=
lain is not MTI.=C2=A0 S256 is MTI for the server in Sec 4.2. so you are OK=
.

The client will default to plain if it doesn=E2=80=99t=
 set a code_challenge_method.

That was to be backw=
ards compatible with the people who deployed when plain was the only option=
.

John B.

On Jan 22, 2016, at 8:45 PM, Chuck Mortimore <cmortimore@sales=
force.com> wrote:

We quietly rolled o=
ut PKCE support at Salesforce a year ago, as well. =C2=A0 We're on a sl=
ightly earlier draft, but look to be compliant with final RFC with one exce=
ption - we default to S256, and do not have support for "plain"
Would be interesting to interop test our deployments.

-cmort

On Mon, Jan 18, 2016 at 9:46 PM, William Denniss <wdenniss@google.com> wrote:
https://accounts.google.com/.well-known/openid-con=
figuration

If you give it a spin, let me know =
how you go! The team monitors the Stack Overflow=C2=A0google-oaut=
h=C2=A0tag=C2=A0too, for any implementation questions.

I'm keen to know what we should be putting in our discovery doc to =
declare PKCE support (see the thread "Advertise PKCE support in OAuth =
2.0 Discovery"), hope we can agree on that soon.

On=
e implementation detail not covered in the spec: we error if you send=C2=A0=
code_verifier=C2=A0to the token endpoint when exchanging a code that was is=
sued without a code_challenge being present. The assumption being that if y=
ou are sending code_verifier on the token exchange, you are using PKCE and =
should have sent code_challenge on the authorization request, so something =
is amiss.

William






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




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



--089e013a00208a12130529f59f16--


From nobody Fri Jan 22 17:29:28 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57471B2E9D for ; Fri, 22 Jan 2016 17:29:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi8RnmuOnUMd for ; Fri, 22 Jan 2016 17:29:20 -0800 (PST)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d: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 438041B2E9B for ; Fri, 22 Jan 2016 17:29:20 -0800 (PST)
Received: by mail-qk0-x22b.google.com with SMTP id x1so35590591qkc.1 for ; Fri, 22 Jan 2016 17:29:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=8oCouqo4EEBfDuMHY9lxS9+6ENsI9Du1vxwXrGWHQE8=; b=yHBhJoguZb39JDhJ4mtscYG4AuFUObBUV9y1WQmfA5z8AwpUa2T9avjAqnKitwGoqj ic8P9fafayrofkwPafrJDyrYB0swaUv1nFa6iP5oHlROhZD37LWKecq0p8KFPmvEQrqW LcNstVkp+j/Qp7UNISvtWcb9VlpbXRtOo9n1Cgx6UnrqTRlRD2zMiMJsAyIwDTyVfyDv srwRT+DzK4t5SoQe3aOim3slXJsY2HLwRxzJ7v4cpndbP4g3ufENeHhRzmave8iTP2PU ykMrqKP6ZvdfzfFiHaZ7XgqdB6yYQJ5T2GD25FoIyoE0k+64wIm9AJ3XoK9A5PahfxV2 ycXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=8oCouqo4EEBfDuMHY9lxS9+6ENsI9Du1vxwXrGWHQE8=; b=JrAaINa7UQbJIPoC7STnXfzMFy2imjHzY8Q9S+w9mju0XGDMQBNbAZe17INZg+SSIc lJze3OhUNYqoYctdocE8lJ6gzcCaMv2RSu+DW4+mlHBg2WV85kIp+J24DQxKBcBqrk5W r8jIk5wiLKEn/WSxVLxBdBNdluGGYP54ie00nk0O6/ogtUlafCoMLs9FFc/rEZarCdKm 6LQ8P/Z5v7q2t8lY7hklYOYfEGNGAVOk8lWXHpldvxifmUjqZccf6jEQRPs/6A1WsKW5 rEDjqveETEuDck6jfEhaRhyNZEX5HBsSkH2Hv5904EnL+DpU9kL1UHNIIcmrTMFWMNZp ZzsQ==
X-Gm-Message-State: AG10YORq7BjQcmoDWyVfeb0EzH5kRkVnmq/IVS8+iWq0VUgjXePvPqGDW8cftrJDtTiFHTWwx3vZQDzAQhneQA==
X-Received: by 10.55.71.135 with SMTP id u129mr7689358qka.26.1453512559372; Fri, 22 Jan 2016 17:29:19 -0800 (PST)
MIME-Version: 1.0
References: <569E2076.2090405@gmx.net>   <569F915D.8020806@mit.edu>          
In-Reply-To: 
From: Nat Sakimura 
Date: Sat, 23 Jan 2016 01:29:08 +0000
Message-ID: 
To: Mike Jones ,  Brian Campbell 
Content-Type: multipart/alternative; boundary=001a114a7d20c730a30529f64304
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2016 01:29:26 -0000

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

I wrote a blog on why the current mix-up draft approach does not solve the
issue.

http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc674=
9/

Hopefully, the point I am making is clearer by this.

Best,

Nat

2016=E5=B9=B41=E6=9C=8823=E6=97=A5(=E5=9C=9F) 8:32 Mike Jones :

> I like the =E2=80=9Cfrom which the authorization server's configuration
> information location can be derived=E2=80=9D language.  Thanks.  I=E2=80=
=99ll plan to
> incorporate that the next time the draft is revised.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Brian Campbell [mailto:bcampbell@pingidentity.com]
> *Sent:* Friday, January 22, 2016 3:26 PM
> *To:* Nat Sakimura 
> *Cc:* Mike Jones ; Justin Richer <
> jricher@mit.edu>;  
>
>
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>
> I agree that the language describing OAuth issuer could and should be
> improved. The text now reads like it is the exact and full URL where the
> metadata/discovery document is located. Perhaps something more like "the
> URL from which the authorization server's configuration information
> location can be derived" and explain that adding the .well-known bits to
> the issuer is where the configuration information can actually be found.
>
>
>
> On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura  wrote:
>
> Re: iss. I discussed this a bit with Nov in more details. It probably is =
a
> sloppy language of the specs that is making it difficult to read what you
> wanted to achieve.
>
>
>
> In mix-up-mitigation draft, OAuth issuer is "the URL of the authorization
> server's configuration information location". In OAuth discovery draft,
> there is something called "OAuth 2.0 Configuration Information Location
> URL", which is equal to "OpenID Connect Issuer".
>
> When I wrote the statement, I thought you were pointing to the URL that
> you can actually pull the configuration information by "the URL of the
> authorizaiton server's configuration information location" since otherwis=
e
> you would have used the term "OAuth 2.0 Configuration Information Locatio=
n
> URL". But after all, you probably meant these two are the same. Then I
> would strongly recommend to fix the language.
>
> Now, even If that is the case, the relationship like
>
> =C2=B7         iss + .well-know/openid-configuration =3D Connect OP confi=
g
> endoint
>
> =C2=B7         OAuth config endpoint - .well-known/openid-configuration =
=3D
> OAuth iss
>
> is very confusing.
>
>
>
> You also claim that your approach is simpler, but to me, your approach
> seem to be overly complex. It requires discovery and the check for the
> value of the discovered config information to work as the mitigation.
> (Right. Draft -01 does not have it, so it does not solve the mix-up issue=
.)
> With oauth-meta, you do not need it.
>
>
>
> Finally, your point that HATEOAS reminds you of WSDL, it is not. If you
> want to have something similar to WSDL in REST API area, it is Swagger.
> (Actually, it is gaining a lot of momentum recently, but that's beside th=
e
> fact ;-). And the point here is not the format but the fact that we need =
to
> have a way to associate metadata to the data. The root cause of this mix-=
up
> attack is that the metadata and data is not associated properly. We have =
a
> standard way of associating the data and metadata with link-rel such as
> RFC5988 so why not use it? Link-rel-href pattern is used a lot now. Most
> modern web pages actually have it. Using a proper way to associate metada=
ta
> with data will save you from a lot of other attacks in the future. Instea=
d
> of doing patch works, we should solve it architecturally.
>
>
>
> Nat
>
>
>
>
>
>
>
> 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 10:34 Mike Jones :
>
> Nat, I=E2=80=99m confused by this statement in the message you reference =
=E2=80=9CUnfortunately,
> this does not match the value of OAuth issuer defined in Section 2
> of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as
> specified in 3.1. As such, validation as specified in bullet 1 of Section=
 4
> fails in Google's case -- OR it means that the document is internally
> inconsistent.=E2=80=9D.  The issuer definition in draft-jones-oauth-disco=
very is
> 100% compatible with the one in OpenID Connect Discovery, by design.  In
> the Google example, both the OpenID issuer and the OAuth issuer values
> would be the string =E2=80=9Chttps://accounts.google.com=E2=80=9D.  What =
is the
> inconsistency that you perceive?
>
>
>
> The discussion of the duplication problem happened in the private meeting=
s
> in Yokohama.
>
>
>
> I will admit, in Yokohama, I didn=E2=80=99t speak up in the public meetin=
gs to
> point out that a simpler alternative to oauth-meta was already being
> discussed there in private, because then I would have had to talk about t=
he
> security issues, which we=E2=80=99d decided not to publicly do at that po=
int.  So I
> stayed silent during the poll, out of politeness.  Perhaps I should have
> found a way to say something then anyway, but that=E2=80=99s water under =
the bridge
> now.
>
>
>
> Finally, for what it=E2=80=99s worth, the HATEOAS stuff reminds me far to=
o much of
> Web Services Description Language (WSDL) =E2=80=93 part of the complexity=
 baggage
> that helped sink Web Services.  The use of =E2=80=9Clink rel=E2=80=9D to =
define an
> interaction vocabulary and publish endpoints for that vocabulary seems
> pretty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=
=93 another cute =E2=80=9CWebby=E2=80=9D
> innovation that never caught on.  The industry has pretty much voted with
> its feet and is using JSON for publishing discovery data structures =E2=
=80=93 not
> =E2=80=9Clink rel=E2=80=9D.  I am against us reverting to the =E2=80=9Cli=
nk rel=E2=80=9D proposal from 2008
> that never caught on when JSON is simpler and does a better job.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Nat Sakimura [mailto:sakimura@gmail.com]
> *Sent:* Thursday, January 21, 2016 6:24 AM
> *To:* Justin Richer ; Mike Jones <
> Michael.Jones@microsoft.com>
> *Cc:* William Denniss ;  <
> oauth@ietf.org>
>
>
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>
> Mike,
>
>
>
> You just criticize my draft. That's ok, but I would really like to get
> some response to my questions stated in
> https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To
> me, it just does not seem to work, and the combination of the oauth-meta
> and PKCE seems to be much more elegan, nicer, and much simpler to
> implement. If you just give up the dynamic response at the authorization
> endpoint, then you even do not have to touch the code but just change a
> config file.
>
>
>
> Please convince me by answering to my questions.
>
>
>
> For the record of Yokohama, I do not recall much about duplication in
> OAuth session. The poll in the room was 19 for / zero against / 4 persons
> need more information. Indeed, it is not duplicating much. And if you mov=
e
> to a new model without pre-configured discovery, it is not duplicating an=
y
> but the resource endpoint URI, which is optional and is for the cases whe=
re
> the client did not know the concrete resource endpoint to start with.
>
>
>
> I understand your usecases always start from a concrete endpoint location=
.
> Mine do not. In a four party model, it is likely not. The user just want =
to
> have the service to fetch his data from some resource endpoint. He just
> hits the service. He does not hit the resource endpoint directly. For
> example, in the case of a consumer using a personal finance platform
> (PFP)to manage his pension fund, he hits the PFP and not the Pension fund=
.
> Assuming that the pension fund has delegated the authorization control to
> the authorization server, then, the authorization server should return bo=
th
> the access token and the endpoint of the pension fund so that the PFP can
> pull the data using them. A similar model holds for personal health servi=
ce
> and health care providers.
>
>
>
> Best,
>
>
>
> Nat
>
>
>
>
>
> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 21:18 Justin Richer :
>
> Convergence is exactly what I=E2=80=99m arguing for, though. These things=
 ought to
> work together.
>
>
>
>  =E2=80=94 Justin
>
>
>
> On Jan 21, 2016, at 2:55 AM, Mike Jones 
> wrote:
>
>
>
> My memory of the discussions of the oauth-meta draft in Yokohama were tha=
t
> many people felt that it was unnecessarily dynamically duplicating a lot =
of
> information that the client already had.  Most of us that were aware of t=
he
> attacks then were in favor of a more targeted, minimal approach.  You wer=
e
> listened to in Yokohama, but that didn=E2=80=99t necessarily mean that pe=
ople
> agreed with the approach.  Participants were already aware of the
> oauth-meta proposal in Darmstadt but no one spoke up in favor of it that =
I
> can recall.  Rather, I think people were thinking that =E2=80=9Cless is m=
ore=E2=80=9D.
>
>
>
> There have also been discussions in the last day about how dynamically
> returning a resource URL, which oauth-meta does, is both unnecessary (sin=
ce
> the client initiated the resource authorization already knowing what
> resource it wants to access) and often problematic, since many
> authorization servers can authorize access to multiple resources.  If
> anything, the client should be telling the authorization server what
> resource it wants to access =E2=80=93 not the other way around.
>
>
>
> I=E2=80=99m not saying that there aren=E2=80=99t some good ideas in the o=
auth-meta draft =E2=80=93
> I=E2=80=99m sure there are, just as there are in the approach designed by=
 the
> participants in Darmstadt.  While I volunteered to write the first draft =
of
> the mix-up-mitigation approach, it really reflects something a lot of
> people have already bought into =E2=80=93 as evidenced in the passion in =
the
> high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D thread, =
and not just my
> personal project.
>
>
>
> If you think there are things missing or wrong in the mix-up-mitigation
> draft, please say what they are.  That will help us quickly converge on a
> solution that will work for everyone.
>
>
>
>                                                           Sincerely,
>
>                                                           -- Mike
>
>
>
> *From:* Nat Sakimura [mailto:sakimura@gmail.com ]
> *Sent:* Wednesday, January 20, 2016 11:17 PM
> *To:* Mike Jones ; William Denniss <
> wdenniss@google.com>; Justin Richer 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>
> Hi Mike.
>
>
>
> Conversely, I would like to ask why this approach does not work for Mix-u=
p
> attack. As Nov stated, we in fact have discussed the approach in quite a
> length back in Yokohama. I really would like to know why it does not work=
.
>
>
>
> Besides, for oauth-meta approach, mix-up attack is only one of the thing
> it solves.
>
>
>
> Nat Sakimura
>
>
>
> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones :
>
> Not to be negative, but I disagree with adopting
> draft-sakimura-oauth-meta.  We should define and promote one mitigation
> approach to the mix-up attacks.  Having two would confuse implementers an=
d
> cause compatibility problems =E2=80=93 reducing overall security.
>
>
>
> The approach defined in draft-jones-oauth-mix-up-mitigation was created i=
n
> collaboration with the security researchers who identified the problems i=
n
> the first place, was vigorously discussed in the security meeting Hannes
> and Torsten held in Darmstadt, and has been since refined based on
> substantial input from the working group.  And at least three implementer=
s
> have already stated that they=E2=80=99ve implemented it.  I=E2=80=99m not=
 saying that it=E2=80=99s,
> but if there are things missing or things that need to be improved in our
> approach, we should do it there, rather introducing a competing approach.
>
>
>
> Also, standard OAuth deployments register the client and then use the
> information gathered at registration time for subsequent protocol
> interactions.  They do not need all the configuration information for the
> authorization server to be retransmitted at runtime.  The oauth-meta draf=
t
> goes too far in that direction, at least as I see it.  Returning things t=
wo
> ways creates its own problems, as discussed in the Duplicate Information
> Attacks security considerations section (7.2) of the mix-up-mitigation
> draft.
>
>
>
> I=E2=80=99ll note that the mix-up-mitigation approach is compatible with =
existing
> practice in both static and dynamic metadata discovery.  Replying to
> Justin=E2=80=99s comment that =E2=80=9CIt's the pre-configured discovery =
document that's
> at the root of the mix-up attack in the first place=E2=80=9D =E2=80=93 th=
is is not the
> case.  The attacks can be performed without either discovery or dynamic
> registration.
>
>
>
> I would be interested in hearing a technical discussion on whether there
> are aspects of the oauth-meta approach that mitigate aspects of the attac=
ks
> that the mix-up-mitigation approach does not.  That could help inform
> whether there are additional things we should add to or change in the
> mix-up draft.
>
>
>
>                                                           -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William
> Denniss
> *Sent:* Wednesday, January 20, 2016 10:37 PM
> *To:* Justin Richer 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>
> +1 to adopt this, and I agree with Justin's comments.
>
>
>
> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer  wrote:
>
> +1
>
> Inline discovery and pre-configured discovery (ie, .well-known) should at
> the very least be compatible and developed together. It's the
> pre-configured discovery document that's at the root of the mix-up attack
> in the first place.
>
>  -- Justin
>
>
>
> On 1/19/2016 10:30 PM, Nat Sakimura wrote:
>
> Just to give more context, at IETF 94, I have done a presentation on
> discovery.
>
>
>
> According to the minutes,
>
>
>
>     (f) Discovery (Nat)
>
>
>
>              Nat explains his document as an example of the work that has=
 to be done
>
>              in the area of discovery, which is a topic that has been ide=
ntified
>
>              as necessary for interoperability since many years but so fa=
r there
>
>              was not time to work on it. Mike, John and Nat are working o=
n a new
>
>              document that describes additional discovery-relevant compon=
ents.
>
>
>
>              Poll: 19 for / zero against / 4 persons need more informatio=
n.
>
>
>
> The document discussed there was
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
> simple (only 1-page!) but a very powerful document that nudges towards
> HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-u=
p
> attack without introducing the concept of issuer which is not in RFC6749.
> It is also good for selecting different endpoints depending on the user
> authentication and authorization results and more privacy sensitive than
> pre-announced Discovery document. It also allows you to find to which
> protected resource endpoint you can use the access token against.
>
>
>
> In the last sentence of the minutes, it talks about "a new document that
> describes additional discovery-relevant components". This is
> https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went for
> the call for adoption. However, it is only a half of the story. I believe
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was
> discussed at IETF 94 and had support there should be adopted as well.
>
>
>
> Nat Sakimura
>
>
>
>
>
>
>
>
>
> 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura :
>
> Thanks Hannes.
>
>
>
> I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, =
which
> was discussed in Yokohama, and was largely in agreement if my recollectio=
n
> is correct. Why is it not in the call for adoption?
>
>
>
>
>
>
>
> 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig :
>
> Hi all,
>
> we have submitted our new charter to the IESG (see
> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
> since some IESG members like to see an updated list of milestones as
> well. For this reason, based on a suggestion from Barry, we are also
> starting a call for adoption concurrently with the review of the charter
> text by the IESG.
>
> We will post separate mails on the individual documents. Your feedback
> is important! Please take the time to look at the documents and provide
> your feedback.
>
> Ciao
> Hannes & Derek
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

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


I wrote a blog on why the current mix-up draft approach do=
es not solve the issue.=C2=A0

http://nat.=
sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
<=
/div>

Hopefully, the point I am making is clearer by thi=
s.=C2=A0

Best,=C2=A0

Nat<=
/div>

2016=E5=B9=B41=
=E6=9C=8823=E6=97=A5(=E5=9C=9F) 8:32 Mike Jones <Michael.Jones@microsoft.com>:











I like the =E2=80=9Cfrom which=
 the authorization server's configuration information location can be d=
erived=E2=80=9D
 language.=C2=A0 Thanks.=C2=A0 I=E2=80=99ll plan to incorporate that the ne=
xt time the draft is revised.


=C2=A0


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


=C2=A0


From: Brian Campbell [mailto:bcampbell@pingiden=
tity.com]


Sent: Friday, January 22, 2016 3:26 PM

To: Nat Sakimura <sakimura@gmail.com>

Cc: Mike Jones <Michael.Jones@microsoft.com>; Justin Richer <jricher@mit.edu>; &=
lt;oauth@ietf.org&g=
t; <oauth@ietf.org>


=C2=A0




I agree that the lang=
uage describing OAuth issuer could and should be improved. The text now rea=
ds like it is the exact and full URL where the metadata/discovery document =
is located. Perhaps something more like
 "the URL from which the authorization server's configuration info=
rmation location can be derived" and explain that adding the .well-kno=
wn bits to the issuer is where the configuration information can actually b=
e found.










=C2=A0




On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura <sakimura@gmail.com> wrote:






Re: iss. I discussed this a bit with Nov in more det=
ails. It probably is a sloppy language of the specs that is making it diffi=
cult to read what you wanted to achieve.=C2=A0




=C2=A0







In mix-up-mitigation draft, OAuth issuer is "the URL of t=
he authorization server's configuration information location". In =
OAuth discovery draft, there is something called "OAuth 2.0
 Configuration Information Location URL", which is equal to "Open=
ID Connect Issuer".=C2=A0



When I wrote the statement, I thought you were pointing to the=
 URL that you can actually pull the configuration information by "the =
URL of the authorizaiton server's configuration information
 location" since otherwise you would have used the term "OAuth 2.=
0 Configuration Information Location URL". But after all, you probably=
 meant these two are the same. Then I would strongly recommend to fix the l=
anguage.=C2=A0



Now, even If that is the case, the relationship like=C2=A0<=
/u>



=C2=B7=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
iss + .well-know/openid-configurat=
ion =3D Connect OP config endoint



=C2=B7=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
OAuth config endpoint - .well-know=
n/openid-configuration =3D OAuth iss




is very confusing.=C2=A0<=
u>








=C2=A0






You also claim that your approach is si=
mpler, but to me, your approach seem to be overly complex. It requires disc=
overy and the check for the value of the discovered
 config information to work as the mitigation. (Right. Draft -01 does not h=
ave it, so it does not solve the mix-up issue.) With oauth-meta, you do not=
 need it.=C2=A0






=C2=A0






Finally, your point that HATEOAS remind=
s you of WSDL, it is not. If you want to have something similar to WSDL in =
REST API area, it is Swagger. (Actually, it is
 gaining a lot of momentum recently, but that's beside the fact ;-). An=
d the point here is not the format but the fact that we need to have a way =
to associate metadata to the data. The root cause of this mix-up attack is =
that the metadata and data is not associated
 properly. We have a standard way of associating the data and metadata with=
 link-rel such as RFC5988 so why not use it? Link-rel-href pattern is used =
a lot now. Most modern web pages actually have it. Using a proper way to as=
sociate metadata with data will
 save you from a lot of other attacks in the future. Instead of doing patch=
 works, we should solve it=C2=A0architecturally.=C2=A0=







=C2=A0






Nat






=C2=A0






=C2=A0






=C2=A0















Nat, I=E2=80=99m confused by this sta=
tement in the message you reference =E2=80=9CUnfortunately,
 this does not match the value of OAuth issuer defined in Section 2 of=C2=
=A0draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as=
 specified in 3.1.=C2=A0As such, validation as specified in bullet 1 of Sec=
tion 4 fails in Google's case -- OR it means that the
 document is internally inconsistent.=E2=80=9D.=C2=A0=
 The issuer definition in draft-jones-oauth-discovery is 100% compatible wi=
th the one in OpenID Connect Discovery, by design.=C2=A0 In the
 Google example, both the OpenID issuer and the OAuth issuer values would b=
e the string =E2=80=9Chttps://accounts.google.com=E2=80=9D.=C2=A0 What is the inconsiste=
ncy that you perceive?


=C2=A0


The discussion of the duplication pro=
blem happened in the private meetings in Yokohama.


=C2=A0


I will admit, in Yokohama, I didn=E2=
=80=99t speak up in the public meetings to point out that a simpler alterna=
tive
 to oauth-meta was already being discussed there in private, because then I=
 would have had to talk about the security issues, which we=E2=80=99d decid=
ed not to publicly do at that point.=C2=A0 So I stayed silent during the po=
ll, out of politeness.=C2=A0 Perhaps I should have
 found a way to say something then anyway, but that=E2=80=99s water under t=
he bridge now.


=C2=A0


Finally, for what it=E2=80=99s worth,=
 the HATEOAS stuff reminds me far too much of Web Services Description
 Language (WSDL) =E2=80=93 part of the complexity baggage that helped sink =
Web Services.=C2=A0 The use of =E2=80=9Clink rel=E2=80=9D to define an inte=
raction vocabulary and publish endpoints for that vocabulary seems pretty b=
aroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=93 another =
cute =E2=80=9CWebby=E2=80=9D
 innovation that never caught on.=C2=A0 The industry has pretty much voted =
with its feet and is using JSON for publishing discovery data structures =
=E2=80=93 not =E2=80=9Clink rel=E2=80=9D.=C2=A0 I am against us reverting t=
o the =E2=80=9Clink rel=E2=80=9D proposal from 2008 that never caught on wh=
en JSON is
 simpler and does a better job.


=C2=A0


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


=C2=A0


From: Nat Sakimura [mailto:sakimura@gmail.com]


Sent: Thursday, January 21, 2016 6:24 AM

To: Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>
Cc: William Denniss <wdenniss@google.com>; <oauth@ietf.org> <oauth@ietf.org>












Subject: Re: [OAUTH-WG] Call for Adoption










=C2=A0




Mike,=C2=A0




=C2=A0






You just criticize my draft. That's ok, but I wo=
uld really like to get some response to my questions stated in=C2=A0https://www.ietf.org/mail-archive/web/oauth/current/msg15483.=
html=C2=A0.
 To me, it just does not seem to work, and the combination of the oauth-met=
a and PKCE seems to be much more elegan, nicer, and much simpler to impleme=
nt. If you just give up the dynamic response at the authorization endpoint,=
 then you even do not have to touch
 the code but just change a config file.=C2=A0






=C2=A0






Please convince me by answering to my questions.=C2=
=A0






=C2=A0






For the record of Yokohama, I do not recall much abo=
ut duplication in OAuth session. The poll in the room was=C2=A019 for / zero against / 4
 persons need more information. Indeed, it is not duplicating much. And if =
you move to a new model without pre-configured discovery, it is not duplica=
ting any but the resource endpoint URI, which is optional and is for the ca=
ses where the client did not know
 the concrete resource endpoint to start with.=C2=A0





=C2=A0






I unders=
tand your usecases always start from a concrete endpoint location. Mine do =
not. In a four party model, it is likely not. The user
 just want to have the service to fetch his data from some resource endpoin=
t. He just hits the service. He does not hit the resource endpoint directly=
. For example, in the case of a consumer using a personal finance platform =
(PFP)to manage his pension fund,
 he hits the PFP and not the Pension fund. Assuming that the pension fund h=
as delegated the authorization control to the authorization server, then, t=
he authorization server should return both the access token and the endpoin=
t of the pension fund so that the
 PFP can pull the data using them. A similar model holds for personal healt=
h service and health care providers.=C2=A0






=C2=A0






Best,=C2=
=A0






=C2=A0






Nat






=C2=A0






=C2=A0






2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
 21:18 Justin Richer <jricher@mit.edu>:








Convergence is exactly what I=E2=80=99m arguing for,=
 though. These things ought to work together.








=C2=A0






=C2=A0=E2=80=94 Justin










=C2=A0








On Jan 21, 2016, at 2:55 AM, Mike Jones <Michael.Jones@mic=
rosoft.com> wrote:




=C2=A0








My memory of the discussions of the o=
auth-meta draft in Yokohama were that many people felt that it
 was unnecessarily dynamically duplicating a lot of information that the cl=
ient already had.=C2=A0 Most of us that were aware of the attacks then were=
 in favor of a more targeted, minimal approach.=C2=A0 You were listened to =
in Yokohama, but that didn=E2=80=99t necessarily mean
 that people agreed with the approach.=C2=A0 Participants were already awar=
e of the oauth-meta proposal in Darmstadt but no one spoke up in favor of i=
t that I can recall.=C2=A0 Rather, I think people were thinking that =E2=80=
=9Cless is more=E2=80=9D.


=C2=A0


There have also been discussions in t=
he last day about how dynamically returning a resource URL, which
 oauth-meta does, is both unnecessary (since the client initiated the resou=
rce authorization already knowing what resource it wants to access) and oft=
en problematic, since many authorization servers can authorize access to mu=
ltiple resources.=C2=A0 If anything,
 the client should be telling the authorization server what resource it wan=
ts to access =E2=80=93 not the other way around.


=C2=A0


I=E2=80=99m not saying that there are=
n=E2=80=99t some good ideas in the oauth-meta draft =E2=80=93 I=E2=80=99m s=
ure there are, just
 as there are in the approach designed by the participants in Darmstadt.=C2=
=A0 While I volunteered to write the first draft of the mix-up-mitigation a=
pproach, it really reflects something a lot of people have already bought i=
nto =E2=80=93 as evidenced in the passion in
 the high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D threa=
d, and not just my personal project.


=C2=A0


If you think there are things missing=
 or wrong in the mix-up-mitigation draft, please say what they
 are.=C2=A0 That will help us quickly converge on a solution that will work=
 for everyone.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Sincerely,


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


=C2=A0


From: Nat Sakimura [mailto:sakimura@gmail.com]


Sent: Wednesday, January 20, 2016 11:17 PM

To: Mike Jones <Michael.Jones@microsoft.com>; William Denniss <wdenniss@google.com<=
/a>>; Justin Richer <jricher@mit.edu>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Call for Adoption


=C2=A0




Hi Mike.=C2=A0




=C2=A0






Conversely, I would like to ask why this approach do=
es not work for Mix-up attack.=C2=A0As Nov stated, we in fact have discusse=
d the approach in quite a length back in Yokohama. I really
 would like to know why it does not work.=C2=A0






=C2=A0






Besides, for oauth-meta approach, mix-up attack is o=
nly one of the thing it solves.=C2=A0






=C2=A0






Nat Sakimura






=C2=A0






2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
 16:02 Mike Jones <Michael.Jones@microsoft.com>:










Not to be negative, but I disagree wi=
th adopting draft-sakimura-oauth-meta.=C2=A0 We should define and promote
 one mitigation approach to the mix-up attacks.=C2=A0 Having two would conf=
use implementers and cause compatibility problems =E2=80=93 reducing overal=
l security.


=C2=A0


The approach defined in draft-jones-o=
auth-mix-up-mitigation was created in collaboration with the security
 researchers who identified the problems in the first place, was vigorously=
 discussed in the security meeting Hannes and Torsten held in Darmstadt, an=
d has been since refined based on substantial input from the working group.=
=C2=A0 And at least three implementers
 have already stated that they=E2=80=99ve implemented it.=C2=A0 I=E2=80=99m=
 not saying that it=E2=80=99s, but if there are things missing or things th=
at need to be improved in our approach, we should do it there, rather intro=
ducing a competing approach.


=C2=A0


Also, standard OAuth deployments regi=
ster the client and then use the information gathered at registration
 time for subsequent protocol interactions.=C2=A0 They do not need all the =
configuration information for the authorization server to be retransmitted =
at runtime.=C2=A0 The oauth-meta draft goes too far in that direction, at l=
east as I see it.=C2=A0 Returning things two ways
 creates its own problems, as discussed in the Duplicate Information Attack=
s security considerations section (7.2) of the mix-up-mitigation draft.


=C2=A0


I=E2=80=99ll note that the mix-up-mit=
igation approach is compatible with existing practice in both static and
 dynamic metadata discovery.=C2=A0 Replying to Justin=E2=80=99s comment tha=
t =E2=80=9CIt's the pre-configured discovery document that's=
 at the root of the mix-up attack in the first place=E2=80=
=9D =E2=80=93 this
 is not the case.=C2=A0 The attacks can be performed without either discove=
ry or dynamic registration.


=C2=A0


I would be interested in hearing a te=
chnical discussion on whether there are aspects of the oauth-meta
 approach that mitigate aspects of the attacks that the mix-up-mitigation a=
pproach does not.=C2=A0 That could help inform whether there are additional=
 things we should add to or change in the mix-up draft.


=C2=A0


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


=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of William Denniss

Sent: Wednesday, January 20, 2016 10:37 PM

To: Justin Richer <jricher@mit.edu>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Call for Adoption










=C2=A0




+1 to adopt this, and I agree with Justin's comm=
ents.




=C2=A0




On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer <<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>=
 wrote:






+1



Inline discovery and pre-configured discovery (ie, .well-known) should at t=
he very least be compatible and developed together. It's the pre-config=
ured discovery document that's at the root of the mix-up attack in the =
first place.



=C2=A0-- Justin






=C2=A0<=
/p>



On 1/19/2016 10:30 PM, Nat Sakimura wrote:=









Just to give more context, at IETF 94, I have done a=
 presentation on discovery.=C2=A0





=C2=A0






According to the minutes,=C2=A0






=C2=A0






=C2=A0=C2=A0=C2=A0 (f) Discovery (Nat)=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Nat explains his document as an e=
xample of the work that has to be done


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the area of discovery, which is a t=
opic that has been identified


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as necessary for interoperability sinc=
e many years but so far there


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was not time to work on it. Mike, John=
 and Nat are working on a new


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document that describes additional dis=
covery-relevant components.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Poll: 19 for / zero against / 4 p=
ersons need more information.


=C2=A0


The document discussed there was

https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a sim=
ple (only 1-page!) but a very powerful document that nudges towards HATEOAS=
 which is at the core of RESTful-ness. It also mitigates the Mix-up attack =
without introducing the concept
 of issuer which is not in RFC6749. It is also good for selecting different=
 endpoints depending on the user authentication and authorization results a=
nd more privacy sensitive than pre-announced Discovery document. It also al=
lows you to find to which protected
 resource endpoint you can use the access token against.=C2=A0






=C2=A0




In the last sentence of the minutes, it talks about =
"a new document that describes additional discovery-relevant component=
s". This is=C2=A0https://tools.ietf.org/html/draft-jones=
-oauth-discovery-00.=C2=A0
 It went for the call for adoption. However, it is only a half of the story=
. I believe=C2=A0https://tools.ietf.org/html/draft-sakimura-oau=
th-meta-05=C2=A0that was discussed at IETF
 94 and had support there=C2=A0should be adopted as well.=C2=A0 <=
/u>




=C2=A0






Nat Sakimura




=C2=A0






=C2=A0






=C2=A0








=C2=A0






2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4)
 12:05 Nat Sakimura <sakimura@gmail.com>:








Thanks Hannes.=C2=A0





=C2=A0






I did not find=C2=A0https://tools.ietf.o=
rg/html/draft-sakimura-oauth-meta-05,=C2=A0which was discussed
 in Yokohama, and was largely in agreement if my recollection is correct. W=
hy is it not in the call for adoption?=C2=A0






=C2=A0






=C2=A0






=C2=A0






2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB)
 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:










Hi all,



we have submitted our new charter to the IESG (see

http://www.ietf.org/mail-archive/web/oauth/current/msg1=
5379.html) and

since some IESG members like to see an updated list of milestones as

well. For this reason, based on a suggestion from Barry, we are also

starting a call for adoption concurrently with the review of the charter
text by the IESG.



We will post separate mails on the individual documents. Your feedback

is important! Please take the time to look at the documents and provide

your feedback.



Ciao

Hannes & Derek



_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth










=C2=A0<=
/p>

_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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




=C2=A0










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth






=C2=A0










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth
















=C2=A0
























_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth






=C2=A0






--001a114a7d20c730a30529f64304--


From nobody Fri Jan 22 19:19:46 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E73CF1B303C for ; Fri, 22 Jan 2016 19:19:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QMsOsZbSEhL for ; Fri, 22 Jan 2016 19:19:42 -0800 (PST)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 7320C1B3023 for ; Fri, 22 Jan 2016 19:19:42 -0800 (PST)
Received: by mail-qg0-x22f.google.com with SMTP id 6so72050081qgy.1 for ; Fri, 22 Jan 2016 19:19:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=k/UGvKByJJVWcxoD/BSPvHusfgXHCJJ3SaaJ+Hg2CAs=; b=nR6IznrJUs+RUvJ2QkN3FxbJ/mxvqaps+WQZ9WFgQgvN3fnZmFqWFDibecJgT77zzc rEuthub4a2XvoNZdPddlAGfZQ2U+0gsfetQBuRUUpPFBHg7JlNBrTn6KL2GvyWD5MVUf 9ywqE86NQuDlD44zVCUO8M33WBfz+O5U4DR82CungQBieGGzXl9wSL/3c+98avYQzKVp 59gKThYcx4gDQdQA0RObuEjjJ4/4XH8r36Tg5UmxIl118+hnqT8a72vzu1tv+ZdzDpAu /C7G/b+qO/iU34Fk+TZTr7ARWzmKUMgMf+abhGrr998sHkUXbKW2L3tEcRyyj6euIZGc LhiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=k/UGvKByJJVWcxoD/BSPvHusfgXHCJJ3SaaJ+Hg2CAs=; b=DZXlxcnd/Ldm3O8qiyczfwAC+ndtpEbemb4428MDuotH1xjQMChXofhHsDon/bKmdX c9mfCqjD9yJdfaS8Rs2XleeiibrnTJjdbH99QOqna0/MCAujKpXQn8DbEORGWArT1Iv0 xq++F8SemgP8ghXJk50xmbvpcPEPyIUDxxeqZJgvcz8EChvqk4k1Wpdqs9J2bodzZjf6 oXreTyE8fpgArM6epWS1YoaWH5lv2/q5xfvtDrtzLSF+VecKjIawaFqDP1WR7peRG1zQ xNtK8AB9/a2H5YVZi9zBZCH7vwNCUgHFjoovLxiU4Q2ayiyLrq4bw7O9BEvlnfqBt2lG VTbA==
X-Gm-Message-State: AG10YORhGsxF3297GZlcWc1Q2QlFyfQzqI+NSXzTzBIzwgPVB7Jfig2RqZGuM8GvTKUqFS+waKadFAwwrYz9JQ==
X-Received: by 10.140.152.18 with SMTP id 18mr8154885qhy.16.1453519181661; Fri, 22 Jan 2016 19:19:41 -0800 (PST)
MIME-Version: 1.0
References:   <0E094321-8A8A-4D94-8BE9-27D49BC6572F@ve7jtb.com> 
In-Reply-To: 
From: Nat Sakimura 
Date: Sat, 23 Jan 2016 03:19:31 +0000
Message-ID: 
To: Chuck Mortimore , John Bradley 
Content-Type: multipart/alternative; boundary=001a1135a2a07f4d850529f7cef3
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Google's OAuth endpoints now fully support PKCE (RFC7636)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2016 03:19:45 -0000

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

That's a great news.
Thanks so much for sharing.

Nat
2016=E5=B9=B41=E6=9C=8823=E6=97=A5(=E5=9C=9F) 9:43 Chuck Mortimore :

> Thanks - we'll fail if the client defaults to plain, as we didn't
> implement.    Will take a look in the future though.
>
> I am curious if an implementing client can move back and forth between
> Salesforce and Google implementations.    If someone tries, please let us
> know!
>
> On Fri, Jan 22, 2016 at 4:21 PM, John Bradley  wrote:
>
>> In the final spec plain is not MTI.  S256 is MTI for the server in Sec
>> 4.2. so you are OK.
>>
>> The client will default to plain if it doesn=E2=80=99t set a
>> code_challenge_method.
>>
>> That was to be backwards compatible with the people who deployed when
>> plain was the only option.
>>
>> John B.
>>
>> On Jan 22, 2016, at 8:45 PM, Chuck Mortimore 
>> wrote:
>>
>> We quietly rolled out PKCE support at Salesforce a year ago, as well.
>> We're on a slightly earlier draft, but look to be compliant with final R=
FC
>> with one exception - we default to S256, and do not have support for "pl=
ain"
>>
>> Would be interesting to interop test our deployments.
>>
>> -cmort
>>
>> On Mon, Jan 18, 2016 at 9:46 PM, William Denniss 
>> wrote:
>>
>>> This month we rolled out full PKCE (RFC7636) support on our OAuth
>>> endpoints.
>>>
>>> We'd previously implemented an earlier draft but were not conformant to
>>> the final spec when it was published =E2=80=93 now we are. Both "plain"=
 and "S256"
>>> transforms are supported. As always, get the latest endpoints from our
>>> discovery document:
>>> https://accounts.google.com/.well-known/openid-configuration
>>>
>>> If you give it a spin, let me know how you go! The team monitors the
>>> Stack Overflow google-oauth
>>>  tag too, for
>>> any implementation questions.
>>>
>>> I'm keen to know what we should be putting in our discovery doc to
>>> declare PKCE support (see the thread "Advertise PKCE support in OAuth 2=
.0
>>> Discovery"), hope we can agree on that soon.
>>>
>>> One implementation detail not covered in the spec: we error if you
>>> send code_verifier to the token endpoint when exchanging a code that wa=
s
>>> issued without a code_challenge being present. The assumption being tha=
t if
>>> you are sending code_verifier on the token exchange, you are using PKCE=
 and
>>> should have sent code_challenge on the authorization request, so someth=
ing
>>> is amiss.
>>>
>>> William
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>

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

That's a great news. 
Thanks so much for sharing. 

Nat
2016=E5=B9=B41=E6=9C=8823=E6=97=A5=
(=E5=9C=9F) 9:43 Chuck Mortimore <cmortimore@salesforce.com>:
Thanks - we'll fail if the client defaults to p=
lain, as we didn't implement. =C2=A0 =C2=A0Will take a look in the futu=
re though. =C2=A0 =C2=A0=C2=A0

I am curious if an implem=
enting client can move back and forth between Salesforce and Google impleme=
ntations. =C2=A0 =C2=A0If someone tries, please let us know!

On Fri, Jan 22, 2016=
 at 4:21 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
In the final=
 spec plain is not MTI.=C2=A0 S256 is MTI for the server in Sec 4.2. so you=
 are OK.

The client will default to plain if it doesn=E2=
=80=99t set a code_challenge_method.

That was to b=
e backwards compatible with the people who deployed when plain was the only=
 option.

John B.

On Jan 22, 2016, at 8:45 PM, Chuck Mortimore <cmortimore@salesforce.=
com> wrote:

We quietly rolled out PKC=
E support at Salesforce a year ago, as well. =C2=A0 We're on a slightly=
 earlier draft, but look to be compliant with final RFC with one exception =
- we default to S256, and do not have support for "plain"
Would be interesting to interop test our deployments.

-cmort

On Mon, Jan 18, 2016 at 9:46 PM, William Denniss <wdenn=
iss@google.com> wrote:
This month we rolled out full PKCE (RFC7636) support on our OAuth endpoint=
s.

We'd previously implemented an earlier draf=
t but were not conformant to the final spec when it was published =E2=80=93=
 now we are. Both "plain" and "S256" transforms are sup=
ported. As always, get the latest endpoints from our discovery document:=C2=
=A0https://accounts.google.com/.well-known/openid-configura=
tion

If you give it a spin, let me know how yo=
u go! The team monitors the Stack Overflow=C2=A0google-oauth=
=C2=A0tag=C2=A0too, for any implementation questions.

I=
'm keen to know what we should be putting in our discovery doc to decla=
re PKCE support (see the thread "Advertise PKCE support in OAuth 2.0 D=
iscovery"), hope we can agree on that soon.

One imp=
lementation detail not covered in the spec: we error if you send=C2=A0code_=
verifier=C2=A0to the token endpoint when exchanging a code that was issued =
without a code_challenge being present. The assumption being that if you ar=
e sending code_verifier on the token exchange, you are using PKCE and shoul=
d have sent code_challenge on the authorization request, so something is am=
iss.

William






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




_______________________________________________
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



--001a1135a2a07f4d850529f7cef3--


From nobody Sat Jan 23 07:27:02 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B821B3808 for ; Sat, 23 Jan 2016 07:27:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Level: 
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qhGhPnX7Pog for ; Sat, 23 Jan 2016 07:26:58 -0800 (PST)
Received: from smtp5.umu.se (smtp5.umu.se [130.239.8.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7936F1B3806 for ; Sat, 23 Jan 2016 07:26:57 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.22,336,1449529200";  d="asc'?scan'208";a="84976457"
X-IPAS-Result: A2DLBABbm6NW/8wN74JVBgMZAQEBAQ8BAQEBgl99ZwYGiFGhfZFzAgUYCoVtAoF4AQEBAQEBgQuEQQEBAQECAQEBASBLCwUJAgIBCA4KKgICFhELJQIEDgUODQSHZwMKCAEDBQWuYI5sAQEBAQEBAQEBAQEBAQEBAQEBAQEBDQgEhi6CBIJpgkmBWUodCYI6K4EPBY0qiUyCeYFjaoluSoxRhn4Qg16DU2KCABmBUGqGQAF7AQEB
Received: from umu-ex04.ad.umu.se (HELO mail.ad.umu.se) ([130.239.13.204]) by smtp5.umu.se with ESMTP; 23 Jan 2016 16:26:55 +0100
Received: from UMU-EX03.ad.umu.se (2002:82ef:dcb::82ef:dcb) by UMU-EX04.ad.umu.se (2002:82ef:dcc::82ef:dcc) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sat, 23 Jan 2016 16:26:55 +0100
Received: from UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133]) by UMU-EX03.ad.umu.se ([fe80::708f:f02f:c850:d133%24]) with mapi id 15.00.1130.005; Sat, 23 Jan 2016 16:26:55 +0100
From: Roland Hedberg 
To: George Fletcher 
Thread-Topic: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
Thread-Index: AQHRVfJ98RjUiO7nzkSUebkgHeTEdQ==
Date: Sat, 23 Jan 2016 15:26:54 +0000
Message-ID: <37CB7306-9AA9-4B5D-9EAD-5A803D52C044@adm.umu.se>
References:  <2EB9855D-BAB2-4B90-B649-F1B24B8834EC@alkaline-solutions.com>  <80218A07-9D37-42A3-B90A-56AEDBC3A86C@alkaline-solutions.com>   <56A260B6.4060302@aol.com> <478C8683-0E47-43E7-A7F3-75F89AB1DCDA@alkaline-solutions.com>  <56A27C3E.2070301@gmail.com> <56A27D8A.3040804@aol.com>
In-Reply-To: <56A27D8A.3040804@aol.com>
Accept-Language: en-US, sv-SE
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-pgp-agent: GPGMail 2.5.2
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [31.208.6.237]
Content-Type: multipart/signed; boundary="Apple-Mail=_F562AFB4-1E14-4C84-A7C9-EA2829956ED1"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: 
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2016 15:27:01 -0000

--Apple-Mail=_F562AFB4-1E14-4C84-A7C9-EA2829956ED1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1  :-)

> 22 jan 2016 kl. 20:05 skrev George Fletcher :
>=20
> Isn't that your department Paul? I have high expectations!
>=20
> On 1/22/16 2:00 PM, Paul Madsen wrote:
>> tshirt or it didnt happen
>>=20
>> On 1/22/16 1:57 PM, John Bradley wrote:
>>> Now that we have a cool name all we need is a logo for the attack =
and per haps an anime character, and we are done with all the hard =
work:)
>>>=20
>>> John B.
>>>> On Jan 22, 2016, at 2:54 PM, David Waite =
 wrote:
>>>>=20
>>>> It=E2=80=99s pronounced FronkenSTEEN-ian.
>>>>=20
>>>> -DW
>>>>=20
>>>>> On Jan 22, 2016, at 10:02 AM, George Fletcher  =
wrote:
>>>>>=20
>>>>> "Frankensteinian Amalgamation" -- David Waite
>>>>>=20
>>>>> I like it! :)
>>>>>=20
>>>>> On 1/22/16 8:11 AM, William Denniss wrote:
>>>>>> +1 ;)
>>>>>> On Fri, Jan 22, 2016 at 8:45 PM John Bradley  =
wrote:
>>>>>> Perhaps Frankenstein response is a better name than cut and paste =
attack.
>>>>>>=20
>>>>>> John B.
>>>>>>=20
>>>>>> On Jan 22, 2016 1:22 AM, "David Waite" =
 wrote:
>>>>>>> On Jan 21, 2016, at 2:50 PM, John Bradley  =
wrote:
>>>>>>>=20
>>>>>>> In that case you probably would put a hash of the state in the =
code to manage size.  The alg would be up to the AS, as long as it used =
the same hash both places it would work.
>>>>>> Yes, true.
>>>>>>>=20
>>>>>>> Sending the state to the token endpoint is like having nonce and =
c_hash in the id_token, it binds the issued code to the browser =
instance.
>>>>>> I think I understand what you are saying. Someone won=E2=80=99t =
be able to frankenstein up a state and a token from two different =
responses from an AS, and have a client successfully fetch an access =
token based on the amalgamation.
>>>>>>=20
>>>>>>> This protects against codes that leak via redirect uri pattern =
matching. failures etc.  It prevents an attacker from being able to =
replay a code from a different browser.
>>>>>> Yes, if a party intercepts the redirect_url, or the AS fails to =
enforce one time use (which even for a compliant implementation could =
just mean the attacker was faster than the state propagated within the =
AS)
>>>>>>=20
>>>>>> Makes sense. Thanks John.
>>>>>>=20
>>>>>> -DW
>>>>>>=20
>>>>>>> If the client implements the other mitigations on the =
authorization endpoint, then it wouldn't be leaking the code via the =
token endpoint.
>>>>>>>=20
>>>>>>> The two mitigations are for different attacks, however some of =
the attacks combined both vulnerabilities.
>>>>>>>=20
>>>>>>> Sending the iss and client_id is enough to stop the confused =
client attacks, but sending state on its own would not have stopped all =
of them.
>>>>>>>=20
>>>>>>> We discussed having them in separate drafts, and may still do =
that.   However for discussion having them in one document is I think =
better in the short run.
>>>>>>>=20
>>>>>>> John B.
>>>>>>>=20
>>>>>>>> On Jan 21, 2016, at 4:48 PM, David Waite =
 wrote:
>>>>>>>>=20
>>>>>>>> Question:
>>>>>>>>=20
>>>>>>>> I understand how =E2=80=9Ciss" helps mitigate this attack =
(client knows response was from the appropriate issuer and not an attack =
where the request was answered by another issuer).
>>>>>>>>=20
>>>>>>>> However, how does passing =E2=80=9Cstate=E2=80=9D on the =
authorization_code grant token request help once you have the above in =
place? Is this against some alternate flow of this attack I don=E2=80=99t =
see, or is it meant to mitigate some entirely separate attack?
>>>>>>>>=20
>>>>>>>> If one is attempting to work statelessly (e.g. your =E2=80=9Cstat=
e=E2=80=9D parameter is actual state and not just a randomly generated =
value), a client would have always needed some way to differentiate =
which issuer the authorization_code                                      =
                     grant token request would be sent to.
>>>>>>>>=20
>>>>>>>> However, if an AS was treating =E2=80=9Ccode=E2=80=9D as a =
token (for instance, encoding: client, user, consent time and approved   =
                                                        scopes), the AS =
now has to include the client=E2=80=99s state as well. This would =
effectively double (likely more with encoding) the state sent in the =
authorization response back to the client redirect URL, adding more =
pressure against maximum URL sizes.
>>>>>>>>=20
>>>>>>>> -DW
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>=20
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>>=20
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>=20
>>>>> --
>>>>> Chief Architect
>>>>> Identity Services Engineering     Work:
>>>>> george.fletcher@teamaol.com
>>>>>=20
>>>>> AOL Inc.                          AIM:  gffletch
>>>>> Mobile: +1-703-462-3494           Twitter:
>>>>> http://twitter.com/gffletch
>>>>>=20
>>>>> Office: +1-703-265-2544           Photos:
>>>>> http://georgefletcher.photography
>>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>>=20
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>>=20
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> --
> Chief Architect
> Identity Services Engineering     Work:
> george.fletcher@teamaol.com
>=20
> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter:
> http://twitter.com/gffletch
>=20
> Office: +1-703-265-2544           Photos:
> http://georgefletcher.photography
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_F562AFB4-1E14-4C84-A7C9-EA2829956ED1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWo5u9AAoJEMHjX+0KUIOolO4P/R+WGixX//kE8FbSfGTxbs0+
aU/kLKqJGYK5bF2o/GF3T6cy8tCp2SQnnz3fbQLB36RS4p/9+eKhSOk3s5uZenKB
bcLoanJO3cruwIJy0sMj/r8efr8Nc1YsUGBn22qTIEMuhniSWGFOw6EP2TKSLyoN
D9UMfwmSSc96zkG274UHlEvDzxbMQl2mDTvOq11JfzCGFQp3DCRinNAdxvpDKEUp
LyKrBqxtPAORPM3tu+3EBBBExUcwxMoavtxSRNI1MJBJV22axZW6Ve2gpHPPWzhA
6SV/v8/Qd1rNI/MsXyrHGSkedJzuQ1gSr+p71Pl67Xz0myzDWGjFxe4cneUJPqDI
VsN13huHJ/f3oi28B3q7o6LFTkhBH63dWqdPo7aiXg2OslRd6RqV1M633XEhXiXW
9D5qb7wd0j++ssp5RUBzwdqP4PdSKFlmV/ArHWN63FraRce5VIGbh4Q3H4vTqQG6
4XanfNwa9tyDiu0XENNqEL6M1WpuZvdbY0V59ag8iP/r3DuxEZO7a+dZc/muB+Kt
n72Zaw/10xUbFXPuEw1MK13yWzzjfWeLY3Z5H1Iz3sDjuJwdLVGuULkzzeXFvmWb
NVdyYo03B/u6NHounJ+GwP2rWMLexwB8NNRwDUYCc6IMxq0p9LoNaZmLf48QHScO
35inBOkSSBekfnveFIpF
=+fCH
-----END PGP SIGNATURE-----

--Apple-Mail=_F562AFB4-1E14-4C84-A7C9-EA2829956ED1--


From nobody Sat Jan 23 14:53:06 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAB71B2A88 for ; Sat, 23 Jan 2016 14:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2KsNd3VcgJQ for ; Sat, 23 Jan 2016 14:52:59 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3938F1B2A87 for ; Sat, 23 Jan 2016 14:52:59 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id s68so42038175qkh.3 for ; Sat, 23 Jan 2016 14:52:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=oR2ihx5y13G1kuPjx3HCJb6i4lUaDabgC+VucNxI5gE=; b=PmFdKG30dT82MMC+QOU/pR1ZpiaoYysA7Y/+8Z5zLr+dgMCCpcjN9NH/O3lMxaQS7+ h+eI7FsBgzk4fbdkh86T/3D559s+jk15T2UyeR8NA4yzRSOOybIxmVnoTeZPDgB6q4u7 YhAnbBCGI6rHw+PzVgmZARGzxRgGycOBnrnvRGyUxvdGaPQT8cAMVLQVY5Nrp/3HJK9B ublXASYNZ17eSSMTprhEA6rHCPiG+mfhQ09ZbvSr9EE35nRIrXucEXZ5IssXrloXM7ch tdn1o5ObRSTkvJTQVjSN92eapZPf11qKq0OvWMojOm9yuUj9/vMlK6w6odAi1yHHeldh 4wxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=oR2ihx5y13G1kuPjx3HCJb6i4lUaDabgC+VucNxI5gE=; b=SRCexw8TQunkYZyrVLV2JQeuTSN1TjMz6pz+GOEVELNyBgysC5ddx68lnAwygAeo4Y blULbZ8yHqw6En85oFd/rVD0Qw8IQKEokaNFCwVnkPSp9+sztL/t66j3pKyuScslZM89 DF9EpO910dIL3sbuBCOvY39o6FJhXbU35u8oKdkNGN3pRFIwy9JMoK2AZxtAN++kMcz9 vt2sf4pRh+zo/XIOeND1y1uETC97JoP+S07QbFBfTiVKiT/hOFiMnqudJ+SUFAv+EM+l wTzmACNlAAJpf7JGq2h+RKLZeP+iNpgi9Nhh2v9jAW5jBaC3GhWbG1VnR04mJehCzk9t 9nwA==
X-Gm-Message-State: AG10YOS1NarvJ+JaxAgA3UtG33PxwEY//Sr/bT991CJw9PP7muNKObzsrks6DYWTSIWiLKtWEI24iOLi0RGWUQ==
X-Received: by 10.55.71.135 with SMTP id u129mr12862787qka.26.1453589578340; Sat, 23 Jan 2016 14:52:58 -0800 (PST)
MIME-Version: 1.0
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.com>  <56A1F249.3020307@pingidentity.com>
In-Reply-To: <56A1F249.3020307@pingidentity.com>
From: Nat Sakimura 
Date: Sat, 23 Jan 2016 22:52:48 +0000
Message-ID: 
To: Hans Zandbelt , Mike Jones , John Bradley 
Content-Type: multipart/alternative; boundary=001a114a7d20776073052a083298
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 23 Jan 2016 22:53:05 -0000

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

Since we have been discussing in another thread and you guys may be a aware
of it in this thread, here is one of the problem statement for the mix-up
draft explaining why it does not solve the problem as it is written now.

It can be fixed to solve the problem, but then the overhead size will be
much larger and involves an extra round trip compared to oauth-meta draft.

See
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc674=
9/
for the details.

Nat
2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 18:11 Hans Zandbelt :

> +1 to everything Mike stated
>
> Hans.
>
> On 1/22/16 2:04 AM, Mike Jones wrote:
> > I believe that it=E2=80=99s simpler and more elegant to return an issue=
r, from
> > which the discovery metadata document can be retrieved, which contains
> > **all** the configuration information about the authorization server,
> > than to return some of the configuration parameters but not most of the=
m
> > (which is what the oauth-meta proposal does).  There=E2=80=99s lots mor=
e in a
> > typical discovery document than just a few endpoint addresses. For
> > instance, there are statements about what response types are supported,
> > other configuration choices, keys, etc.
> >
> > I also think that returning the issuer is more future-proof than trying
> > to decide now what all the configuration information is that might want
> > to be verified by the client and hoping we get it right.  With the
> > issuer, assuming that discovery is supported, it can retrieve and check
> > all of it, should the client want/need to do so.  Even when discovery
> > isn=E2=80=99t supported, the issuer still provides a concrete identifie=
r for the
> > authorization server that can be checked for equality.
> >
> > We talked about the value of that approach in the side meetings in
> > Yokohama and people were supportive then.
> >
> >                                                                  -- Mik=
e
> >
> > *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradle=
y
> > *Sent:* Thursday, January 21, 2016 4:48 PM
> > *To:* Nat Sakimura 
> > *Cc:* oauth@ietf.org WG 
> > *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigatio=
n
> >
> > I will point out for clarification that this would be like IdP discover=
y
> > in openID 2 that everyone did.  I think IdP not doing RP discovery in
> > openID 2 is a weak argument.
> >
> > There may be other evidence that RP will not do discovery, but if that
> > is the case why are we doing a OAuth discovery spec?
> >
> > Many people see your spec as discovery as well just in a different way.
> >
> > I think both ways can work, but doing both leaves too many options.
> >
> > John B.
> >
> >     On Jan 21, 2016, at 9:38 PM, Nat Sakimura  >     > wrote:
> >
> >     Still doing the analysis. We spent 1.5 hours today with John,
> >     George, nov and me on the OpenID Connect WG call on this issue. Joh=
n
> >     explained the mitigation, but none of us was convinced that it work=
s.
> >
> >     Then, after the call, I and nov went on with various scenarios. The
> >     interim conclusion is that:
> >
> >       * client_id response parameter does not help. There are legitimat=
e
> >         cases that client_id duplicates out there and we cannot ban tha=
t.
> >       * iss response parameter does not help unless the discovery is
> >         performed and the value of iss is checked against the value of
> >         OAuth issuer inside the document. (<- Discovery becomes
> >         mandatory. From our experience on RP discovery step in OpenID
> >         2.0, chance of this being done properly seems to be rather slim=
.)
> >       * sending the state to the token endpoint helps in the case code
> >         was stollen, but code should not be stolen to start with.
> >
> >     Cheers,
> >
> >     Nat
> >
> >     2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John Bradley  >     >:
> >
> >         There have been a lot of discussions. I think Hannes posted som=
e
> >         minutes of the F2F meeting we had with the security researchers=
.
> >
> >         The problem can=E2=80=99t be mitigated without some action on t=
he client
> >         side.  It boils down to the client making a request to AS1 (Fro=
m
> >         it=E2=80=99s perspective) and getting back a response from AS 2=
 (that it
> >         thinks is AS1)
> >
> >         This can be done if AS1 is a good AS but has it=E2=80=99s logs
> >         compromised so that an attacker can read them. Hans Zandbelt
> >         built a proof of concept for the attack.
> >
> >         In some cases the attacker gets the code and the credential to
> >         use it at the good AS token endpoint and in others it just gets
> >         the code and can replay that at the client to extract
> >         information from the API through the client by binding the api
> >         access to a new account.
> >
> >         PKCE unfortunately mitigates a different attack, where the
> >         client is impersonated and trys to replay a intercepted code.
> >         It however assumes the token endpoint is good, and is no help i=
n
> >         the case of a compromised token endpoint.
> >
> >         The client in these attacks is vulnerable because it relies on
> >         some local state, or the value of the state parameter to know
> >         who the response is coming from.  This allows a authorization
> >         request that is intercepted to be used to create a new request
> >         in that browser to a different AS, or trick the client into
> >         using a Authorization endpoint for a different authorization
> server.
> >
> >         One problem is that OAuth doesn=E2=80=99t really have a unified=
 concept
> >         of what a AS is.  Traditionally it is a Authorization endpoint
> >         URI, token end point URI and resource server URI that some one
> >         gives the client in some documentation.
> >
> >         As ling as a client only talks to one AS then there is no
> >         problem.   However once a client is configured to talk to more
> >         than one AS, we have problems if one of those AS lies about it=
=E2=80=99s
> >         endpoints, or is compromised and used to attack another AS.   A=
s
> >         a design goal you don=E2=80=99t want the overall  security to b=
e limited
> >         by the weakest system.
> >
> >         One approach as Nat promotes is to have the authorization
> >         endpoint return the next hop, token endpoint for code or RS URI
> >         for token. The token endpoint must also return the RS URI or th=
e
> >         client must push the RS URI to the token endpoint or the
> >         attacker just replaces the RS URI in the config and captures th=
e
> >         token that way.
> >
> >         The other way is to provide a name for each AS as part of
> >         registration and the client not allow duplicate registrations
> >         with the same name.  When the response comes back the client
> >         checks the name against the one it made the request to. If the
> >         name dereferences to a discovery document then the client can
> >         check that name at registration or runtime to validate the net
> hops.
> >
> >         I think the two approaches mitigate the attack in similar ways.
> >         Nat=E2=80=99s is more REST friendly and returns the next hop as=
 a
> >         parameter of header.
> >
> >         The one Mike and I wrote up based on the meeting in Germany
> >         provides identifiers (iss and client_id) that can be checked fo=
r
> >         validity in the simple case and be dereferenced via .well-known
> >         to get the information Nat=E2=80=99s proposal is providing.
> >
> >         Perhaps the main difference is Nat is using the token endpoint
> >         as the identifier for the AS and Mike=E2=80=99s is using locati=
on for a
> >         discovery document as the identifier.
> >
> >         I don=E2=80=99t recall the reasons using the token endpoint as =
the
> >         identifier was rejected at the meeting.  Perhaps others can pos=
t
> >         the reasons.
> >
> >         We need to close on this quickly, otherwise if we are indecisiv=
e
> >         fixes will not go into products for another year or so until
> >         this is a RFC.
> >
> >         That is my main concern.
> >
> >         John B.
> >
> >             On Jan 21, 2016, at 11:50 AM, Josh Mandel  >             > wrote:
> >
> >             Thanks Nat - that's helpful. If both mitigations *can* work
> >             effectively, then I would like to see this group consider
> >             the decision between them carefully (if that hasn't happene=
d
> >             yet). Again, don't hesitate to let me know if this is the
> >             wrong place/time for such discussion.
> >
> >             At a high level, I would rather ask server developers to do
> >             some "coding", for two reasons:
> >
> >             1. Most OAuth servers talk to many, many clients. So
> >             consolidating the security critical work in one place
> >             (server) is a net savings of work (rather than asking each
> >             client to implement these checks.
> >
> >             2. OAuth server developers are typically more sophisticated
> >             than client developers, and therefore more likely to
> >             understand the implications and more likely to get these
> >             critical details correct. Asking each client developer to d=
o
> >             something right is likely to result in heterogenius
> >             implementation and persistent security holes. But if the
> >             server does the heavy lifting, and clients just have to pas=
s
> >             along an extra parameter, this is more likely to see
> >             consistent implementation (for example, clients will fail t=
o
> >             work if misconfigured, which will prompt developers to fix
> >             them).
> >
> >             On Jan 21, 2016 09:40, "Nat Sakimura"  >             > wrote:
> >
> >                 Hi Josh,
> >
> >                 It is similar but slightly different IMHO.
> >
> >                 Section 4.6.4 of the RFC6819 is the access token
> >                 phishing by a counterfeit resource server.
> >
> >                 The mix-up attack described here is the code phishing b=
y
> >                 a counterfeit token endpoint.
> >
> >                 In my view, both can be mitigated by the server
> >                 returning the next step: i.e., authorization endpoint
> >                 returning the legitimate token endpoint uri, and token
> >                 endpoint returning legitimate resource endpoint uris.
> >                 This involves no discovery endpoint, which is good.
> >
> >                 Your way also works. It is just the reverse of my
> >                 proposal. The difference being that my proposal does no=
t
> >                 need any coding on the server but just configuration,
> >                 and it can return more metadata if needed.
> >
> >                 Cheers,
> >
> >                 Nat
> >
> >                 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Jos=
h Mandel  >                 >:
> >
> >                     Apologies if this is the wrong forum for my comment
> >                     (and please direct me to the appropriate place in
> >                     that case), but I have two questions about the
> >                     propose mitigation (and the thinking behind it) tha=
t
> >                     I think the write-up could address:
> >
> >                     1. Could the writeup clarify whether/how the primar=
y
> >                     "mixup" threat differs from what RFC6819 identifies
> >                     as in section 4.6.4?
> >
> >                     2. Has the workgroup considered a mitigation that
> >                     puts more responsibility on the authorization
> >                     server, and less on the client? For example, if
> >                     would be helpful for the writeup to clarify why
> >                     having the client send an "audience field" (in the
> >                     terminology of RFC6819) to the authorization
> >                     endpoint would not mitigate the threat. (In that
> >                     scenario, the authorization server can recognize
> >                     that the audience does not correspond to a resource
> >                     server it knows, rather than asking clients to make
> >                     this check). I assume this approach has been
> >                     considered and rejected as an incomplete mitigation=
,
> >                     but I don't have visibility into where/how that
> >                     discussion went.
> >
> >                     Thanks,
> >
> >                     Josh
> >
> >                     Hi all,
> >
> >                     this is the call for adoption of OAuth 2.0 Mix-Up
> >                     Mitigation, see
> >
> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
> >
> >                     Please let us know by Feb 9th whether you accept /
> >                     object to the
> >                     adoption of this document as a starting point for
> >                     work in the OAuth
> >                     working group.
> >
> >                     Note: This call is related to the announcement made
> >                     on the list earlier
> >                     this month, see
> >
> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html.
> >                     More
> >                     time for analysis is provided due to the complexity
> >                     of the topic.
> >
> >                     Ciao
> >                     Hannes & Derek
> >
> >
> >                     _______________________________________________
> >                     OAuth mailing list
> >                     OAuth@ietf.org 
> >                     https://www.ietf.org/mailman/listinfo/oauth
> >
> >                     _______________________________________________
> >                     OAuth mailing list
> >                     OAuth@ietf.org 
> >                     https://www.ietf.org/mailman/listinfo/oauth
> >
> >             _______________________________________________
> >             OAuth mailing list
> >             OAuth@ietf.org 
> >             https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
> --
> Hans Zandbelt              | Sr. Technical Architect
> hzandbelt@pingidentity.com | Ping Identity
>

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

Since we have been discussing in another thread and you guys may be a aware=
 of it in this thread, here is one of the problem statement for the mix-up =
draft explaining why it does not solve the problem as it is written now. 
It can be fixed to solve the problem, but then the overhead size will=
 be much larger and involves an extra round trip compared to oauth-meta dra=
ft. 

See http://nat.sakimura.org/2016/01/22/code-phis=
hing-attack-on-oauth-2-0-rfc6749/ for the details. 

Nat
2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=
=E9=87=91) 18:11 Hans Zandbelt <hzandbelt@pingidentity.com>:
+1 to everything Mike stated



Hans.



On 1/22/16 2:04 AM, Mike Jones wrote:

> I believe that it=E2=80=99s simpler and more elegant to return an issu=
er, from

> which the discovery metadata document can be retrieved, which contains=


> **all** the configuration information about the authorization server,<=
br>
> than to return some of the configuration parameters but not most of th=
em

> (which is what the oauth-meta proposal does).=C2=A0 There=E2=80=99s lo=
ts more in a

> typical discovery document than just a few endpoint addresses. For

> instance, there are statements about what response types are supported=
,

> other configuration choices, keys, etc.

>

> I also think that returning the issuer is more future-proof than tryin=
g

> to decide now what all the configuration information is that might wan=
t

> to be verified by the client and hoping we get it right.=C2=A0 With th=
e

> issuer, assuming that discovery is supported, it can retrieve and chec=
k

> all of it, should the client want/need to do so.=C2=A0 Even when disco=
very

> isn=E2=80=99t supported, the issuer still provides a concrete identifi=
er for the

> authorization server that can be checked for equality.

>

> We talked about the value of that approach in the side meetings in

> Yokohama and people were supportive then.

>

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

>

> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley

> *Sent:* Thursday, January 21, 2016 4:48 PM

> *To:* Nat Sakimura <sakimura@gmail.com>

> *Cc:* oauth@ietf.o=
rg WG <oauth@iet=
f.org>

> *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigati=
on

>

> I will point out for clarification that this would be like IdP discove=
ry

> in openID 2 that everyone did.=C2=A0 I think IdP not doing RP discover=
y in

> openID 2 is a weak argument.

>

> There may be other evidence that RP will not do discovery, but if that=


> is the case why are we doing a OAuth discovery spec?

>

> Many people see your spec as discovery as well just in a different way=
.

>

> I think both ways can work, but doing both leaves too many options.
>

> John B.

>

>=C2=A0 =C2=A0 =C2=A0On Jan 21, 2016, at 9:38 PM, Nat Sakimura <sakimura@gmail.com
>=C2=A0 =C2=A0 =C2=A0<mailto:sakimura@gmail.com>> wrote:

>

>=C2=A0 =C2=A0 =C2=A0Still doing the analysis. We spent 1.5 hours today =
with John,

>=C2=A0 =C2=A0 =C2=A0George, nov and me on the OpenID Connect WG call on=
 this issue. John

>=C2=A0 =C2=A0 =C2=A0explained the mitigation, but none of us was convin=
ced that it works.

>

>=C2=A0 =C2=A0 =C2=A0Then, after the call, I and nov went on with variou=
s scenarios. The

>=C2=A0 =C2=A0 =C2=A0interim conclusion is that:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0* client_id response parameter does not help=
. There are legitimate

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cases that client_id duplicates out t=
here and we cannot ban that.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0* iss response parameter does not help unles=
s the discovery is

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0performed and the value of iss is che=
cked against the value of

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OAuth issuer inside the document. (&l=
t;- Discovery becomes

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mandatory. From our experience on RP =
discovery step in OpenID

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02.0, chance of this being done proper=
ly seems to be rather slim.)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0* sending the state to the token endpoint he=
lps in the case code

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0was stollen, but code should not be s=
tolen to start with.

>

>=C2=A0 =C2=A0 =C2=A0Cheers,

>

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

>

>=C2=A0 =C2=A0 =C2=A02016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 =
John Bradley <ve7=
jtb@ve7jtb.com

>=C2=A0 =C2=A0 =C2=A0<mailto:ve7jtb@ve7jtb.com>>:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0There have been a lot of discussions.=
 I think Hannes posted some

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0minutes of the F2F meeting we had wit=
h the security researchers.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The problem can=E2=80=99t be mitigate=
d without some action on the client

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0side.=C2=A0 It boils down to the clie=
nt making a request to AS1 (From

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it=E2=80=99s perspective) and getting=
 back a response from AS 2 (that it

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thinks is AS1)

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This can be done if AS1 is a good AS =
but has it=E2=80=99s logs

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compromised so that an attacker can r=
ead them. Hans Zandbelt

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0built a proof of concept for the atta=
ck.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In some cases the attacker gets the c=
ode and the credential to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0use it at the good AS token endpoint =
and in others it just gets

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the code and can replay that at the c=
lient to extract

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0information from the API through the =
client by binding the api

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0access to a new account.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PKCE unfortunately mitigates a differ=
ent attack, where the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client is impersonated and trys to re=
play a intercepted code.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It however assumes the token endpoint=
 is good, and is no help in

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the case of a compromised token endpo=
int.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The client in these attacks is vulner=
able because it relies on

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some local state, or the value of the=
 state parameter to know

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0who the response is coming from.=C2=
=A0 This allows a authorization

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0request that is intercepted to be use=
d to create a new request

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in that browser to a different AS, or=
 trick the client into

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0using a Authorization endpoint for a =
different authorization server.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0One problem is that OAuth doesn=E2=80=
=99t really have a unified concept

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of what a AS is.=C2=A0 Traditionally =
it is a Authorization endpoint

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0URI, token end point URI and resource=
 server URI that some one

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0gives the client in some documentatio=
n.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0As ling as a client only talks to one=
 AS then there is no

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0problem.=C2=A0 =C2=A0However once a c=
lient is configured to talk to more

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0than one AS, we have problems if one =
of those AS lies about it=E2=80=99s

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0endpoints, or is compromised and used=
 to attack another AS.=C2=A0 =C2=A0As

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a design goal you don=E2=80=99t want =
the overall=C2=A0 security to be limited

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by the weakest system.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0One approach as Nat promotes is to ha=
ve the authorization

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0endpoint return the next hop, token e=
ndpoint for code or RS URI

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for token. The token endpoint must al=
so return the RS URI or the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client must push the RS URI to the to=
ken endpoint or the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0attacker just replaces the RS URI in =
the config and captures the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0token that way.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The other way is to provide a name fo=
r each AS as part of

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0registration and the client not allow=
 duplicate registrations

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with the same name.=C2=A0 When the re=
sponse comes back the client

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0checks the name against the one it ma=
de the request to. If the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0name dereferences to a discovery docu=
ment then the client can

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0check that name at registration or ru=
ntime to validate the net hops.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think the two approaches mitigate t=
he attack in similar ways.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Nat=E2=80=99s is more REST friendly a=
nd returns the next hop as a

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0parameter of header.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The one Mike and I wrote up based on =
the meeting in Germany

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0provides identifiers (iss and client_=
id) that can be checked for

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0validity in the simple case and be de=
referenced via .well-known

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to get the information Nat=E2=80=99s =
proposal is providing.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Perhaps the main difference is Nat is=
 using the token endpoint

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0as the identifier for the AS and Mike=
=E2=80=99s is using location for a

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discovery document as the identifier.=


>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I don=E2=80=99t recall the reasons us=
ing the token endpoint as the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identifier was rejected at the meetin=
g.=C2=A0 Perhaps others can post

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the reasons.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We need to close on this quickly, oth=
erwise if we are indecisive

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0fixes will not go into products for a=
nother year or so until

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this is a RFC.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0That is my main concern.

>

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

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Jan 21, 2016, at 11:=
50 AM, Josh Mandel <jmandel@gmail.com

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:jmandel@gmail.com>> wr=
ote:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks Nat - that's=
 helpful. If both mitigations *can* work

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0effectively, then I wou=
ld like to see this group consider

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the decision between th=
em carefully (if that hasn't happened

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yet). Again, don't =
hesitate to let me know if this is the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrong place/time for su=
ch discussion.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0At a high level, I woul=
d rather ask server developers to do

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0some "coding"=
, for two reasons:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01. Most OAuth servers t=
alk to many, many clients. So

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0consolidating the secur=
ity critical work in one place

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(server) is a net savin=
gs of work (rather than asking each

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client to implement the=
se checks.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02. OAuth server develop=
ers are typically more sophisticated

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0than client developers,=
 and therefore more likely to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0understand the implicat=
ions and more likely to get these

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0critical details correc=
t. Asking each client developer to do

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0something right is like=
ly to result in heterogenius

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implementation and pers=
istent security holes. But if the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server does the heavy l=
ifting, and clients just have to pass

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0along an extra paramete=
r, this is more likely to see

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0consistent implementati=
on (for example, clients will fail to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0work if misconfigured, =
which will prompt developers to fix

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0them).

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On Jan 21, 2016 09:40, =
"Nat Sakimura" <sakimura@gmail.com

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

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Josh,<=
br>
>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It is sim=
ilar but slightly different IMHO.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 4=
.6.4 of the RFC6819 is the access token

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0phishing =
by a counterfeit resource server.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The mix-u=
p attack described here is the code phishing by

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a counter=
feit token endpoint.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In my vie=
w, both can be mitigated by the server

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0returning=
 the next step: i.e., authorization endpoint

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0returning=
 the legitimate token endpoint uri, and token

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0endpoint =
returning legitimate resource endpoint uris.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This invo=
lves no discovery endpoint, which is good.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Your way =
also works. It is just the reverse of my

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0proposal.=
 The difference being that my proposal does not

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0need any =
coding on the server but just configuration,

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and it ca=
n return more metadata if needed.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Cheers,
>

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

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02016=E5=
=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel <jmandel@gmail.com

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailt=
o:jmandel@gmail.com<=
/a>>>:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Apologies if this is the wrong forum for my comment

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0(and please direct me to the appropriate place in

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0that case), but I have two questions about the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0propose mitigation (and the thinking behind it) that

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0I think the write-up could address:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A01. Could the writeup clarify whether/how the primary

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0"mixup" threat differs from what RFC6819 identifies

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0as in section 4.6.4?

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A02. Has the workgroup considered a mitigation that

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0puts more responsibility on the authorization

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0server, and less on the client? For example, if

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0would be helpful for the writeup to clarify why

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0having the client send an "audience field" (in the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0terminology of RFC6819) to the authorization

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0endpoint would not mitigate the threat. (In that

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0scenario, the authorization server can recognize

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0that the audience does not correspond to a resource

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0server it knows, rather than asking clients to make

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0this check). I assume this approach has been

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0considered and rejected as an incomplete mitigation,

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0but I don't have visibility into where/how that

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0discussion went.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Thanks,

>

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

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Hi all,

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0this is the call for adoption of OAuth 2.0 Mix-Up

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Mitigation, see

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0https://tools.ietf.org/html/=
draft-jones-oauth-mix-up-mitigation-00

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Please let us know by Feb 9th whether you accept /

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0object to the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0adoption of this document as a starting point for

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0work in the OAuth

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0working group.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Note: This call is related to the announcement made

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0on the list earlier

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0this month, see

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0http://www.ietf.org/mail-archi=
ve/web/oauth/current/msg15336.html.

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

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0time for analysis is provided due to the complexity

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0of the topic.

>

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

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Hannes & Derek

>

>

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

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

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

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

>

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

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

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

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

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_______________________=
________________________

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

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

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

>

>

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

>



--

Hans Zandbelt=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Sr. Technic=
al Architect

hzandbelt@p=
ingidentity.com | Ping Identity




--001a114a7d20776073052a083298--


From nobody Sun Jan 24 20:11:30 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFB31A6FD7 for ; Sun, 24 Jan 2016 20:11:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmK8n8W8CSx4 for ; Sun, 24 Jan 2016 20:11:25 -0800 (PST)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 348D31A6FD8 for ; Sun, 24 Jan 2016 20:11:25 -0800 (PST)
Received: by mail-ob0-x234.google.com with SMTP id is5so106606782obc.0 for ; Sun, 24 Jan 2016 20:11:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PkBWNPnd4gPJeKI2mc+faV9XlNRixWfWfqdMG1wHggI=; b=Yn8pERt5Z162+ppEjm4OnRFXuxSk1ftu9cWL9qwser6cC3xltHcD+ekmUQ0iHx6sae mE7byzGKt8Bn+pznudXc/lw6C8D9CiK2KsyyRdu5dutWcqb5ab61LiDZmiu51KXs9qGk VZFTk68qsAzfuW6ZeSu6+WE1C6W9FTmOQ20aK9nrN/3la1iM581N+qj+0y6p6oEujDRc 4sEqM/S6YyH7sTd3ZesIDoboN6c0BHBrtASCujvZ3DmInpWzOjq6W1q3iu+NMZzCWicE D4A9nxL/PKK69ZStialUZfSXqxiW9WP+FE5kcQCGFQUErhHv0oMnR2oT1rwWmh+OO03V XQgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PkBWNPnd4gPJeKI2mc+faV9XlNRixWfWfqdMG1wHggI=; b=V7SNgQorIsrfgWFyuGE1POCCICADMWueQa5iZt5Thy1JEe/uMU+GK90IJ1oDmOqxQy cHHhMPrw9oUweT06GtPbxaRlS5mA3cn3RMc6EALS1FJB5+jd8gUgUmxdrUiOGd7TxD4P ma7QGhV8rIpvwWiBwCLDPnu6OLH535pY7Bi2mLFVu2xQoa95XgJzPCTotI1BPw5SvOG1 5qCkxzRYDrG03/2fF9SzN+2fJebdforw048ofMwck5rHEkBgGNrVzRFLa4tRc4AW/UtD 6iKKaVLmGoCiIg5bsfYIME51QsytDt32RsPGF69pmrTK4ruDP5mIyzmKGiPDE9otaZVu VQ0A==
X-Gm-Message-State: AG10YOS6jkD7M/7eDohjFbGZFpbachDzkUTgTi1NN0xV3+FBmZqbfRQi4V5oNNBsVFU8OF363JOQM2KrxYMFGAmP
X-Received: by 10.60.138.67 with SMTP id qo3mr11334350oeb.80.1453695084361; Sun, 24 Jan 2016 20:11:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.227.39 with HTTP; Sun, 24 Jan 2016 20:11:04 -0800 (PST)
In-Reply-To: <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>
From: William Denniss 
Date: Sun, 24 Jan 2016 20:11:04 -0800
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=047d7b2e465a1dc151052a20c392
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 04:11:28 -0000

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

On Thu, Jan 21, 2016 at 2:59 PM, John Bradley  wrote:

> There have been a lot of discussions. I think Hannes posted some minutes
> of the F2F meeting we had with the security researchers.
>
> The problem can=E2=80=99t be mitigated without some action on the client =
side.  It
> boils down to the client making a request to AS1 (From it=E2=80=99s persp=
ective)
> and getting back a response from AS 2 (that it thinks is AS1)
>
> This can be done if AS1 is a good AS but has it=E2=80=99s logs compromise=
d so that
> an attacker can read them. Hans Zandbelt built a proof of concept for the
> attack.
>

So for mix-up, we're only talking about a compromised logs attack and not a
completely compromised AS?


> In some cases the attacker gets the code and the credential to use it at
> the good AS token endpoint and in others it just gets the code and can
> replay that at the client to extract information from the API through the
> client by binding the api access to a new account.
>
> PKCE unfortunately mitigates a different attack, where the client is
> impersonated and trys to replay a intercepted code.  It however assumes t=
he
> token endpoint is good, and is no help in the case of a compromised token
> endpoint.
>
> The client in these attacks is vulnerable because it relies on some local
> state, or the value of the state parameter to know who the response is
> coming from.  This allows a authorization request that is intercepted to =
be
> used to create a new request in that browser to a different AS, or trick
> the client into using a Authorization endpoint for a different
> authorization server.
>
> One problem is that OAuth doesn=E2=80=99t really have a unified concept o=
f what a
> AS is.  Traditionally it is a Authorization endpoint URI, token end point
> URI and resource server URI that some one gives the client in some
> documentation.
>
> As ling as a client only talks to one AS then there is no problem.
> However once a client is configured to talk to more than one AS, we have
> problems if one of those AS lies about it=E2=80=99s endpoints, or is comp=
romised
> and used to attack another AS.   As a design goal you don=E2=80=99t want =
the
> overall  security to be limited by the weakest system.
>
> One approach as Nat promotes is to have the authorization endpoint return
> the next hop, token endpoint for code or RS URI for token. The token
> endpoint must also return the RS URI or the client must push the RS URI t=
o
> the token endpoint or the attacker just replaces the RS URI in the config
> and captures the token that way.
>

I believe the RS URI would not be needed to defeat the compromised logs
mix-up attack for the code flow. The client will send the client_id it got
when registering at AS1 to the token endpoint returned by AS2 (using Nat's
spec), which will then cause a failure due to client_id mis-match. So
simply returning the "token_endpoint" URI in the AS2 authorization response
would defeat the compromised-logs mix-up attack, would it not?


> The other way is to provide a name for each AS as part of registration an=
d
> the client not allow duplicate registrations with the same name.  When th=
e
> response comes back the client checks the name against the one it made th=
e
> request to.  If the name dereferences to a discovery document then the
> client can check that name at registration or runtime to validate the net
> hops.
>
> I think the two approaches mitigate the attack in similar ways.  Nat=E2=
=80=99s is
> more REST friendly and returns the next hop as a parameter of header.
>
> The one Mike and I wrote up based on the meeting in Germany provides
> identifiers (iss and client_id) that can be checked for validity in the
> simple case and be dereferenced via .well-known to get the information
> Nat=E2=80=99s proposal is providing.
>


>
> Perhaps the main difference is Nat is using the token endpoint as the
> identifier for the AS and Mike=E2=80=99s is using location for a discover=
y document
> as the identifier.
>
> I don=E2=80=99t recall the reasons using the token endpoint as the identi=
fier was
> rejected at the meeting.  Perhaps others can post the reasons.
>

Can you help clarify something that I've yet to discern from the minutes,
does OpenID Connect solve the mix-up attack by binding all the tokens
together and to the issuer via the ID Token?


We need to close on this quickly, otherwise if we are indecisive fixes will
> not go into products for another year or so until this is a RFC.
>
> That is my main concern.
>
> John B.
>
>
>
>
>
> On Jan 21, 2016, at 11:50 AM, Josh Mandel  wrote:
>
> Thanks Nat - that's helpful. If both mitigations *can* work effectively,
> then I would like to see this group consider the decision between them
> carefully (if that hasn't happened yet). Again, don't hesitate to let me
> know if this is the wrong place/time for such discussion.
>
> At a high level, I would rather ask server developers to do some "coding"=
,
> for two reasons:
>
> 1. Most OAuth servers talk to many, many clients. So consolidating the
> security critical work in one place (server) is a net savings of work
> (rather than asking each client to implement these checks.
>
> 2. OAuth server developers are typically more sophisticated than client
> developers, and therefore more likely to understand the implications and
> more likely to get these critical details correct. Asking each client
> developer to do something right is likely to result in heterogenius
> implementation and persistent security holes. But if the server does the
> heavy lifting, and clients just have to pass along an extra parameter, th=
is
> is more likely to see consistent implementation (for example, clients wil=
l
> fail to work if misconfigured, which will prompt developers to fix them).
> On Jan 21, 2016 09:40, "Nat Sakimura"  wrote:
>
>> Hi Josh,
>>
>> It is similar but slightly different IMHO.
>>
>> Section 4.6.4 of the RFC6819 is the access token phishing by a
>> counterfeit resource server.
>> The mix-up attack described here is the code phishing by a counterfeit
>> token endpoint.
>>
>> In my view, both can be mitigated by the server returning the next step:
>> i.e., authorization endpoint returning the legitimate token endpoint uri=
,
>> and token endpoint returning legitimate resource endpoint uris. This
>> involves no discovery endpoint, which is good.
>>
>> Your way also works. It is just the reverse of my proposal. The
>> difference being that my proposal does not need any coding on the server
>> but just configuration, and it can return more metadata if needed.
>>
>> Cheers,
>>
>> Nat
>>
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel :
>>
>>> Apologies if this is the wrong forum for my comment (and please direct
>>> me to the appropriate place in that case), but I have two questions abo=
ut
>>> the propose mitigation (and the thinking behind it) that I think the
>>> write-up could address:
>>>
>>> 1. Could the writeup clarify whether/how the primary "mixup" threat
>>> differs from what RFC6819 identifies as in section 4.6.4?
>>>
>>> 2. Has the workgroup considered a mitigation that puts more
>>> responsibility on the authorization server, and less on the client? For
>>> example, if would be helpful for the writeup to clarify why having the
>>> client send an "audience field" (in the terminology of RFC6819) to the
>>> authorization endpoint would not mitigate the threat. (In that scenario=
,
>>> the authorization server can recognize that the audience does not
>>> correspond to a resource server it knows, rather than asking clients to
>>> make this check). I assume this approach has been considered and reject=
ed
>>> as an incomplete mitigation, but I don't have visibility into where/how
>>> that discussion went.
>>>
>>> Thanks,
>>>
>>> Josh
>>> Hi all,
>>>
>>> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
>>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>>>
>>> Please let us know by Feb 9th whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth
>>> working group.
>>>
>>> Note: This call is related to the announcement made on the list earlier
>>> this month, see
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html. More
>>> time for analysis is provided due to the complexity of the topic.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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



=
On Thu, Jan 21, 2016 at 2:59 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
There =
have been a lot of discussions. I think Hannes posted some minutes of the F=
2F meeting we had with the security researchers.

The pro=
blem can=E2=80=99t be mitigated without some action on the client side.=C2=
=A0 It boils down to the client making a request to AS1 (From it=E2=80=99s =
perspective) and getting back a response from AS 2 (that it thinks is AS1)<=
/div>

This can be done if AS1 is a good AS but has it=E2=
=80=99s logs compromised so that an attacker can read them. Hans Zandbelt b=
uilt a proof of concept for the attack.=C2=A0
=

So for mix-up, we're only talking about a compromised lo=
gs attack and not a completely compromised AS?
=C2=A0
In some cases the attac=
ker gets the code and the credential to use it at the good AS token endpoin=
t and in others it just gets the code and can replay that at the client to =
extract information from the API through the client by binding the api acce=
ss to a new account.

PKCE unfortunately mitigates =
a different attack, where the client is impersonated and trys to replay a i=
ntercepted code.=C2=A0 It however assumes the token endpoint is good, and i=
s no help in the case of a compromised token endpoint.

=

The client in these attacks is vulnerable because it relies on some lo=
cal state, or the value of the state parameter to know who the response is =
coming from.=C2=A0 This allows a authorization request that is intercepted =
to be used to create a new request in that browser to a different AS, or tr=
ick the client into using a Authorization endpoint for a different authoriz=
ation server.

One problem is that OAuth doesn=E2=
=80=99t really have a unified concept of what a AS is.=C2=A0 Traditionally =
it is a Authorization endpoint URI, token end point URI and resource server=
 URI that some one gives the client in some documentation. =C2=A0=C2=A0

As ling as a client only talks to one AS then there i=
s no problem. =C2=A0 However once a client is configured to talk to more th=
an one AS, we have problems if one of those AS lies about it=E2=80=99s endp=
oints, or is compromised and used to attack another AS. =C2=A0 As a design =
goal you don=E2=80=99t want the overall =C2=A0security to be limited by the=
 weakest system.

One approach as Nat promotes is t=
o have the authorization endpoint return the next hop, token endpoint for c=
ode or RS URI for token. The token endpoint must also return the RS URI or =
the client must push the RS URI to the token endpoint or the attacker just =
replaces the RS URI in the config and captures the token that way.=C2=A0

I believe the RS URI would not be=
 needed to defeat the compromised logs mix-up attack for the code flow. The=
 client will send the client_id it got when registering at AS1 to the token=
 endpoint returned by AS2 (using Nat's spec), which will then cause a f=
ailure due to client_id mis-match. So simply returning the "token_endp=
oint" URI in the AS2 authorization response would defeat the compromis=
ed-logs mix-up attack, would it not?=C2=A0
=C2=A0
The other way is to pro=
vide a name for each AS as part of registration and the client not allow du=
plicate registrations with the same name.=C2=A0 When the response comes bac=
k the client checks the name against the one it made the request to.=C2=A0 =
If the name dereferences to a discovery document then the client can check =
that name at registration or runtime to validate the net hops.
I think the two approaches mitigate the attack in similar ways=
.=C2=A0 Nat=E2=80=99s is more REST friendly and returns the next hop as a p=
arameter of header. =C2=A0

The one Mike and I wrot=
e up based on the meeting in Germany provides identifiers (iss and client_i=
d) that can be checked for validity in the simple case and be dereferenced =
via .well-known to get the information Nat=E2=80=99s proposal is providing.=

=C2=A0

Perhaps the main difference is Nat =
is using the token endpoint as the identifier for the AS and Mike=E2=80=99s=
 is using location for a discovery document as the identifier.
I don=E2=80=99t recall the reasons using the token endpoint as=
 the identifier was rejected at the meeting.=C2=A0 Perhaps others can post =
the reasons.

Can you help clari=
fy something that I've yet to discern from the minutes, does OpenID Con=
nect solve the mix-up attack by binding all the tokens together and to the =
issuer via the ID Token?


We need to close on this quickly=
, otherwise if we are indecisive fixes will not go into products for anothe=
r year or so until this is a RFC.

That is my main =
concern.

John B.





On Jan 21, 2016, at 11:50 AM, Josh Mandel <jmandel@gmail.com> wrote:
Thanks Nat - that's helpful. If both mitigatio=
ns *can* work effectively, then I would like to see this group consider the=
 decision between them carefully (if that hasn't happened yet). Again, =
don't hesitate to let me know if this is the wrong place/time for such =
discussion. 
At a high level, I would rather ask server d=
evelopers to do some "coding", for two reasons:
1. Most OAuth servers talk to many, many clients. So consolidating the sec=
urity critical work in one place (server) is a net savings of work (rather =
than asking each client to implement these checks. 
2. OA=
uth server developers are typically more sophisticated than client develope=
rs, and therefore more likely to understand the implications and more likel=
y to get these critical details correct. Asking each client developer to do=
 something right is likely to result in heterogenius implementation and per=
sistent security holes. But if the server does the heavy lifting, and clien=
ts just have to pass along an extra parameter, this is more likely to see c=
onsistent implementation (for example, clients will fail to work if misconf=
igured, which will prompt developers to fix them). 


On Jan 21, 2016 09:40, "Nat Sakimura" =
<sakimura@gmail.=
com> wrote:
Hi Josh,=C2=A0

It is similar but slightly different IM=
HO.=C2=A0

Section 4.6.4 of the RFC6819 is the acce=
ss token phishing by a counterfeit resource server.=C2=A0
The mix=
-up attack described here is the code phishing by a counterfeit token endpo=
int.=C2=A0

In my view, both can be mitigated by th=
e server returning the next step: i.e., authorization endpoint returning th=
e legitimate token endpoint uri, and token endpoint returning legitimate re=
source endpoint uris. This involves no discovery endpoint, which is good.=
=C2=A0

Your way also works. It is just the reverse=
 of my proposal. The difference being that my proposal does not need any co=
ding on the server but just configuration, and it can return more metadata =
if needed.=C2=A0

Cheers,=C2=A0

Nat

2016=
=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel <jmandel@gmail.com>:
<=
/div>
Apologies if this is the wrong forum f=
or my comment (and please direct me to the appropriate place in that case),=
 but I have two questions about the propose mitigation (and the thinking be=
hind it) that I think the write-up could address:
1. Coul=
d the writeup clarify whether/how the primary "mixup" threat diff=
ers from what RFC6819 identifies as in section 4.6.4? 
2.=
 Has the workgroup considered a mitigation that puts more responsibility on=
 the authorization server, and less on the client? For example, if would be=
 helpful for the writeup to clarify why having the client send an "aud=
ience field" (in the terminology of RFC6819) to the authorization endp=
oint would not mitigate the threat. (In that scenario, the authorization se=
rver can recognize that the audience does not correspond to a resource serv=
er it knows, rather than asking clients to make this check). I assume this =
approach has been considered and rejected as an incomplete mitigation, but =
I don't have visibility into where/how that discussion went. 
Thanks, 
Josh 




Hi all,



this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see

https://tools.ietf.org/html/draft-=
jones-oauth-mix-up-mitigation-00



Please let us know by Feb 9th whether you accept / object to the

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

working group.



Note: This call is related to the announcement made on the list earlier

this month, see

http://www.ietf.org/mail-archive/web=
/oauth/current/msg15336.html. More

time for analysis is provided due to the complexity of the topic.



Ciao

Hannes & Derek




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





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

______________________________________________=
_

OAuth mailing list

OAuth@ietf.org

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





--047d7b2e465a1dc151052a20c392--


From nobody Sun Jan 24 22:11:52 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABD2D1A8032 for ; Sun, 24 Jan 2016 22:11:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oopVA6zC7DPJ for ; Sun, 24 Jan 2016 22:11:45 -0800 (PST)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F181A88D1 for ; Sun, 24 Jan 2016 22:11:45 -0800 (PST)
Received: by mail-pf0-x232.google.com with SMTP id q63so78802432pfb.1 for ; Sun, 24 Jan 2016 22:11:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=qx82vOkj5K+WYa4mMQt+ow78bVRGlAuLz5eTKawFfZU=; b=uly1sBHV/xY4DUtcvmlSpNv5Web+o+Q/3nezy9EgSZz48Xmvk55i9yabgCZ/3XmR53 fcDfqXoKhFjcNwARMCVXq4Q913pjI6hNTUldSWrx7urkzHwuuU21sBjlJIrIWYl5qPep 9JHdd4xncvIa5p7W6CuygjAJVvM5As+JZoatHDBQRmhXQR9+ckSWp1u+jTPZDgzG5Xfd p9jthlnoRWPcTTaWGUzFB8mnYyygUlG3nSDoLNb1x9+x9qVbyrFWAL2ZeMjonHqeNFFZ EfRXnqmsoYxd/ZwmQpTbejR4clHcbhp0b7e5JbmUur1QlSyFAnqBvwvKk4ppkWaf0IIg Pd0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=qx82vOkj5K+WYa4mMQt+ow78bVRGlAuLz5eTKawFfZU=; b=mgOwymzNEEh/0musJnMpBD7c8CKWy+DzlWD57CsVtwFmStC5Tjby2FfdtNJ5Q2Xngb 8X0NbTP61koh59Tumzg/g0hAHfvbf+mUvULxTPz3kEuZXswy2x3SNPSq2r18Ugsa/4yK 7H3MGsWzaCaqtat+SYb2/ttjAc+bT7q6sz4H+mOkGeacMRKZV6k8j7MYGQ/blB71OImi VyyB9nCaiRHBluB2QQPlaxtcDCJEl20GvlRgEeD18GmRfcAYMQJfZggeyLaG3fMjRqN0 s7ayCSS03KRctD9sd2+gY5/ikfD9oz0u4JGCCHfZ46IWnPux3HjdWtE/s7LdyVTVZT09 nEMA==
X-Gm-Message-State: AG10YOSQzcVymEuBE/PR9ASAc1z1pwAmEWG8UTsZkVk2WAFqiS1PlEG+pRXNispMxE1FZw==
X-Received: by 10.98.0.150 with SMTP id 144mr23320189pfa.139.1453702305053; Sun, 24 Jan 2016 22:11:45 -0800 (PST)
Received: from tovan.intra.gree-office.net ([27.110.57.140]) by smtp.gmail.com with ESMTPSA id n84sm25414673pfa.45.2016.01.24.22.11.42 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 24 Jan 2016 22:11:44 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2CDED874-9E7C-4C60-8E6E-61A273DE1ACA"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: nov matake 
In-Reply-To: 
Date: Mon, 25 Jan 2016 15:11:41 +0900
Message-Id: <65A02656-94A6-47AB-AC77-FA1D71186D37@gmail.com>
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.com>  <56A1F249.3020307@pingidentity.com> 
To: Nat Sakimura 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 06:11:50 -0000

--Apple-Mail=_2CDED874-9E7C-4C60-8E6E-61A273DE1ACA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hum, even if the client uses different redirect_uri per each IdP, code =
phishing attack succeeds in Nat=E2=80=99s sample attack scenario.
In such scenario, returning AuthZ endpoint URI as AuthZ response also =
won=E2=80=99t help.

So it seems returning =E2=80=9Ciss" (with discovery support) or =
oauth-meta is MUST for such case.

> On Jan 24, 2016, at 07:52, Nat Sakimura  wrote:
>=20
> Since we have been discussing in another thread and you guys may be a =
aware of it in this thread, here is one of the problem statement for the =
mix-up draft explaining why it does not solve the problem as it is =
written now.=20
>=20
> It can be fixed to solve the problem, but then the overhead size will =
be much larger and involves an extra round trip compared to oauth-meta =
draft.=20
>=20
> See =
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc67=
49/ =
 for the details.=20
>=20
> Nat
> 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 18:11 Hans Zandbelt =
>:
> +1 to everything Mike stated
>=20
> Hans.
>=20
> On 1/22/16 2:04 AM, Mike Jones wrote:
> > I believe that it=E2=80=99s simpler and more elegant to return an =
issuer, from
> > which the discovery metadata document can be retrieved, which =
contains
> > **all** the configuration information about the authorization =
server,
> > than to return some of the configuration parameters but not most of =
them
> > (which is what the oauth-meta proposal does).  There=E2=80=99s lots =
more in a
> > typical discovery document than just a few endpoint addresses. For
> > instance, there are statements about what response types are =
supported,
> > other configuration choices, keys, etc.
> >
> > I also think that returning the issuer is more future-proof than =
trying
> > to decide now what all the configuration information is that might =
want
> > to be verified by the client and hoping we get it right.  With the
> > issuer, assuming that discovery is supported, it can retrieve and =
check
> > all of it, should the client want/need to do so.  Even when =
discovery
> > isn=E2=80=99t supported, the issuer still provides a concrete =
identifier for the
> > authorization server that can be checked for equality.
> >
> > We talked about the value of that approach in the side meetings in
> > Yokohama and people were supportive then.
> >
> >                                                                  -- =
Mike
> >
> > *From:*OAuth [mailto:oauth-bounces@ietf.org =
] *On Behalf Of *John Bradley
> > *Sent:* Thursday, January 21, 2016 4:48 PM
> > *To:* Nat Sakimura >
> > *Cc:* oauth@ietf.org  WG >
> > *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up =
Mitigation
> >
> > I will point out for clarification that this would be like IdP =
discovery
> > in openID 2 that everyone did.  I think IdP not doing RP discovery =
in
> > openID 2 is a weak argument.
> >
> > There may be other evidence that RP will not do discovery, but if =
that
> > is the case why are we doing a OAuth discovery spec?
> >
> > Many people see your spec as discovery as well just in a different =
way.
> >
> > I think both ways can work, but doing both leaves too many options.
> >
> > John B.
> >
> >     On Jan 21, 2016, at 9:38 PM, Nat Sakimura 
> >     >> wrote:
> >
> >     Still doing the analysis. We spent 1.5 hours today with John,
> >     George, nov and me on the OpenID Connect WG call on this issue. =
John
> >     explained the mitigation, but none of us was convinced that it =
works.
> >
> >     Then, after the call, I and nov went on with various scenarios. =
The
> >     interim conclusion is that:
> >
> >       * client_id response parameter does not help. There are =
legitimate
> >         cases that client_id duplicates out there and we cannot ban =
that.
> >       * iss response parameter does not help unless the discovery is
> >         performed and the value of iss is checked against the value =
of
> >         OAuth issuer inside the document. (<- Discovery becomes
> >         mandatory. =46rom our experience on RP discovery step in =
OpenID
> >         2.0, chance of this being done properly seems to be rather =
slim.)
> >       * sending the state to the token endpoint helps in the case =
code
> >         was stollen, but code should not be stolen to start with.
> >
> >     Cheers,
> >
> >     Nat
> >
> >     2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John Bradley =

> >     >>:
> >
> >         There have been a lot of discussions. I think Hannes posted =
some
> >         minutes of the F2F meeting we had with the security =
researchers.
> >
> >         The problem can=E2=80=99t be mitigated without some action =
on the client
> >         side.  It boils down to the client making a request to AS1 =
(From
> >         it=E2=80=99s perspective) and getting back a response from =
AS 2 (that it
> >         thinks is AS1)
> >
> >         This can be done if AS1 is a good AS but has it=E2=80=99s =
logs
> >         compromised so that an attacker can read them. Hans Zandbelt
> >         built a proof of concept for the attack.
> >
> >         In some cases the attacker gets the code and the credential =
to
> >         use it at the good AS token endpoint and in others it just =
gets
> >         the code and can replay that at the client to extract
> >         information from the API through the client by binding the =
api
> >         access to a new account.
> >
> >         PKCE unfortunately mitigates a different attack, where the
> >         client is impersonated and trys to replay a intercepted =
code.
> >         It however assumes the token endpoint is good, and is no =
help in
> >         the case of a compromised token endpoint.
> >
> >         The client in these attacks is vulnerable because it relies =
on
> >         some local state, or the value of the state parameter to =
know
> >         who the response is coming from.  This allows a =
authorization
> >         request that is intercepted to be used to create a new =
request
> >         in that browser to a different AS, or trick the client into
> >         using a Authorization endpoint for a different authorization =
server.
> >
> >         One problem is that OAuth doesn=E2=80=99t really have a =
unified concept
> >         of what a AS is.  Traditionally it is a Authorization =
endpoint
> >         URI, token end point URI and resource server URI that some =
one
> >         gives the client in some documentation.
> >
> >         As ling as a client only talks to one AS then there is no
> >         problem.   However once a client is configured to talk to =
more
> >         than one AS, we have problems if one of those AS lies about =
it=E2=80=99s
> >         endpoints, or is compromised and used to attack another AS.  =
 As
> >         a design goal you don=E2=80=99t want the overall  security =
to be limited
> >         by the weakest system.
> >
> >         One approach as Nat promotes is to have the authorization
> >         endpoint return the next hop, token endpoint for code or RS =
URI
> >         for token. The token endpoint must also return the RS URI or =
the
> >         client must push the RS URI to the token endpoint or the
> >         attacker just replaces the RS URI in the config and captures =
the
> >         token that way.
> >
> >         The other way is to provide a name for each AS as part of
> >         registration and the client not allow duplicate =
registrations
> >         with the same name.  When the response comes back the client
> >         checks the name against the one it made the request to. If =
the
> >         name dereferences to a discovery document then the client =
can
> >         check that name at registration or runtime to validate the =
net hops.
> >
> >         I think the two approaches mitigate the attack in similar =
ways.
> >         Nat=E2=80=99s is more REST friendly and returns the next hop =
as a
> >         parameter of header.
> >
> >         The one Mike and I wrote up based on the meeting in Germany
> >         provides identifiers (iss and client_id) that can be checked =
for
> >         validity in the simple case and be dereferenced via =
.well-known
> >         to get the information Nat=E2=80=99s proposal is providing.
> >
> >         Perhaps the main difference is Nat is using the token =
endpoint
> >         as the identifier for the AS and Mike=E2=80=99s is using =
location for a
> >         discovery document as the identifier.
> >
> >         I don=E2=80=99t recall the reasons using the token endpoint =
as the
> >         identifier was rejected at the meeting.  Perhaps others can =
post
> >         the reasons.
> >
> >         We need to close on this quickly, otherwise if we are =
indecisive
> >         fixes will not go into products for another year or so until
> >         this is a RFC.
> >
> >         That is my main concern.
> >
> >         John B.
> >
> >             On Jan 21, 2016, at 11:50 AM, Josh Mandel =

> >             >> =
wrote:
> >
> >             Thanks Nat - that's helpful. If both mitigations *can* =
work
> >             effectively, then I would like to see this group =
consider
> >             the decision between them carefully (if that hasn't =
happened
> >             yet). Again, don't hesitate to let me know if this is =
the
> >             wrong place/time for such discussion.
> >
> >             At a high level, I would rather ask server developers to =
do
> >             some "coding", for two reasons:
> >
> >             1. Most OAuth servers talk to many, many clients. So
> >             consolidating the security critical work in one place
> >             (server) is a net savings of work (rather than asking =
each
> >             client to implement these checks.
> >
> >             2. OAuth server developers are typically more =
sophisticated
> >             than client developers, and therefore more likely to
> >             understand the implications and more likely to get these
> >             critical details correct. Asking each client developer =
to do
> >             something right is likely to result in heterogenius
> >             implementation and persistent security holes. But if the
> >             server does the heavy lifting, and clients just have to =
pass
> >             along an extra parameter, this is more likely to see
> >             consistent implementation (for example, clients will =
fail to
> >             work if misconfigured, which will prompt developers to =
fix
> >             them).
> >
> >             On Jan 21, 2016 09:40, "Nat Sakimura" =

> >             >> =
wrote:
> >
> >                 Hi Josh,
> >
> >                 It is similar but slightly different IMHO.
> >
> >                 Section 4.6.4 of the RFC6819 is the access token
> >                 phishing by a counterfeit resource server.
> >
> >                 The mix-up attack described here is the code =
phishing by
> >                 a counterfeit token endpoint.
> >
> >                 In my view, both can be mitigated by the server
> >                 returning the next step: i.e., authorization =
endpoint
> >                 returning the legitimate token endpoint uri, and =
token
> >                 endpoint returning legitimate resource endpoint =
uris.
> >                 This involves no discovery endpoint, which is good.
> >
> >                 Your way also works. It is just the reverse of my
> >                 proposal. The difference being that my proposal does =
not
> >                 need any coding on the server but just =
configuration,
> >                 and it can return more metadata if needed.
> >
> >                 Cheers,
> >
> >                 Nat
> >
> >                 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 =
Josh Mandel 
> >                 >>:
> >
> >                     Apologies if this is the wrong forum for my =
comment
> >                     (and please direct me to the appropriate place =
in
> >                     that case), but I have two questions about the
> >                     propose mitigation (and the thinking behind it) =
that
> >                     I think the write-up could address:
> >
> >                     1. Could the writeup clarify whether/how the =
primary
> >                     "mixup" threat differs from what RFC6819 =
identifies
> >                     as in section 4.6.4?
> >
> >                     2. Has the workgroup considered a mitigation =
that
> >                     puts more responsibility on the authorization
> >                     server, and less on the client? For example, if
> >                     would be helpful for the writeup to clarify why
> >                     having the client send an "audience field" (in =
the
> >                     terminology of RFC6819) to the authorization
> >                     endpoint would not mitigate the threat. (In that
> >                     scenario, the authorization server can recognize
> >                     that the audience does not correspond to a =
resource
> >                     server it knows, rather than asking clients to =
make
> >                     this check). I assume this approach has been
> >                     considered and rejected as an incomplete =
mitigation,
> >                     but I don't have visibility into where/how that
> >                     discussion went.
> >
> >                     Thanks,
> >
> >                     Josh
> >
> >                     Hi all,
> >
> >                     this is the call for adoption of OAuth 2.0 =
Mix-Up
> >                     Mitigation, see
> >                     =
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 =

> >
> >                     Please let us know by Feb 9th whether you accept =
/
> >                     object to the
> >                     adoption of this document as a starting point =
for
> >                     work in the OAuth
> >                     working group.
> >
> >                     Note: This call is related to the announcement =
made
> >                     on the list earlier
> >                     this month, see
> >                     =
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html =
.
> >                     More
> >                     time for analysis is provided due to the =
complexity
> >                     of the topic.
> >
> >                     Ciao
> >                     Hannes & Derek
> >
> >
> >                     _______________________________________________
> >                     OAuth mailing list
> >                     OAuth@ietf.org  =
>
> >                     https://www.ietf.org/mailman/listinfo/oauth =

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

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

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

> >
>=20
> --
> Hans Zandbelt              | Sr. Technical Architect
> hzandbelt@pingidentity.com  | Ping =
Identity
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_2CDED874-9E7C-4C60-8E6E-61A273DE1ACA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hum, even if the client uses different redirect_uri per each =
IdP, code phishing attack succeeds in Nat=E2=80=99s sample attack =
scenario.
In such scenario, returning AuthZ endpoint URI =
as AuthZ response also won=E2=80=99t help.

So it seems returning =
=E2=80=9Ciss" (with discovery support) or oauth-meta is MUST for such =
case.

On Jan 24, 2016, at 07:52, Nat =
Sakimura <sakimura@gmail.com> wrote:

Since we have been =
discussing in another thread and you guys may be a aware of it in this =
thread, here is one of the problem statement for the mix-up draft =
explaining why it does not solve the problem as it is written now. 

It can be fixed to solve the problem, but then =
the overhead size will be much larger and involves an extra round trip =
compared to oauth-meta draft. 

See http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oaut=
h-2-0-rfc6749/ for the details. 

Nat
2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 18:11 Hans =
Zandbelt <hzandbelt@pingidentity.com>:
+1 to everything Mike =
stated



Hans.



On 1/22/16 2:04 AM, Mike Jones wrote:

> I believe that it=E2=80=99s simpler and more elegant to return an =
issuer, from

> which the discovery metadata document can be retrieved, which =
contains

> **all** the configuration information about the authorization =
server,

> than to return some of the configuration parameters but not most of =
them

> (which is what the oauth-meta proposal does).  There=E2=80=99s =
lots more in a

> typical discovery document than just a few endpoint addresses. =
For

> instance, there are statements about what response types are =
supported,

> other configuration choices, keys, etc.

>

> I also think that returning the issuer is more future-proof than =
trying

> to decide now what all the configuration information is that might =
want

> to be verified by the client and hoping we get it right.  With =
the

> issuer, assuming that discovery is supported, it can retrieve and =
check

> all of it, should the client want/need to do so.  Even when =
discovery

> isn=E2=80=99t supported, the issuer still provides a concrete =
identifier for the

> authorization server that can be checked for equality.
=

>

> We talked about the value of that approach in the side meetings =
in

> Yokohama and people were supportive then.

>

>                  =
                    =
                    =
        -- Mike

>

> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of =
*John Bradley

> *Sent:* Thursday, January 21, 2016 4:48 PM

> *To:* Nat Sakimura <sakimura@gmail.com>

> *Cc:* oauth@ietf.org WG <oauth@ietf.org>

> *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up =
Mitigation

>

> I will point out for clarification that this would be like IdP =
discovery

> in openID 2 that everyone did.  I think IdP not doing RP =
discovery in

> openID 2 is a weak argument.

>

> There may be other evidence that RP will not do discovery, but if =
that

> is the case why are we doing a OAuth discovery spec?

>

> Many people see your spec as discovery as well just in a different =
way.

>

> I think both ways can work, but doing both leaves too many =
options.

>

> John B.

>

>     On Jan 21, 2016, at 9:38 PM, Nat Sakimura <sakimura@gmail.com

>     <mailto:sakimura@gmail.com>> wrote:

>

>     Still doing the analysis. We spent 1.5 hours =
today with John,

>     George, nov and me on the OpenID Connect WG call =
on this issue. John

>     explained the mitigation, but none of us was =
convinced that it works.

>

>     Then, after the call, I and nov went on with =
various scenarios. The

>     interim conclusion is that:

>

>       * client_id response parameter does not =
help. There are legitimate

>         cases that client_id duplicates =
out there and we cannot ban that.

>       * iss response parameter does not help =
unless the discovery is

>         performed and the value of iss is =
checked against the value of

>         OAuth issuer inside the document. =
(<- Discovery becomes

>         mandatory. =46rom our experience =
on RP discovery step in OpenID

>         2.0, chance of this being done =
properly seems to be rather slim.)

>       * sending the state to the token endpoint =
helps in the case code

>         was stollen, but code should not =
be stolen to start with.

>

>     Cheers,

>

>     Nat

>

>     2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) =
7:59 John Bradley <ve7jtb@ve7jtb.com

>     <mailto:ve7jtb@ve7jtb.com>>:
=

>

>         There have been a lot of =
discussions. I think Hannes posted some

>         minutes of the F2F meeting we had =
with the security researchers.

>

>         The problem can=E2=80=99t be =
mitigated without some action on the client

>         side.  It boils down to the =
client making a request to AS1 (From

>         it=E2=80=99s perspective) and =
getting back a response from AS 2 (that it

>         thinks is AS1)

>

>         This can be done if AS1 is a good =
AS but has it=E2=80=99s logs

>         compromised so that an attacker =
can read them. Hans Zandbelt

>         built a proof of concept for the =
attack.

>

>         In some cases the attacker gets =
the code and the credential to

>         use it at the good AS token =
endpoint and in others it just gets

>         the code and can replay that at =
the client to extract

>         information from the API through =
the client by binding the api

>         access to a new account.

>

>         PKCE unfortunately mitigates a =
different attack, where the

>         client is impersonated and trys to =
replay a intercepted code.

>         It however assumes the token =
endpoint is good, and is no help in

>         the case of a compromised token =
endpoint.

>

>         The client in these attacks is =
vulnerable because it relies on

>         some local state, or the value of =
the state parameter to know

>         who the response is coming =
from.  This allows a authorization

>         request that is intercepted to be =
used to create a new request

>         in that browser to a different AS, =
or trick the client into

>         using a Authorization endpoint for =
a different authorization server.

>

>         One problem is that OAuth =
doesn=E2=80=99t really have a unified concept

>         of what a AS is.  =
Traditionally it is a Authorization endpoint

>         URI, token end point URI and =
resource server URI that some one

>         gives the client in some =
documentation.

>

>         As ling as a client only talks to =
one AS then there is no

>         problem.   However once =
a client is configured to talk to more

>         than one AS, we have problems if =
one of those AS lies about it=E2=80=99s

>         endpoints, or is compromised and =
used to attack another AS.   As

>         a design goal you don=E2=80=99t =
want the overall  security to be limited

>         by the weakest system.

>

>         One approach as Nat promotes is to =
have the authorization

>         endpoint return the next hop, =
token endpoint for code or RS URI

>         for token. The token endpoint must =
also return the RS URI or the

>         client must push the RS URI to the =
token endpoint or the

>         attacker just replaces the RS URI =
in the config and captures the

>         token that way.

>

>         The other way is to provide a name =
for each AS as part of

>         registration and the client not =
allow duplicate registrations

>         with the same name.  When the =
response comes back the client

>         checks the name against the one it =
made the request to. If the

>         name dereferences to a discovery =
document then the client can

>         check that name at registration or =
runtime to validate the net hops.

>

>         I think the two approaches =
mitigate the attack in similar ways.

>         Nat=E2=80=99s is more REST =
friendly and returns the next hop as a

>         parameter of header.

>

>         The one Mike and I wrote up based =
on the meeting in Germany

>         provides identifiers (iss and =
client_id) that can be checked for

>         validity in the simple case and be =
dereferenced via .well-known

>         to get the information Nat=E2=80=99s=
 proposal is providing.

>

>         Perhaps the main difference is Nat =
is using the token endpoint

>         as the identifier for the AS and =
Mike=E2=80=99s is using location for a

>         discovery document as the =
identifier.

>

>         I don=E2=80=99t recall the reasons =
using the token endpoint as the

>         identifier was rejected at the =
meeting.  Perhaps others can post

>         the reasons.

>

>         We need to close on this quickly, =
otherwise if we are indecisive

>         fixes will not go into products =
for another year or so until

>         this is a RFC.

>

>         That is my main concern.

>

>         John B.

>

>             On Jan 21, 2016, at =
11:50 AM, Josh Mandel <jmandel@gmail.com

>             <mailto:jmandel@gmail.com>> wrote:

>

>             Thanks Nat - that's =
helpful. If both mitigations *can* work

>             effectively, then I =
would like to see this group consider

>             the decision between =
them carefully (if that hasn't happened

>             yet). Again, don't =
hesitate to let me know if this is the

>             wrong place/time for =
such discussion.

>

>             At a high level, I =
would rather ask server developers to do

>             some "coding", for =
two reasons:

>

>             1. Most OAuth =
servers talk to many, many clients. So

>             consolidating the =
security critical work in one place

>             (server) is a net =
savings of work (rather than asking each

>             client to implement =
these checks.

>

>             2. OAuth server =
developers are typically more sophisticated

>             than client =
developers, and therefore more likely to

>             understand the =
implications and more likely to get these

>             critical details =
correct. Asking each client developer to do

>             something right is =
likely to result in heterogenius

>             implementation and =
persistent security holes. But if the

>             server does the =
heavy lifting, and clients just have to pass

>             along an extra =
parameter, this is more likely to see

>             consistent =
implementation (for example, clients will fail to

>             work if =
misconfigured, which will prompt developers to fix

>             them).

>

>             On Jan 21, 2016 =
09:40, "Nat Sakimura" <sakimura@gmail.com

>             <mailto:sakimura@gmail.com>> wrote:

>

>                 Hi =
Josh,

>

>                 It is =
similar but slightly different IMHO.

>

>                =
 Section 4.6.4 of the RFC6819 is the access token

>                =
 phishing by a counterfeit resource server.

>

>                 The =
mix-up attack described here is the code phishing by

>                 a =
counterfeit token endpoint.

>

>                 In my =
view, both can be mitigated by the server

>                =
 returning the next step: i.e., authorization endpoint
=

>                =
 returning the legitimate token endpoint uri, and token

>                =
 endpoint returning legitimate resource endpoint uris.
=

>                 This =
involves no discovery endpoint, which is good.

>

>                 Your =
way also works. It is just the reverse of my

>                =
 proposal. The difference being that my proposal does not

>                 need =
any coding on the server but just configuration,

>                 and it =
can return more metadata if needed.

>

>                =
 Cheers,

>

>                 Nat

>

>                =
 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel =
<jmandel@gmail.com

>                =
 <mailto:jmandel@gmail.com>>:

>

>                  =
   Apologies if this is the wrong forum for my comment

>                  =
   (and please direct me to the appropriate place in

>                  =
   that case), but I have two questions about the
=

>                  =
   propose mitigation (and the thinking behind it) that

>                  =
   I think the write-up could address:

>

>                  =
   1. Could the writeup clarify whether/how the primary

>                  =
   "mixup" threat differs from what RFC6819 identifies

>                  =
   as in section 4.6.4?

>

>                  =
   2. Has the workgroup considered a mitigation that

>                  =
   puts more responsibility on the authorization

>                  =
   server, and less on the client? For example, if

>                  =
   would be helpful for the writeup to clarify why

>                  =
   having the client send an "audience field" (in the

>                  =
   terminology of RFC6819) to the authorization

>                  =
   endpoint would not mitigate the threat. (In that

>                  =
   scenario, the authorization server can recognize

>                  =
   that the audience does not correspond to a resource

>                  =
   server it knows, rather than asking clients to make

>                  =
   this check). I assume this approach has been

>                  =
   considered and rejected as an incomplete mitigation,

>                  =
   but I don't have visibility into where/how that

>                  =
   discussion went.

>

>                  =
   Thanks,

>

>                  =
   Josh

>

>                  =
   Hi all,

>

>                  =
   this is the call for adoption of OAuth 2.0 Mix-Up

>                  =
   Mitigation, see

>                  =
   https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation=
-00

>

>                  =
   Please let us know by Feb 9th whether you accept /

>                  =
   object to the

>                  =
   adoption of this document as a starting point for

>                  =
   work in the OAuth

>                  =
   working group.

>

>                  =
   Note: This call is related to the announcement made

>                  =
   on the list earlier

>                  =
   this month, see

>                  =
   http://www.ietf.org/mail-archive/web/oauth/current/msg15336.htm=
l.

>                  =
   More

>                  =
   time for analysis is provided due to the complexity

>                  =
   of the topic.

>

>                  =
   Ciao

>                  =
   Hannes & Derek

>

>

>                  =
   _______________________________________________

>                  =
   OAuth mailing list

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

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

>

>                  =
   _______________________________________________

>                  =
   OAuth mailing list

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

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

>

>            =
 _______________________________________________

>             OAuth mailing =
list

>             OAuth@ietf.org <mailto:OAuth@ietf.org>

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

>

>

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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

>



--

Hans Zandbelt              | Sr. =
Technical Architect

hzandbelt@pingidentity.com | Ping Identity



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

=

--Apple-Mail=_2CDED874-9E7C-4C60-8E6E-61A273DE1ACA--


From nobody Mon Jan 25 00:42:02 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15A91B29FC for ; Mon, 25 Jan 2016 00:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKnrOb2FX62O for ; Mon, 25 Jan 2016 00:41:55 -0800 (PST)
Received: from p3plsmtpa11-10.prod.phx3.secureserver.net (p3plsmtpa11-10.prod.phx3.secureserver.net [68.178.252.111]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0861B29DE for ; Mon, 25 Jan 2016 00:41:54 -0800 (PST)
Received: from [192.168.0.16] ([82.11.82.125]) by p3plsmtpa11-10.prod.phx3.secureserver.net with  id A8hs1s0092iDvnW018htKB; Mon, 25 Jan 2016 01:41:54 -0700
To: oauth@ietf.org
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.com>  <56A1F249.3020307@pingidentity.com> 
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <56A5DFD0.4050902@connect2id.com>
Date: Mon, 25 Jan 2016 08:41:52 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030101070505030802020409"
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 08:42:00 -0000

This is a cryptographically signed message in MIME format.

--------------ms030101070505030802020409
Content-Type: multipart/alternative;
 boundary="------------070305070408070907050607"

This is a multi-part message in MIME format.
--------------070305070408070907050607
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The token endpoint mix-up attack was originally discussed in the context
of OIDC, in August 2015. Back then John Bradley noted that by simply
replacing Basic client authentication with JWT (client_secret_jwt or
private_key_jwt) the attack is successfully prevented. Yes, the authz
code will be captured, but the bogus AS will not be able to replay it
with the legitimate AS because the JWT used for client authentication is
bound (via the "aud" claim) to the original token endpoint.

https://bitbucket.org/openid/connect/issues/979/discovery-security-consid=
erations-csrf

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



Is this going to be added to the list of solutions? Its usefulness is
limited to confidential clients, but it's a good solution nevertheless.

JWT authentication helps in another case also - when the client by
mistake sends out the token request over plain HTTP.

Cheers,

Vladimir


On 23/01/16 22:52, Nat Sakimura wrote:
> Since we have been discussing in another thread and you guys may be a a=
ware
> of it in this thread, here is one of the problem statement for the mix-=
up
> draft explaining why it does not solve the problem as it is written now=
=2E
>
> It can be fixed to solve the problem, but then the overhead size will b=
e
> much larger and involves an extra round trip compared to oauth-meta dra=
ft.
>
> See
> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rf=
c6749/
> for the details.
>
> Nat
> 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 18:11 Hans Zandbelt :
>
>> +1 to everything Mike stated
>>
>> Hans.
>>
>> On 1/22/16 2:04 AM, Mike Jones wrote:
>>> I believe that it=E2=80=99s simpler and more elegant to return an iss=
uer, from
>>> which the discovery metadata document can be retrieved, which contain=
s
>>> **all** the configuration information about the authorization server,=

>>> than to return some of the configuration parameters but not most of t=
hem
>>> (which is what the oauth-meta proposal does).  There=E2=80=99s lots m=
ore in a
>>> typical discovery document than just a few endpoint addresses. For
>>> instance, there are statements about what response types are supporte=
d,
>>> other configuration choices, keys, etc.
>>>
>>> I also think that returning the issuer is more future-proof than tryi=
ng
>>> to decide now what all the configuration information is that might wa=
nt
>>> to be verified by the client and hoping we get it right.  With the
>>> issuer, assuming that discovery is supported, it can retrieve and che=
ck
>>> all of it, should the client want/need to do so.  Even when discovery=

>>> isn=E2=80=99t supported, the issuer still provides a concrete identif=
ier for the
>>> authorization server that can be checked for equality.
>>>
>>> We talked about the value of that approach in the side meetings in
>>> Yokohama and people were supportive then.
>>>
>>>                                                                  -- M=
ike
>>>
>>> *From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Brad=
ley
>>> *Sent:* Thursday, January 21, 2016 4:48 PM
>>> *To:* Nat Sakimura 
>>> *Cc:* oauth@ietf.org WG 
>>> *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigat=
ion
>>>
>>> I will point out for clarification that this would be like IdP discov=
ery
>>> in openID 2 that everyone did.  I think IdP not doing RP discovery in=

>>> openID 2 is a weak argument.
>>>
>>> There may be other evidence that RP will not do discovery, but if tha=
t
>>> is the case why are we doing a OAuth discovery spec?
>>>
>>> Many people see your spec as discovery as well just in a different wa=
y.
>>>
>>> I think both ways can work, but doing both leaves too many options.
>>>
>>> John B.
>>>
>>>     On Jan 21, 2016, at 9:38 PM, Nat Sakimura >>     > wrote:
>>>
>>>     Still doing the analysis. We spent 1.5 hours today with John,
>>>     George, nov and me on the OpenID Connect WG call on this issue. J=
ohn
>>>     explained the mitigation, but none of us was convinced that it wo=
rks.
>>>
>>>     Then, after the call, I and nov went on with various scenarios. T=
he
>>>     interim conclusion is that:
>>>
>>>       * client_id response parameter does not help. There are legitim=
ate
>>>         cases that client_id duplicates out there and we cannot ban t=
hat.
>>>       * iss response parameter does not help unless the discovery is
>>>         performed and the value of iss is checked against the value o=
f
>>>         OAuth issuer inside the document. (<- Discovery becomes
>>>         mandatory. From our experience on RP discovery step in OpenID=

>>>         2.0, chance of this being done properly seems to be rather sl=
im.)
>>>       * sending the state to the token endpoint helps in the case cod=
e
>>>         was stollen, but code should not be stolen to start with.
>>>
>>>     Cheers,
>>>
>>>     Nat
>>>
>>>     2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John Bradley <=
ve7jtb@ve7jtb.com
>>>     >:
>>>
>>>         There have been a lot of discussions. I think Hannes posted s=
ome
>>>         minutes of the F2F meeting we had with the security researche=
rs.
>>>
>>>         The problem can=E2=80=99t be mitigated without some action on=
 the client
>>>         side.  It boils down to the client making a request to AS1 (F=
rom
>>>         it=E2=80=99s perspective) and getting back a response from AS=
 2 (that it
>>>         thinks is AS1)
>>>
>>>         This can be done if AS1 is a good AS but has it=E2=80=99s log=
s
>>>         compromised so that an attacker can read them. Hans Zandbelt
>>>         built a proof of concept for the attack.
>>>
>>>         In some cases the attacker gets the code and the credential t=
o
>>>         use it at the good AS token endpoint and in others it just ge=
ts
>>>         the code and can replay that at the client to extract
>>>         information from the API through the client by binding the ap=
i
>>>         access to a new account.
>>>
>>>         PKCE unfortunately mitigates a different attack, where the
>>>         client is impersonated and trys to replay a intercepted code.=

>>>         It however assumes the token endpoint is good, and is no help=
 in
>>>         the case of a compromised token endpoint.
>>>
>>>         The client in these attacks is vulnerable because it relies o=
n
>>>         some local state, or the value of the state parameter to know=

>>>         who the response is coming from.  This allows a authorization=

>>>         request that is intercepted to be used to create a new reques=
t
>>>         in that browser to a different AS, or trick the client into
>>>         using a Authorization endpoint for a different authorization
>> server.
>>>         One problem is that OAuth doesn=E2=80=99t really have a unifi=
ed concept
>>>         of what a AS is.  Traditionally it is a Authorization endpoin=
t
>>>         URI, token end point URI and resource server URI that some on=
e
>>>         gives the client in some documentation.
>>>
>>>         As ling as a client only talks to one AS then there is no
>>>         problem.   However once a client is configured to talk to mor=
e
>>>         than one AS, we have problems if one of those AS lies about i=
t=E2=80=99s
>>>         endpoints, or is compromised and used to attack another AS.  =
 As
>>>         a design goal you don=E2=80=99t want the overall  security to=
 be limited
>>>         by the weakest system.
>>>
>>>         One approach as Nat promotes is to have the authorization
>>>         endpoint return the next hop, token endpoint for code or RS U=
RI
>>>         for token. The token endpoint must also return the RS URI or =
the
>>>         client must push the RS URI to the token endpoint or the
>>>         attacker just replaces the RS URI in the config and captures =
the
>>>         token that way.
>>>
>>>         The other way is to provide a name for each AS as part of
>>>         registration and the client not allow duplicate registrations=

>>>         with the same name.  When the response comes back the client
>>>         checks the name against the one it made the request to. If th=
e
>>>         name dereferences to a discovery document then the client can=

>>>         check that name at registration or runtime to validate the ne=
t
>> hops.
>>>         I think the two approaches mitigate the attack in similar way=
s.
>>>         Nat=E2=80=99s is more REST friendly and returns the next hop =
as a
>>>         parameter of header.
>>>
>>>         The one Mike and I wrote up based on the meeting in Germany
>>>         provides identifiers (iss and client_id) that can be checked =
for
>>>         validity in the simple case and be dereferenced via .well-kno=
wn
>>>         to get the information Nat=E2=80=99s proposal is providing.
>>>
>>>         Perhaps the main difference is Nat is using the token endpoin=
t
>>>         as the identifier for the AS and Mike=E2=80=99s is using loca=
tion for a
>>>         discovery document as the identifier.
>>>
>>>         I don=E2=80=99t recall the reasons using the token endpoint a=
s the
>>>         identifier was rejected at the meeting.  Perhaps others can p=
ost
>>>         the reasons.
>>>
>>>         We need to close on this quickly, otherwise if we are indecis=
ive
>>>         fixes will not go into products for another year or so until
>>>         this is a RFC.
>>>
>>>         That is my main concern.
>>>
>>>         John B.
>>>
>>>             On Jan 21, 2016, at 11:50 AM, Josh Mandel >>             > wrote:
>>>
>>>             Thanks Nat - that's helpful. If both mitigations *can* wo=
rk
>>>             effectively, then I would like to see this group consider=

>>>             the decision between them carefully (if that hasn't happe=
ned
>>>             yet). Again, don't hesitate to let me know if this is the=

>>>             wrong place/time for such discussion.
>>>
>>>             At a high level, I would rather ask server developers to =
do
>>>             some "coding", for two reasons:
>>>
>>>             1. Most OAuth servers talk to many, many clients. So
>>>             consolidating the security critical work in one place
>>>             (server) is a net savings of work (rather than asking eac=
h
>>>             client to implement these checks.
>>>
>>>             2. OAuth server developers are typically more sophisticat=
ed
>>>             than client developers, and therefore more likely to
>>>             understand the implications and more likely to get these
>>>             critical details correct. Asking each client developer to=
 do
>>>             something right is likely to result in heterogenius
>>>             implementation and persistent security holes. But if the
>>>             server does the heavy lifting, and clients just have to p=
ass
>>>             along an extra parameter, this is more likely to see
>>>             consistent implementation (for example, clients will fail=
 to
>>>             work if misconfigured, which will prompt developers to fi=
x
>>>             them).
>>>
>>>             On Jan 21, 2016 09:40, "Nat Sakimura" >>             > wrote:
>>>
>>>                 Hi Josh,
>>>
>>>                 It is similar but slightly different IMHO.
>>>
>>>                 Section 4.6.4 of the RFC6819 is the access token
>>>                 phishing by a counterfeit resource server.
>>>
>>>                 The mix-up attack described here is the code phishing=
 by
>>>                 a counterfeit token endpoint.
>>>
>>>                 In my view, both can be mitigated by the server
>>>                 returning the next step: i.e., authorization endpoint=

>>>                 returning the legitimate token endpoint uri, and toke=
n
>>>                 endpoint returning legitimate resource endpoint uris.=

>>>                 This involves no discovery endpoint, which is good.
>>>
>>>                 Your way also works. It is just the reverse of my
>>>                 proposal. The difference being that my proposal does =
not
>>>                 need any coding on the server but just configuration,=

>>>                 and it can return more metadata if needed.
>>>
>>>                 Cheers,
>>>
>>>                 Nat
>>>
>>>                 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 J=
osh Mandel >>                 >:
>>>
>>>                     Apologies if this is the wrong forum for my comme=
nt
>>>                     (and please direct me to the appropriate place in=

>>>                     that case), but I have two questions about the
>>>                     propose mitigation (and the thinking behind it) t=
hat
>>>                     I think the write-up could address:
>>>
>>>                     1. Could the writeup clarify whether/how the prim=
ary
>>>                     "mixup" threat differs from what RFC6819 identifi=
es
>>>                     as in section 4.6.4?
>>>
>>>                     2. Has the workgroup considered a mitigation that=

>>>                     puts more responsibility on the authorization
>>>                     server, and less on the client? For example, if
>>>                     would be helpful for the writeup to clarify why
>>>                     having the client send an "audience field" (in th=
e
>>>                     terminology of RFC6819) to the authorization
>>>                     endpoint would not mitigate the threat. (In that
>>>                     scenario, the authorization server can recognize
>>>                     that the audience does not correspond to a resour=
ce
>>>                     server it knows, rather than asking clients to ma=
ke
>>>                     this check). I assume this approach has been
>>>                     considered and rejected as an incomplete mitigati=
on,
>>>                     but I don't have visibility into where/how that
>>>                     discussion went.
>>>
>>>                     Thanks,
>>>
>>>                     Josh
>>>
>>>                     Hi all,
>>>
>>>                     this is the call for adoption of OAuth 2.0 Mix-Up=

>>>                     Mitigation, see
>>>
>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00
>>>                     Please let us know by Feb 9th whether you accept =
/
>>>                     object to the
>>>                     adoption of this document as a starting point for=

>>>                     work in the OAuth
>>>                     working group.
>>>
>>>                     Note: This call is related to the announcement ma=
de
>>>                     on the list earlier
>>>                     this month, see
>>>
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html.
>>>                     More
>>>                     time for analysis is provided due to the complexi=
ty
>>>                     of the topic.
>>>
>>>                     Ciao
>>>                     Hannes & Derek
>>>
>>>
>>>                     _______________________________________________
>>>                     OAuth mailing list
>>>                     OAuth@ietf.org 
>>>                     https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>                     _______________________________________________
>>>                     OAuth mailing list
>>>                     OAuth@ietf.org 
>>>                     https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>             _______________________________________________
>>>             OAuth mailing list
>>>             OAuth@ietf.org 
>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>> --
>> Hans Zandbelt              | Sr. Technical Architect
>> hzandbelt@pingidentity.com | Ping Identity
>>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

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


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


  
    
  
  
    The token endpoint mix-up attack was originally discussed in the
    context of OIDC, in August 2015. Back then John Bradley noted that
    by simply replacing Basic client authentication with JWT
    (client_secret_jwt or private_key_jwt) the attack is successfully
    prevented. Yes, the authz code will be captured, but the bogus AS
    will not be able to replay it with the legitimate AS because the JWT
    used for client authentication is bound (via the "aud" claim) to the
    original token endpoint.

    

https://bitbuck=
et.org/openid/connect/issues/979/discovery-security-considerations-csrf

    

http://openid.net/specs/open=
id-connect-core-1_0.html#ClientAuthentication

    

    

    Is this going to be added to the list of solutions? Its usefulness
    is limited to confidential clients, but it's a good solution
    nevertheless.

    

    JWT authentication helps in another case also - when the client by
    mistake sends out the token request over plain HTTP.

    

    Cheers,

    

    Vladimir

    

    

    
On 23/01/16 22:52, Nat Sakimura wrote:=


    

    

      
Since we have been discussing in another thread and =
you guys may be a aware
of it in this thread, here is one of the problem statement for the mix-up=

draft explaining why it does not solve the problem as it is written now.

It can be fixed to solve the problem, but then the overhead size will be
much larger and involves an extra round trip compared to oauth-meta draft=
=2E

See
http://nat.sakimura.org/=
2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
for the details.

Nat
2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 18:11 Hans Zandbelt &l=
t;hzandbelt@pingidentity.com>:



      

        
+1 to everything Mike stated

Hans.

On 1/22/16 2:04 AM, Mike Jones wrote:


        

          
I believe that it=E2=80=99s simpler and more ele=
gant to return an issuer, from
which the discovery metadata document can be retrieved, which contains
**all** the configuration information about the authorization server,
than to return some of the configuration parameters but not most of them
(which is what the oauth-meta proposal does).  There=E2=80=99s lots more =
in a
typical discovery document than just a few endpoint addresses. For
instance, there are statements about what response types are supported,
other configuration choices, keys, etc.

I also think that returning the issuer is more future-proof than trying
to decide now what all the configuration information is that might want
to be verified by the client and hoping we get it right.  With the
issuer, assuming that discovery is supported, it can retrieve and check
all of it, should the client want/need to do so.  Even when discovery
isn=E2=80=99t supported, the issuer still provides a concrete identifier =
for the
authorization server that can be checked for equality.

We talked about the value of that approach in the side meetings in
Yokohama and people were supportive then.

                                                                 -- Mike

*From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bra=
dley
*Sent:* Thursday, January 21, 2016 4:48 PM
*To:* Nat Sakimura <sakimura@gmail.com>
*Cc:* oauth@ietf.org WG <oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

I will point out for clarification that this would be like IdP discovery
in openID 2 that everyone did.  I think IdP not doing RP discovery in
openID 2 is a weak argument.

There may be other evidence that RP will not do discovery, but if that
is the case why are we doing a OAuth discovery spec?

Many people see your spec as discovery as well just in a different way.

I think both ways can work, but doing both leaves too many options.

John B.

    On Jan 21, 2016, at 9:38 PM, Nat Sakimura <sakimura@gmail.com
    <mailto:sakimura@gmail.com>> wrote:

    Still doing the analysis. We spent 1.5 hours today with John,
    George, nov and me on the OpenID Connect WG call on this issue. John
    explained the mitigation, but none of us was convinced that it works.=


    Then, after the call, I and nov went on with various scenarios. The
    interim conclusion is that:

      * client_id response parameter does not help. There are legitimate
        cases that client_id duplicates out there and we cannot ban that.=

      * iss response parameter does not help unless the discovery is
        performed and the value of iss is checked against the value of
        OAuth issuer inside the document. (<- Discovery becomes
        mandatory. From our experience on RP discovery step in OpenID
        2.0, chance of this being done properly seems to be rather slim.)=

      * sending the state to the token endpoint helps in the case code
        was stollen, but code should not be stolen to start with.

    Cheers,

    Nat

    2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John Bradley <<=
a class=3D"moz-txt-link-abbreviated" href=3D"mailto:ve7jtb@ve7jtb.com">ve=
7jtb@ve7jtb.com
    =
<mailto:ve7jtb@ve7jtb.com>>:

        There have been a lot of discussions. I think Hannes posted some
        minutes of the F2F meeting we had with the security researchers.

        The problem can=E2=80=99t be mitigated without some action on the=
 client
        side.  It boils down to the client making a request to AS1 (From
        it=E2=80=99s perspective) and getting back a response from AS 2 (=
that it
        thinks is AS1)

        This can be done if AS1 is a good AS but has it=E2=80=99s logs
        compromised so that an attacker can read them. Hans Zandbelt
        built a proof of concept for the attack.

        In some cases the attacker gets the code and the credential to
        use it at the good AS token endpoint and in others it just gets
        the code and can replay that at the client to extract
        information from the API through the client by binding the api
        access to a new account.

        PKCE unfortunately mitigates a different attack, where the
        client is impersonated and trys to replay a intercepted code.
        It however assumes the token endpoint is good, and is no help in
        the case of a compromised token endpoint.

        The client in these attacks is vulnerable because it relies on
        some local state, or the value of the state parameter to know
        who the response is coming from.  This allows a authorization
        request that is intercepted to be used to create a new request
        in that browser to a different AS, or trick the client into
        using a Authorization endpoint for a different authorization


        

        
server.


        

          
        One problem is that OAuth doesn=E2=80=99t really have a unified c=
oncept
        of what a AS is.  Traditionally it is a Authorization endpoint
        URI, token end point URI and resource server URI that some one
        gives the client in some documentation.

        As ling as a client only talks to one AS then there is no
        problem.   However once a client is configured to talk to more
        than one AS, we have problems if one of those AS lies about it=E2=
=80=99s
        endpoints, or is compromised and used to attack another AS.   As
        a design goal you don=E2=80=99t want the overall  security to be =
limited
        by the weakest system.

        One approach as Nat promotes is to have the authorization
        endpoint return the next hop, token endpoint for code or RS URI
        for token. The token endpoint must also return the RS URI or the
        client must push the RS URI to the token endpoint or the
        attacker just replaces the RS URI in the config and captures the
        token that way.

        The other way is to provide a name for each AS as part of
        registration and the client not allow duplicate registrations
        with the same name.  When the response comes back the client
        checks the name against the one it made the request to. If the
        name dereferences to a discovery document then the client can
        check that name at registration or runtime to validate the net


        

        
hops.


        

          
        I think the two approaches mitigate the attack in similar ways.
        Nat=E2=80=99s is more REST friendly and returns the next hop as a=

        parameter of header.

        The one Mike and I wrote up based on the meeting in Germany
        provides identifiers (iss and client_id) that can be checked for
        validity in the simple case and be dereferenced via .well-known
        to get the information Nat=E2=80=99s proposal is providing.

        Perhaps the main difference is Nat is using the token endpoint
        as the identifier for the AS and Mike=E2=80=99s is using location=
 for a
        discovery document as the identifier.

        I don=E2=80=99t recall the reasons using the token endpoint as th=
e
        identifier was rejected at the meeting.  Perhaps others can post
        the reasons.

        We need to close on this quickly, otherwise if we are indecisive
        fixes will not go into products for another year or so until
        this is a RFC.

        That is my main concern.

        John B.

            On Jan 21, 2016, at 11:50 AM, Josh Mandel <jmandel@gmail.co=
m
            <mailto:jmandel@gmail.com>> wrote:

            Thanks Nat - that's helpful. If both mitigations *can* work
            effectively, then I would like to see this group consider
            the decision between them carefully (if that hasn't happened
            yet). Again, don't hesitate to let me know if this is the
            wrong place/time for such discussion.

            At a high level, I would rather ask server developers to do
            some "coding", for two reasons:

            1. Most OAuth servers talk to many, many clients. So
            consolidating the security critical work in one place
            (server) is a net savings of work (rather than asking each
            client to implement these checks.

            2. OAuth server developers are typically more sophisticated
            than client developers, and therefore more likely to
            understand the implications and more likely to get these
            critical details correct. Asking each client developer to do
            something right is likely to result in heterogenius
            implementation and persistent security holes. But if the
            server does the heavy lifting, and clients just have to pass
            along an extra parameter, this is more likely to see
            consistent implementation (for example, clients will fail to
            work if misconfigured, which will prompt developers to fix
            them).

            On Jan 21, 2016 09:40, "Nat Sakimura" <sakimura@gmail.com<=
/a>
            <mailto:sakimura@gmail.com>> wrote:

                Hi Josh,

                It is similar but slightly different IMHO.

                Section 4.6.4 of the RFC6819 is the access token
                phishing by a counterfeit resource server.

                The mix-up attack described here is the code phishing by
                a counterfeit token endpoint.

                In my view, both can be mitigated by the server
                returning the next step: i.e., authorization endpoint
                returning the legitimate token endpoint uri, and token
                endpoint returning legitimate resource endpoint uris.
                This involves no discovery endpoint, which is good.

                Your way also works. It is just the reverse of my
                proposal. The difference being that my proposal does not
                need any coding on the server but just configuration,
                and it can return more metadata if needed.

                Cheers,

                Nat

                2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh =
Mandel <jmandel@gmail.com
                <mailto:jmandel@gmail.com>>:

                    Apologies if this is the wrong forum for my comment
                    (and please direct me to the appropriate place in
                    that case), but I have two questions about the
                    propose mitigation (and the thinking behind it) that
                    I think the write-up could address:

                    1. Could the writeup clarify whether/how the primary
                    "mixup" threat differs from what RFC6819 identifies
                    as in section 4.6.4?

                    2. Has the workgroup considered a mitigation that
                    puts more responsibility on the authorization
                    server, and less on the client? For example, if
                    would be helpful for the writeup to clarify why
                    having the client send an "audience field" (in the
                    terminology of RFC6819) to the authorization
                    endpoint would not mitigate the threat. (In that
                    scenario, the authorization server can recognize
                    that the audience does not correspond to a resource
                    server it knows, rather than asking clients to make
                    this check). I assume this approach has been
                    considered and rejected as an incomplete mitigation,
                    but I don't have visibility into where/how that
                    discussion went.

                    Thanks,

                    Josh

                    Hi all,

                    this is the call for adoption of OAuth 2.0 Mix-Up
                    Mitigation, see



        

        
https://tool=
s.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00


        

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

                    Note: This call is related to the announcement made
                    on the list earlier
                    this month, see



        

        
http://www.iet=
f.org/mail-archive/web/oauth/current/msg15336.html.


        

          
                    More
                    time for analysis is provided due to the complexity
                    of the topic.

                    Ciao
                    Hannes & Derek


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

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

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



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



        

        
--
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com | Ping Identity



      

      

      

      

      

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


    

    

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

  


--------------070305070408070907050607--

--------------ms030101070505030802020409
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+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAxMjUwODQxNTJaMC8GCSqGSIb3DQEJBDEiBCBjATwS8IOSs/9xk/8LaSoX8PAD/H4P
QaKycz4y61uLSDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQB4dcQi/EzQ
W2TeMGeMQ76KftYXJjvdPGGyCXldbmlBOcCrWkV0ypAKkwWwbrH6RBqFwCRUKI3nQco1Y660
FndTno0ZznVaS/bOXnkk8zxXS4a8YF6HhgyJCi8TEBja3kTkmQqbnyOHJjgq+Lmzr05Y5pgu
2aPkLCktYNBcOBU7RVY/e3J/0B49MRxxjzxZZV3Rq06kILYKcmEa1RggZ5mBduoL34Co4nfj
Rr0Txffc9HQU2aBCq5pptrPOK8o3oZyw9vHsOhI2njppq1wjWB+JjXir3JhAW8vvwghOifQF
kp6/0MtQfeMt7GGTrPTIXLZb4EwKyfZKgCzlutRGR2A/AAAAAAAA
--------------ms030101070505030802020409--


From nobody Mon Jan 25 01:52:32 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC771B29EC for ; Mon, 25 Jan 2016 01:52:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.609
X-Spam-Level: 
X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPbUoP970DuZ for ; Mon, 25 Jan 2016 01:52:25 -0800 (PST)
Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148571B2AEF for ; Mon, 25 Jan 2016 01:52:23 -0800 (PST)
Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs04.index.or.jp (Postfix) with SMTP id 883A7472EE2; Mon, 25 Jan 2016 18:52:22 +0900 (JST)
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea03.index.or.jp (unknown) with ESMTP id u0P9qMGn026353; Mon, 25 Jan 2016 18:52:22 +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 u0P9qMkU058039; Mon, 25 Jan 2016 18:52:22 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u0P9qMIZ058038; Mon, 25 Jan 2016 18:52:22 +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 u0P9qMtg058035; Mon, 25 Jan 2016 18:52:22 +0900
From: "Nat Sakimura" 
To: "'Vladimir Dzhuvinov'" , 
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.com>  <56A1F249.3020307@pingidentity.com>  <56A5DFD0.4050902@connect2id.com>
In-Reply-To: <56A5DFD0.4050902@connect2id.com>
Date: Mon, 25 Jan 2016 18:52:21 +0900
Message-ID: <021601d15756$15d13090$417391b0$@nri.co.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0217_01D157A1.85BFDD70"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQLKG9YKnAuG9iZkuteuVWaKAtPS6AHNDI0sAn71RDUB5QC36QMiMoQvAjAOt08BdybVJAJGd++6ARhElgYCv4d0zQI3XCPOnG/xNlA=
Content-Language: ja
X-MailAdviser: 20141126
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 09:52:31 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0217_01D157A1.85BFDD70
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Right, JWT client authentication prevents the =E2=80=9Ccode =
phishing=E2=80=9D. However, when you generalize it, it amounts to the =
phishing of any =E2=80=9Cbearer tokens=E2=80=9D, including not only =
code+client_secret pair but also access token against resources.=20

.=20

So, the general solution would either be:=20

=20

1)     Let the client know which endpoint is the legitimate endpoint to =
receive the token authoritatively; OR

2)     Stop using bearer tokens and move to PoP tokens.=20

=20

So, I did not deal with the JWT client authentication option in my blog =
post.=20

=20

Cheers,=20

=20

Nat

=20

=20

=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 =
Dzhuvinov
Sent: Monday, January 25, 2016 5:42 PM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

=20

The token endpoint mix-up attack was originally discussed in the context =
of OIDC, in August 2015. Back then John Bradley noted that by simply =
replacing Basic client authentication with JWT (client_secret_jwt or =
private_key_jwt) the attack is successfully prevented. Yes, the authz =
code will be captured, but the bogus AS will not be able to replay it =
with the legitimate AS because the JWT used for client authentication is =
bound (via the "aud" claim) to the original token endpoint.

https://bitbucket.org/openid/connect/issues/979/discovery-security-consid=
erations-csrf

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



Is this going to be added to the list of solutions? Its usefulness is =
limited to confidential clients, but it's a good solution nevertheless.

JWT authentication helps in another case also - when the client by =
mistake sends out the token request over plain HTTP.

Cheers,

Vladimir



On 23/01/16 22:52, Nat Sakimura wrote:

Since we have been discussing in another thread and you guys may be a =
aware
of it in this thread, here is one of the problem statement for the =
mix-up
draft explaining why it does not solve the problem as it is written now.
=20
It can be fixed to solve the problem, but then the overhead size will be
much larger and involves an extra round trip compared to oauth-meta =
draft.
=20
See
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6=
749/
for the details.
=20
Nat
2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 18:11 Hans Zandbelt  =
 :
=20

+1 to everything Mike stated
=20
Hans.
=20
On 1/22/16 2:04 AM, Mike Jones wrote:

I believe that it=E2=80=99s simpler and more elegant to return an =
issuer, from
which the discovery metadata document can be retrieved, which contains
**all** the configuration information about the authorization server,
than to return some of the configuration parameters but not most of them
(which is what the oauth-meta proposal does).  There=E2=80=99s lots more =
in a
typical discovery document than just a few endpoint addresses. For
instance, there are statements about what response types are supported,
other configuration choices, keys, etc.
=20
I also think that returning the issuer is more future-proof than trying
to decide now what all the configuration information is that might want
to be verified by the client and hoping we get it right.  With the
issuer, assuming that discovery is supported, it can retrieve and check
all of it, should the client want/need to do so.  Even when discovery
isn=E2=80=99t supported, the issuer still provides a concrete identifier =
for the
authorization server that can be checked for equality.
=20
We talked about the value of that approach in the side meetings in
Yokohama and people were supportive then.
=20
                                                                 -- Mike
=20
*From:*OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *John Bradley
*Sent:* Thursday, January 21, 2016 4:48 PM
*To:* Nat Sakimura   
*Cc:* oauth@ietf.org   WG  =
 
*Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
=20
I will point out for clarification that this would be like IdP discovery
in openID 2 that everyone did.  I think IdP not doing RP discovery in
openID 2 is a weak argument.
=20
There may be other evidence that RP will not do discovery, but if that
is the case why are we doing a OAuth discovery spec?
=20
Many people see your spec as discovery as well just in a different way.
=20
I think both ways can work, but doing both leaves too many options.
=20
John B.
=20
    On Jan 21, 2016, at 9:38 PM, Nat Sakimura =20
      > wrote:
=20
    Still doing the analysis. We spent 1.5 hours today with John,
    George, nov and me on the OpenID Connect WG call on this issue. John
    explained the mitigation, but none of us was convinced that it =
works.
=20
    Then, after the call, I and nov went on with various scenarios. The
    interim conclusion is that:
=20
      * client_id response parameter does not help. There are legitimate
        cases that client_id duplicates out there and we cannot ban =
that.
      * iss response parameter does not help unless the discovery is
        performed and the value of iss is checked against the value of
        OAuth issuer inside the document. (<- Discovery becomes
        mandatory. From our experience on RP discovery step in OpenID
        2.0, chance of this being done properly seems to be rather =
slim.)
      * sending the state to the token endpoint helps in the case code
        was stollen, but code should not be stolen to start with.
=20
    Cheers,
=20
    Nat
=20
    2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John Bradley =
=20
      >:
=20
        There have been a lot of discussions. I think Hannes posted some
        minutes of the F2F meeting we had with the security researchers.
=20
        The problem can=E2=80=99t be mitigated without some action on =
the client
        side.  It boils down to the client making a request to AS1 (From
        it=E2=80=99s perspective) and getting back a response from AS 2 =
(that it
        thinks is AS1)
=20
        This can be done if AS1 is a good AS but has it=E2=80=99s logs
        compromised so that an attacker can read them. Hans Zandbelt
        built a proof of concept for the attack.
=20
        In some cases the attacker gets the code and the credential to
        use it at the good AS token endpoint and in others it just gets
        the code and can replay that at the client to extract
        information from the API through the client by binding the api
        access to a new account.
=20
        PKCE unfortunately mitigates a different attack, where the
        client is impersonated and trys to replay a intercepted code.
        It however assumes the token endpoint is good, and is no help in
        the case of a compromised token endpoint.
=20
        The client in these attacks is vulnerable because it relies on
        some local state, or the value of the state parameter to know
        who the response is coming from.  This allows a authorization
        request that is intercepted to be used to create a new request
        in that browser to a different AS, or trick the client into
        using a Authorization endpoint for a different authorization

server.

=20
        One problem is that OAuth doesn=E2=80=99t really have a unified =
concept
        of what a AS is.  Traditionally it is a Authorization endpoint
        URI, token end point URI and resource server URI that some one
        gives the client in some documentation.
=20
        As ling as a client only talks to one AS then there is no
        problem.   However once a client is configured to talk to more
        than one AS, we have problems if one of those AS lies about =
it=E2=80=99s
        endpoints, or is compromised and used to attack another AS.   As
        a design goal you don=E2=80=99t want the overall  security to be =
limited
        by the weakest system.
=20
        One approach as Nat promotes is to have the authorization
        endpoint return the next hop, token endpoint for code or RS URI
        for token. The token endpoint must also return the RS URI or the
        client must push the RS URI to the token endpoint or the
        attacker just replaces the RS URI in the config and captures the
        token that way.
=20
        The other way is to provide a name for each AS as part of
        registration and the client not allow duplicate registrations
        with the same name.  When the response comes back the client
        checks the name against the one it made the request to. If the
        name dereferences to a discovery document then the client can
        check that name at registration or runtime to validate the net

hops.

=20
        I think the two approaches mitigate the attack in similar ways.
        Nat=E2=80=99s is more REST friendly and returns the next hop as =
a
        parameter of header.
=20
        The one Mike and I wrote up based on the meeting in Germany
        provides identifiers (iss and client_id) that can be checked for
        validity in the simple case and be dereferenced via .well-known
        to get the information Nat=E2=80=99s proposal is providing.
=20
        Perhaps the main difference is Nat is using the token endpoint
        as the identifier for the AS and Mike=E2=80=99s is using =
location for a
        discovery document as the identifier.
=20
        I don=E2=80=99t recall the reasons using the token endpoint as =
the
        identifier was rejected at the meeting.  Perhaps others can post
        the reasons.
=20
        We need to close on this quickly, otherwise if we are indecisive
        fixes will not go into products for another year or so until
        this is a RFC.
=20
        That is my main concern.
=20
        John B.
=20
            On Jan 21, 2016, at 11:50 AM, Josh Mandel =20
              > =
wrote:
=20
            Thanks Nat - that's helpful. If both mitigations *can* work
            effectively, then I would like to see this group consider
            the decision between them carefully (if that hasn't happened
            yet). Again, don't hesitate to let me know if this is the
            wrong place/time for such discussion.
=20
            At a high level, I would rather ask server developers to do
            some "coding", for two reasons:
=20
            1. Most OAuth servers talk to many, many clients. So
            consolidating the security critical work in one place
            (server) is a net savings of work (rather than asking each
            client to implement these checks.
=20
            2. OAuth server developers are typically more sophisticated
            than client developers, and therefore more likely to
            understand the implications and more likely to get these
            critical details correct. Asking each client developer to do
            something right is likely to result in heterogenius
            implementation and persistent security holes. But if the
            server does the heavy lifting, and clients just have to pass
            along an extra parameter, this is more likely to see
            consistent implementation (for example, clients will fail to
            work if misconfigured, which will prompt developers to fix
            them).
=20
            On Jan 21, 2016 09:40, "Nat Sakimura" =20
              > =
wrote:
=20
                Hi Josh,
=20
                It is similar but slightly different IMHO.
=20
                Section 4.6.4 of the RFC6819 is the access token
                phishing by a counterfeit resource server.
=20
                The mix-up attack described here is the code phishing by
                a counterfeit token endpoint.
=20
                In my view, both can be mitigated by the server
                returning the next step: i.e., authorization endpoint
                returning the legitimate token endpoint uri, and token
                endpoint returning legitimate resource endpoint uris.
                This involves no discovery endpoint, which is good.
=20
                Your way also works. It is just the reverse of my
                proposal. The difference being that my proposal does not
                need any coding on the server but just configuration,
                and it can return more metadata if needed.
=20
                Cheers,
=20
                Nat
=20
                2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh =
Mandel =20
                  >:
=20
                    Apologies if this is the wrong forum for my comment
                    (and please direct me to the appropriate place in
                    that case), but I have two questions about the
                    propose mitigation (and the thinking behind it) that
                    I think the write-up could address:
=20
                    1. Could the writeup clarify whether/how the primary
                    "mixup" threat differs from what RFC6819 identifies
                    as in section 4.6.4?
=20
                    2. Has the workgroup considered a mitigation that
                    puts more responsibility on the authorization
                    server, and less on the client? For example, if
                    would be helpful for the writeup to clarify why
                    having the client send an "audience field" (in the
                    terminology of RFC6819) to the authorization
                    endpoint would not mitigate the threat. (In that
                    scenario, the authorization server can recognize
                    that the audience does not correspond to a resource
                    server it knows, rather than asking clients to make
                    this check). I assume this approach has been
                    considered and rejected as an incomplete mitigation,
                    but I don't have visibility into where/how that
                    discussion went.
=20
                    Thanks,
=20
                    Josh
=20
                    Hi all,
=20
                    this is the call for adoption of OAuth 2.0 Mix-Up
                    Mitigation, see
=20

https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00

=20
                    Please let us know by Feb 9th whether you accept /
                    object to the
                    adoption of this document as a starting point for
                    work in the OAuth
                    working group.
=20
                    Note: This call is related to the announcement made
                    on the list earlier
                    this month, see
=20

http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html.

                    More
                    time for analysis is provided due to the complexity
                    of the topic.
=20
                    Ciao
                    Hannes & Derek
=20
=20
                    _______________________________________________
                    OAuth mailing list
                    OAuth@ietf.org    =
 
                    https://www.ietf.org/mailman/listinfo/oauth
=20
                    _______________________________________________
                    OAuth mailing list
                    OAuth@ietf.org    =
 
                    https://www.ietf.org/mailman/listinfo/oauth
=20
            _______________________________________________
            OAuth mailing list
            OAuth@ietf.org    =
 
            https://www.ietf.org/mailman/listinfo/oauth
=20
=20
=20
_______________________________________________
OAuth mailing list
OAuth@ietf.org =20
https://www.ietf.org/mailman/listinfo/oauth
=20

=20
--
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com   | Ping =
Identity
=20

=20






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





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

------=_NextPart_000_0217_01D157A1.85BFDD70
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


R=
ight, JWT client authentication prevents the =E2=80=9Ccode =
phishing=E2=80=9D. However, when you generalize it, it amounts to the =
phishing of any =E2=80=9Cbearer tokens=E2=80=9D, including not only =
code+client_secret pair but also access token against resources. =

.=
 
S=
o, the general solution would either be: 
<=
o:p> 
<=
span style=3D'mso-list:Ignore'>1)     L=
et the client know which endpoint is the legitimate endpoint to receive =
the token authoritatively; OR
<=
span style=3D'mso-list:Ignore'>2)     S=
top using bearer tokens and move to PoP tokens. 
<=
o:p> 
S=
o, I did not deal with the JWT client authentication option in my blog =
post. 
<=
o:p> 
C=
heers, 
<=
o:p> 
N=
at
<=
o:p> 
<=
o:p> 
<=
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=C2=A0 and delete this e-mail.
<=
o:p> 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Vladimir =
Dzhuvinov
Sent: Monday, January 25, 2016 5:42 PM
To: =
oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption: =
OAuth 2.0 Mix-Up Mitigation
 
The =
token endpoint mix-up attack was originally discussed in the context of =
OIDC, in August 2015. Back then John Bradley noted that by simply =
replacing Basic client authentication with JWT (client_secret_jwt or =
private_key_jwt) the attack is successfully prevented. Yes, the authz =
code will be captured, but the bogus AS will not be able to replay it =
with the legitimate AS because the JWT used for client authentication is =
bound (via the "aud" claim) to the original token =
endpoint.

https://bitbucket.org/openid/connect/issues/979/di=
scovery-security-considerations-csrf

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


Is this going to be added to the list of =
solutions? Its usefulness is limited to confidential clients, but it's a =
good solution nevertheless.

JWT authentication helps in another =
case also - when the client by mistake sends out the token request over =
plain =
HTTP.

Cheers,

Vladimir

On 23/01/16 22:52, Nat Sakimura =
wrote:
Since we have been discussing in another thread and you =
guys may be a aware
of it =
in this thread, here is one of the problem statement for the =
mix-up
draft explaining =
why it does not solve the problem as it is written =
now.
 
It =
can be fixed to solve the problem, but then the overhead size will =
be
much larger and =
involves an extra round trip compared to oauth-meta =
draft.
 
See
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-=
oauth-2-0-rfc6749/
for the details.
 
Nat
2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 18:11 Hans Zandbelt =
<hzandbelt@pingidentity.com=
>:
 
+1 to everything Mike =
stated
 
Hans.
 
On =
1/22/16 2:04 AM, Mike Jones wrote:
I =
believe that it=E2=80=99s simpler and more elegant to return an issuer, =
from
which the discovery =
metadata document can be retrieved, which =
contains
**all** the =
configuration information about the authorization =
server,
than to return =
some of the configuration parameters but not most of =
them
(which is what the =
oauth-meta proposal does).=C2=A0 There=E2=80=99s lots more in =
a
typical discovery =
document than just a few endpoint addresses. =
For
instance, there are =
statements about what response types are =
supported,
other =
configuration choices, keys, etc.
 
I =
also think that returning the issuer is more future-proof than =
trying
to decide now what =
all the configuration information is that might =
want
to be verified by =
the client and hoping we get it right.=C2=A0 With =
the
issuer, assuming that =
discovery is supported, it can retrieve and =
check
all of it, should =
the client want/need to do so.=C2=A0 Even when =
discovery
isn=E2=80=99t =
supported, the issuer still provides a concrete identifier for =
the
authorization server =
that can be checked for equality.
 
We =
talked about the value of that approach in the side meetings =
in
Yokohama and people =
were supportive then.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike
 
*From:*OAuth [mailto:oauth-bounces@ietf.org]=
 *On Behalf Of *John Bradley
*Sent:* Thursday, January 21, 2016 4:48 =
PM
*To:* Nat Sakimura <sakimura@gmail.com>
*Cc:* oauth@ietf.org WG <oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] Call for =
Adoption: OAuth 2.0 Mix-Up Mitigation
 
I =
will point out for clarification that this would be like IdP =
discovery
in openID 2 =
that everyone did.=C2=A0 I think IdP not doing RP discovery =
in
openID 2 is a weak =
argument.
 
There =
may be other evidence that RP will not do discovery, but if =
that
is the case why are =
we doing a OAuth discovery spec?
 
Many =
people see your spec as discovery as well just in a different =
way.
 
I =
think both ways can work, but doing both leaves too many =
options.
 
John =
B.
 
=C2=A0=C2=A0=C2=A0 On Jan 21, 2016, at 9:38 PM, Nat =
Sakimura <sakimura@gmail.com
=C2=A0=C2=A0=C2=A0 <mailto:sakimura@gmail.com>&=
gt; wrote:
 
=C2=A0=C2=A0=C2=A0 Still doing the analysis. We spent 1.5 =
hours today with John,
=C2=A0=C2=A0=C2=A0 George, nov and me on the OpenID Connect =
WG call on this issue. John
=C2=A0=C2=A0=C2=A0 explained the mitigation, but none of us =
was convinced that it works.
 
=C2=A0=C2=A0=C2=A0 Then, after the call, I and nov went on =
with various scenarios. The
=C2=A0=C2=A0=C2=A0 interim conclusion is =
that:
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * client_id response =
parameter does not help. There are =
legitimate
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cases that =
client_id duplicates out there and we cannot ban =
that.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * iss response parameter =
does not help unless the discovery is
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 performed and =
the value of iss is checked against the value =
of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth issuer =
inside the document. (<- Discovery =
becomes
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 mandatory. From =
our experience on RP discovery step in =
OpenID
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A02.0, chance of =
this being done properly seems to be rather =
slim.)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * sending the state to the =
token endpoint helps in the case code
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was stollen, but =
code should not be stolen to start =
with.
 
=C2=A0=C2=A0=C2=A0 =
Cheers,
 
=C2=A0=C2=A0=C2=A0 Nat
 
=C2=A0=C2=A0=C2=A0 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John Bradley =
<ve7jtb@ve7jtb.com=

=C2=A0=C2=A0=C2=A0 <mailto:ve7jtb@ve7jtb.com>>=
;:
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There have been =
a lot of discussions. I think Hannes posted =
some
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 minutes of the =
F2F meeting we had with the security =
researchers.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The problem =
can=E2=80=99t be mitigated without some action on the =
client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 side.=C2=A0 It =
boils down to the client making a request to AS1 =
(From
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it=E2=80=99s =
perspective) and getting back a response from AS 2 (that =
it
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 thinks is =
AS1)
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This can be done =
if AS1 is a good AS but has it=E2=80=99s =
logs
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 compromised so =
that an attacker can read them. Hans =
Zandbelt
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 built a proof of =
concept for the attack.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In some cases =
the attacker gets the code and the credential =
to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 use it at the =
good AS token endpoint and in others it just =
gets
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the code and can =
replay that at the client to extract
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 information from =
the API through the client by binding the =
api
 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0access to a new =
account.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PKCE =
unfortunately mitigates a different attack, where =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client is =
impersonated and trys to replay a intercepted =
code.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It however =
assumes the token endpoint is good, and is no help =
in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the case of a =
compromised token endpoint.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The client in =
these attacks is vulnerable because it relies =
on
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 some local =
state, or the value of the state parameter to =
know
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 who the response =
is coming from.=C2=A0 This allows a =
authorization
=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0request that is intercepted to be =
used to create a new request
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in that browser =
to a different AS, or trick the client =
into
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 using a =
Authorization endpoint for a different =
authorization
server.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 One problem is =
that OAuth doesn=E2=80=99t really have a unified =
concept
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of what a AS =
is.=C2=A0 Traditionally it is a Authorization =
endpoint
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 URI, token end =
point URI and resource server URI that some =
one
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 gives the client =
in some documentation.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As ling as a =
client only talks to one AS then there is =
no
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
problem.=C2=A0=C2=A0 However once a client is configured to talk to =
more
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 than one AS, we =
have problems if one of those AS lies about =
it=E2=80=99s
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 endpoints, or is =
compromised and used to attack another AS.=C2=A0=C2=A0 =
As
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0a design goal =
you don=E2=80=99t want the overall=C2=A0 security to be =
limited
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by the weakest =
system.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 One approach as =
Nat promotes is to have the =
authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 endpoint return =
the next hop, token endpoint for code or RS =
URI
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for token. The =
token endpoint must also return the RS URI or =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client must push =
the RS URI to the token endpoint or =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attacker just =
replaces the RS URI in the config and captures =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 token that =
way.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The other way is =
to provide a name for each AS as part =
of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 registration and =
the client not allow duplicate =
registrations
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 with the same =
name.=C2=A0 When the response comes back the =
client
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 checks the name =
against the one it made the request to. If =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 name =
dereferences to a discovery document then the client =
can
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 check that name =
at registration or runtime to validate the =
net
hops.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I think the two =
approaches mitigate the attack in similar =
ways.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Nat=E2=80=99s is =
more REST friendly and returns the next hop as =
a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 parameter of =
header.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The one Mike and =
I wrote up based on the meeting in =
Germany
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 provides =
identifiers (iss and client_id) that can be checked =
for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 validity in the =
simple case and be dereferenced via =
.well-known
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to get the =
information Nat=E2=80=99s proposal is =
providing.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Perhaps the main =
difference is Nat is using the token =
endpoint
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as the =
identifier for the AS and Mike=E2=80=99s is using location for =
a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 discovery =
document as the identifier.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I don=E2=80=99t =
recall the reasons using the token endpoint as =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identifier was =
rejected at the meeting.=C2=A0 Perhaps others can =
post
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the =
reasons.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We need to close =
on this quickly, otherwise if we are =
indecisive
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 fixes will not =
go into products for another year or so =
until
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this is a =
RFC.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 That is my main =
concern.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 John =
B.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 On Jan 21, 2016, at 11:50 AM, Josh Mandel <jmandel@gmail.com=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 <mailto:jmandel@gmail.com>>=
; wrote:
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Thanks Nat - that's helpful. If both mitigations *can* =
work
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 effectively, then I would like to see this group =
consider
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0the decision between them carefully (if =
that hasn't happened
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 yet). Again, don't hesitate to let me know if this is =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 wrong place/time for such =
discussion.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 At a high level, I would rather ask server developers to =
do
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 some "coding", for two =
reasons:
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 1. Most OAuth servers talk to many, many clients. =
So
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 consolidating the security critical work in one =
place
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 (server) is a net savings of work (rather than asking =
each
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0client to implement these =
checks.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 2. OAuth server developers are typically more =
sophisticated
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 than client developers, and therefore more likely =
to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 understand the implications and more likely to get =
these
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0critical details correct. Asking each client developer =
to do
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 something right is likely to result in =
heterogenius
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 implementation and persistent security holes. But if =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 server does the heavy lifting, and clients just have to =
pass
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 along an extra parameter, this is more likely to =
see
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 consistent implementation (for example, clients will fail =
to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 work if misconfigured, which will prompt developers to =
fix
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 them).
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 On Jan 21, 2016 09:40, "Nat Sakimura" <sakimura@gmail.com
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 <mailto:sakimura@gmail.com>&=
gt; wrote:
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi =
Josh,
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 It is similar but slightly different =
IMHO.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 4.6.4 of the RFC6819 is the =
access token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 phishing by a counterfeit resource =
server.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The mix-up attack described here is the =
code phishing by
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a counterfeit token =
endpoint.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In my view, both can be mitigated by the =
server
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 returning the next step: i.e., =
authorization endpoint
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 returning the legitimate token endpoint =
uri, and token
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 endpoint returning legitimate resource =
endpoint uris.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This involves no discovery endpoint, =
which is good.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Your way also works. It is just the =
reverse of my
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 proposal. The difference being that my =
proposal does not
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 need any coding on the server but just =
configuration,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and it can return more metadata if =
needed.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Cheers,
 
=C2=A0=C2=A0=C2=A0=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
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel =
<jmandel@gmail.com=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <mailto:jmandel@gmail.com>>=
;:
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Apologies if this =
is the wrong forum for my comment
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (and please =
direct me to the appropriate place in
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that case), but I =
have two questions about the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 propose =
mitigation (and the thinking behind it) =
that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I think the =
write-up could address:
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1. Could the =
writeup clarify whether/how the =
primary
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "mixup" =
threat differs from what RFC6819 =
identifies
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as in section =
4.6.4?
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 2. Has the =
workgroup considered a mitigation that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 puts more =
responsibility on the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server, and less =
on the client? For example, if
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 would be helpful =
for the writeup to clarify why
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 having the client =
send an "audience field" (in =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0termino=
logy of RFC6819) to the authorization
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 endpoint would =
not mitigate the threat. (In that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scenario, the =
authorization server can recognize
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that the audience =
does not correspond to a resource
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 server it knows, =
rather than asking clients to make
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this check). I =
assume this approach has been
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 considered and =
rejected as an incomplete mitigation,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 but I don't have =
visibility into where/how that
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 discussion =
went.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Thanks,
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Josh
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hi =
all,
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this is the call =
for adoption of OAuth 2.0 Mix-Up
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0Mitigation, =
see
 
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00=

 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Please let us =
know by Feb 9th whether you accept /
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0object to =
the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 adoption of this =
document as a starting point for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 work in the =
OAuth
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 working =
group.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Note: This call =
is related to the announcement made
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0on the list =
earlier
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this month, =
see
 
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
More
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 time for analysis =
is provided due to the complexity
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of the =
topic.
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Ciao
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hannes & =
Derek
 
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
_______________________________________________
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth mailing =
list
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0OAuth@ietf.org <mailto:OAuth@ietf.org>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0________________________________________=
_______
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth mailing =
list
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OAuth@ietf.org <mailto:OAuth@ietf.org>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org=
/mailman/listinfo/oauth
 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 =
_______________________________________________
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 OAuth mailing list
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 OAuth@ietf.org <mailto:OAuth@ietf.org>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 https://www.ietf.org=
/mailman/listinfo/oauth
 
 
 
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
=

https://www.ietf.org=
/mailman/listinfo/oauth
 
 
--
Hans =
Zandbelt=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 | Sr. Technical Architect
hzandbelt@pingidentity.com=
 | Ping Identity
 
 



_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
=

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


-- =

Vladimir Dzhuvinov :: vladimir@connect2id.com<=
/o:p>

------=_NextPart_000_0217_01D157A1.85BFDD70--


From nobody Mon Jan 25 06:11:38 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8DC81ACD0C for ; Mon, 25 Jan 2016 06:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-YD49h60qMi for ; Mon, 25 Jan 2016 06:11:32 -0800 (PST)
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 A56C91ACD02 for ; Mon, 25 Jan 2016 06:11:31 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id s68so54362028qkh.3 for ; Mon, 25 Jan 2016 06:11:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=C3Mx3LWglIko2y1L6rLleraqCa5VfADOra6cYLFKEyI=; b=QWYj92Oe+OseiwQGVPA2t6uLjOxXknKSLXzCwD1XeQu4iu8oN/92WPhhCszrINWSSF NPgha8gohzRTBmRpXY3T9p5ZbZY6LAIRgVBYKDlfRXRWQMPwwOSnVw6V6QfDvul3YnLs 5p1dWi5gX6Miy8qOv5R31MbKCNxWl9FMAy/r4UPIi3GFNLe1/s4knbCGek1H1OOY4jo4 k9RV+5/pEBIHsnzHZGKE86JXeAS0YMkKbPIdENimAJrDKoGjclEq32CthUwZXrkgNrFS 7qjQDXmDXDKvbrOZiczMc+4YVImWr/tQtumH458+JrCE0cDrfVzq1go04siGb806/da2 M1ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=C3Mx3LWglIko2y1L6rLleraqCa5VfADOra6cYLFKEyI=; b=d7CrnQ82tB6tO/BQmVEXUIWfLTRfU+J0grwpodasrEhSSd9EqKGnqGhhb4CjujKwwG LZ3etfIYLM3sB/MXoUhLaWwYRgo/qz7jB9bNWXpMPrdYFk8n+/7yvS0prGTEs0C3XREM dv0JqjtfcOlBToyrB1WueSJFkvhQdMDIXM7TRL/FpMnJZuSrH0RCoWaHoG8DbgXlzC1b khVBv9q9V9Nf5PAS8jsTsx6pTfgxaVkyvImV3K5IaoODtLFS+1xl/Rdkgjvl5qTwG+CD y09534i98ld5ryqLZjtsW4VHlS+5CnNU3VbNxBCUvpC7bVVrPoen0+PTMKn5SOdujXFD dkBA==
X-Gm-Message-State: AG10YOSYrUkiqCXiRBv3xRK/V9qSxIwK5UdTv9QQpeOswyNT9fNYvzKB62OZRHeI73Z9ww==
X-Received: by 10.55.15.79 with SMTP id z76mr21101359qkg.42.1453731090667; Mon, 25 Jan 2016 06:11:30 -0800 (PST)
Received: from [192.168.1.68] ([191.115.57.165]) by smtp.gmail.com with ESMTPSA id 107sm8786058qge.16.2016.01.25.06.11.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 06:11:29 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_5C460D1C-826D-4281-8A6F-43AC0AC989DC"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Mon, 25 Jan 2016 11:11:24 -0300
Message-Id: <995474C5-62E7-4310-84AF-A5EF1CDEA4DB@ve7jtb.com>
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com> 
To: William Denniss 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 14:11:35 -0000

--Apple-Mail=_5C460D1C-826D-4281-8A6F-43AC0AC989DC
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_CBC884D3-37F7-410C-B860-C1A8D8EE0146"


--Apple-Mail=_CBC884D3-37F7-410C-B860-C1A8D8EE0146
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The mixup attack where the client is confused about who the response is =
coming from is posable both by providing bad configuration information =
and by compromising a existing AS.

The point was that telling clients to only register with =E2=80=9Cgood=E2=80=
=9D AS or somehow validating the configuration information is not =
sufficient to stop the attack.

If a AS is completely compromised you would be able to do the same =
attack.   In principal the OAuth protocol should not intertwine the =
security of different AS so that if one is compromised it degrades the =
security of all the others.

You are correct that in the compromised log flow the RS would not be =
able to leak the token unless it is compromised as well or the =
introspection endpoint on the AS is.=20

Given that the log attack is just one example we do also want to cover =
the ones where a client is given bad discovery information with a evil =
RS.  =20

This RS attack is not dissimilar to the attack that Eran was concerned =
about  where a client starts at the RS and gets a insufficient_scope =
error and then goes to it=E2=80=99s AS and requests a token with a new =
scope.
This would also be an example of client becoming confused about who it =
is dealing with.  I recall that bearer took the URI of the Authorization =
endpoint URI out of the error response to prevent that.
It is also not the current pattern to start with the resource except in =
UMA that might have an issue (it is probably mitigated some other way =
George can comment, he know the UMA spec)

The ways that I can think of to avoid the confused client RS attack are:
1. Proof of Possession tokens.  That was Eran=E2=80=99s solution, and =
there are other good reasons to do it and the work is already chartered, =
but perhaps overkill for many applications.

2. AS based Discovery where the RS are listed in the AS discovery =
document.  This is what Connect provides with the =
=E2=80=9Cuserinfo_endpoint=E2=80=9D claim in discovery.   This depends =
on having a logical identifier for the AS.

3. Providing the URI of the resource the token is being requested for in =
the token request.  This is what the =E2=80=9Caud" parameter in POP key =
distribution is doing (that may wind up as a separate spec if adopted)

4. Providing the list of URI that the token can be used at in the =
response from the token endpoint.   This is basically Nat=E2=80=99s =
proposal.

Certainly some combination of them is also possible.

Connect provides mitigation for the mix up attack in some flows, =
specifically =E2=80=9Ccode id_token=E2=80=9D =E2=80=9Ctoken id_token=E2=80=
=9D and =E2=80=9Ccode token id_token=E2=80=9D.

The mitigation doesn=E2=80=99t work for the code flow, because the =
client sends the code to the token endpoint before it can validate the =
id_token.=20

Returning the iss and client_id from the authorization endpoint per =
Mike=E2=80=99s draft allows the client to reject the authorization =
response and not leak the code.

John B.

On Jan 25, 2016, at 1:11 AM, William Denniss  =
wrote:
>=20
>=20
> On Thu, Jan 21, 2016 at 2:59 PM, John Bradley > wrote:
> There have been a lot of discussions. I think Hannes posted some =
minutes of the F2F meeting we had with the security researchers.
>=20
> The problem can=E2=80=99t be mitigated without some action on the =
client side.  It boils down to the client making a request to AS1 (=46rom =
it=E2=80=99s perspective) and getting back a response from AS 2 (that it =
thinks is AS1)
>=20
> This can be done if AS1 is a good AS but has it=E2=80=99s logs =
compromised so that an attacker can read them. Hans Zandbelt built a =
proof of concept for the attack.=20
>=20
> So for mix-up, we're only talking about a compromised logs attack and =
not a completely compromised AS?
> =20
> In some cases the attacker gets the code and the credential to use it =
at the good AS token endpoint and in others it just gets the code and =
can replay that at the client to extract information from the API =
through the client by binding the api access to a new account.
>=20
> PKCE unfortunately mitigates a different attack, where the client is =
impersonated and trys to replay a intercepted code.  It however assumes =
the token endpoint is good, and is no help in the case of a compromised =
token endpoint.
>=20
> The client in these attacks is vulnerable because it relies on some =
local state, or the value of the state parameter to know who the =
response is coming from.  This allows a authorization request that is =
intercepted to be used to create a new request in that browser to a =
different AS, or trick the client into using a Authorization endpoint =
for a different authorization server.
>=20
> One problem is that OAuth doesn=E2=80=99t really have a unified =
concept of what a AS is.  Traditionally it is a Authorization endpoint =
URI, token end point URI and resource server URI that some one gives the =
client in some documentation.  =20
>=20
> As ling as a client only talks to one AS then there is no problem.   =
However once a client is configured to talk to more than one AS, we have =
problems if one of those AS lies about it=E2=80=99s endpoints, or is =
compromised and used to attack another AS.   As a design goal you =
don=E2=80=99t want the overall  security to be limited by the weakest =
system.
>=20
> One approach as Nat promotes is to have the authorization endpoint =
return the next hop, token endpoint for code or RS URI for token. The =
token endpoint must also return the RS URI or the client must push the =
RS URI to the token endpoint or the attacker just replaces the RS URI in =
the config and captures the token that way.=20
>=20
> I believe the RS URI would not be needed to defeat the compromised =
logs mix-up attack for the code flow. The client will send the client_id =
it got when registering at AS1 to the token endpoint returned by AS2 =
(using Nat's spec), which will then cause a failure due to client_id =
mis-match. So simply returning the "token_endpoint" URI in the AS2 =
authorization response would defeat the compromised-logs mix-up attack, =
would it not?=20
> =20
> The other way is to provide a name for each AS as part of registration =
and the client not allow duplicate registrations with the same name.  =
When the response comes back the client checks the name against the one =
it made the request to.  If the name dereferences to a discovery =
document then the client can check that name at registration or runtime =
to validate the net hops.
>=20
> I think the two approaches mitigate the attack in similar ways.  =
Nat=E2=80=99s is more REST friendly and returns the next hop as a =
parameter of header. =20
>=20
> The one Mike and I wrote up based on the meeting in Germany provides =
identifiers (iss and client_id) that can be checked for validity in the =
simple case and be dereferenced via .well-known to get the information =
Nat=E2=80=99s proposal is providing.
> =20
>=20
> Perhaps the main difference is Nat is using the token endpoint as the =
identifier for the AS and Mike=E2=80=99s is using location for a =
discovery document as the identifier.
>=20
> I don=E2=80=99t recall the reasons using the token endpoint as the =
identifier was rejected at the meeting.  Perhaps others can post the =
reasons.
>=20
> Can you help clarify something that I've yet to discern from the =
minutes, does OpenID Connect solve the mix-up attack by binding all the =
tokens together and to the issuer via the ID Token?
>=20
>=20
> We need to close on this quickly, otherwise if we are indecisive fixes =
will not go into products for another year or so until this is a RFC.
>=20
> That is my main concern.
>=20
> John B.
>=20
>=20
[snip]  For readability of a long thread.


--Apple-Mail=_CBC884D3-37F7-410C-B860-C1A8D8EE0146
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The mixup attack where the client is confused about who the =
response is coming from is posable both by providing bad configuration =
information and by compromising a existing AS.

The point was that telling clients to =
only register with =E2=80=9Cgood=E2=80=9D AS or somehow validating the =
configuration information is not sufficient to stop the =
attack.

If a =
AS is completely compromised you would be able to do the same attack. =
  In principal the OAuth protocol should not intertwine the =
security of different AS so that if one is compromised it degrades the =
security of all the others.

You are correct that in the compromised log flow the RS =
would not be able to leak the token unless it is compromised as well or =
the introspection endpoint on the AS is. 

Given that the log attack is just one =
example we do also want to cover the ones where a client is given bad =
discovery information with a evil RS.   

This RS attack is not =
dissimilar to the attack that Eran was concerned about  where a =
client starts at the RS and gets a insufficient_scope error and then =
goes to it=E2=80=99s AS and requests a token with a new scope.
This would also be an example of client becoming confused =
about who it is dealing with.  I recall that bearer took the URI of =
the Authorization endpoint URI out of the error response to prevent =
that.
It is also not the current pattern to start =
with the resource except in UMA that might have an issue (it is probably =
mitigated some other way George can comment, he know the UMA =
spec)

The ways =
that I can think of to avoid the confused client RS attack =
are:
1. Proof of Possession tokens.  That was =
Eran=E2=80=99s solution, and there are other good reasons to do it and =
the work is already chartered, but perhaps overkill for many =
applications.

2.=
 AS based Discovery where the RS are listed in the AS discovery =
document.  This is what Connect provides with the =
=E2=80=9Cuserinfo_endpoint=E2=80=9D claim in discovery.   This =
depends on having a logical identifier for the AS.

3. Providing the URI of =
the resource the token is being requested for in the token request. =
 This is what the =E2=80=9Caud" parameter in POP key distribution =
is doing (that may wind up as a separate spec if adopted)

4. Providing the list of =
URI that the token can be used at in the response from the token =
endpoint.   This is basically Nat=E2=80=99s proposal.

Certainly some =
combination of them is also possible.

Connect provides mitigation for the mix =
up attack in some flows, specifically =E2=80=9Ccode id_token=E2=80=9D =
=E2=80=9Ctoken id_token=E2=80=9D and =E2=80=9Ccode token =
id_token=E2=80=9D.

The mitigation doesn=E2=80=99t work for the code flow, =
because the client sends the code to the token endpoint before it can =
validate the id_token. 

Returning the iss and client_id from =
the authorization endpoint per Mike=E2=80=99s draft allows the client to =
reject the authorization response and not leak the code.

John B.

On Jan 25, 2016, at 1:11 =
AM, William Denniss <wdenniss@google.com> wrote:


On Thu, Jan 21, 2016 at 2:59 PM, John =
Bradley <ve7jtb@ve7jtb.com> wrote:
There have been a lot of =
discussions. I think Hannes posted some minutes of the F2F meeting we =
had with the security researchers.

The problem can=E2=80=99t be mitigated =
without some action on the client side.  It boils down to the =
client making a request to AS1 (=46rom it=E2=80=99s perspective) and =
getting back a response from AS 2 (that it thinks is AS1)

This can be done if AS1 =
is a good AS but has it=E2=80=99s logs compromised so that an attacker =
can read them. Hans Zandbelt built a proof of concept for the =
attack. 

So =
for mix-up, we're only talking about a compromised logs attack and not a =
completely compromised AS?
 
In some cases the attacker gets =
the code and the credential to use it at the good AS token endpoint and =
in others it just gets the code and can replay that at the client to =
extract information from the API through the client by binding the api =
access to a new account.

PKCE unfortunately mitigates a different attack, where the =
client is impersonated and trys to replay a intercepted code.  It =
however assumes the token endpoint is good, and is no help in the case =
of a compromised token endpoint.

The client in these attacks is =
vulnerable because it relies on some local state, or the value of the =
state parameter to know who the response is coming from.  This =
allows a authorization request that is intercepted to be used to create =
a new request in that browser to a different AS, or trick the client =
into using a Authorization endpoint for a different authorization =
server.

One =
problem is that OAuth doesn=E2=80=99t really have a unified concept of =
what a AS is.  Traditionally it is a Authorization endpoint URI, =
token end point URI and resource server URI that some one gives the =
client in some documentation.   

As ling as a client only talks to one =
AS then there is no problem.   However once a client is configured =
to talk to more than one AS, we have problems if one of those AS lies =
about it=E2=80=99s endpoints, or is compromised and used to attack =
another AS.   As a design goal you don=E2=80=99t want the overall =
 security to be limited by the weakest system.

One approach as Nat =
promotes is to have the authorization endpoint return the next hop, =
token endpoint for code or RS URI for token. The token endpoint must =
also return the RS URI or the client must push the RS URI to the token =
endpoint or the attacker just replaces the RS URI in the config and =
captures the token that way. 

I believe the RS URI would =
not be needed to defeat the compromised logs mix-up attack for the code =
flow. The client will send the client_id it got when registering at AS1 =
to the token endpoint returned by AS2 (using Nat's spec), which will =
then cause a failure due to client_id mis-match. So simply returning the =
"token_endpoint" URI in the AS2 authorization response would defeat the =
compromised-logs mix-up attack, would it not? 
 
The other =
way is to provide a name for each AS as part of registration and the =
client not allow duplicate registrations with the same name.  When =
the response comes back the client checks the name against the one it =
made the request to.  If the name dereferences to a discovery =
document then the client can check that name at registration or runtime =
to validate the net hops.

I think the two approaches mitigate the attack in similar =
ways.  Nat=E2=80=99s is more REST friendly and returns the next hop =
as a parameter of header.  

The one Mike and I wrote up based on =
the meeting in Germany provides identifiers (iss and client_id) that can =
be checked for validity in the simple case and be dereferenced via =
.well-known to get the information Nat=E2=80=99s proposal is =
providing.
 

Perhaps the main difference is Nat is using the token =
endpoint as the identifier for the AS and Mike=E2=80=99s is using =
location for a discovery document as the identifier.

I don=E2=80=99t recall =
the reasons using the token endpoint as the identifier was rejected at =
the meeting.  Perhaps others can post the =
reasons.

Can you =
help clarify something that I've yet to discern from the minutes, does =
OpenID Connect solve the mix-up attack by binding all the tokens =
together and to the issuer via the ID Token?


We need to =
close on this quickly, otherwise if we are indecisive fixes will not go =
into products for another year or so until this is a RFC.

That is my main =
concern.

John =
B.


[snip] =
 For readability of a long thread.

=

--Apple-Mail=_CBC884D3-37F7-410C-B860-C1A8D8EE0146--

--Apple-Mail=_5C460D1C-826D-4281-8A6F-43AC0AC989DC
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjUxNDExMjVaMCMGCSqGSIb3DQEJBDEWBBRpIaeGPs80YvFT6c76NRwD
Jjf7DjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAugF7JsWTe5t8R4GBzHck7iXGclEPkvZG1SWYY2cbiYHbPZBD85roT
CCGtZPnFKyr0aRZ5aIJdpdipBlIihmPgENl076TDhE3eqipcfMjsVfEatbsbKs+tv7XAW55Srykk
KEU+XReFFrH6/Zyk8A4oFvQs7JyqA83MT1m1/vY7DpyeP0QUQLfvKxzsy9t4TCWX3YHvAN4GmhRy
g8SabxGs2qNPUPjRv46O6KGlFVmtTQep1lpZUEB01C3aaOJM1dS78IHEmjOt9p/DAbK5pV9qNv5t
QhE0Eovt/ddZAEMUburijGGEWFpRuYhXOyNMb1+0lmEYImto8xidfbaflCcBAAAAAAAA
--Apple-Mail=_5C460D1C-826D-4281-8A6F-43AC0AC989DC--


From nobody Mon Jan 25 06:35:36 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8751B2A47 for ; Mon, 25 Jan 2016 06:35:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B29GVFLApyNY for ; Mon, 25 Jan 2016 06:35:29 -0800 (PST)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::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 9746D1B2A41 for ; Mon, 25 Jan 2016 06:35:29 -0800 (PST)
Received: by mail-qg0-x22c.google.com with SMTP id e32so110111069qgf.3 for ; Mon, 25 Jan 2016 06:35:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=yD54JIce1sxGtqBY4jA6Cu9N46O0fyKJ9hBUMbYttnE=; b=axK8uOxvgYPj0zuh+2Hbv8dDNdkFbkfeX95JevwJCdBI9+fjSd7bRriLjpGg3Mr4KR /p6MeI5fEM1oLfWzmuZO1fDIKleuTn0Zpq194/m1eRFHkiOucCthVvQwcji+sKfeh/f7 /d9tL00L77iPUH1Pxe6+P8962NNqPftqZNq3z0QDW695gt+Q8vtoufdKWhB+wGUvrk62 SUpWDWP/6AXbphy5pJ7BSr5SFzKG6g050dqmZ39+6NYBh/poXFGVOl/0pXr/NqXUiKOO a1a06yeWae18sxv+Y+J1caXtSgotABdRUGSjxy62PSuqLuoPIoiieG7UFgKRZXtJeNJK qTTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=yD54JIce1sxGtqBY4jA6Cu9N46O0fyKJ9hBUMbYttnE=; b=UorlGbeJkLFbLgjKuk8GR+KFEgzGeYsPDpjcSuhOxwK7zvVaiVheAgxtJ9E+9e/BSD /RiS7s1te+lPsstJH0U6p/kM4ql8ZznWwebhoGm3r2+atpPLCOejB7XmxijIPwl5XdZ5 2LMX18w5CkJI07cqoawccZLzf1xwrtLK6nv/VYUcs3Jr1EIs2BuqWaCAsZ4fI0cTZ103 75yRtcf+OJgRnqn2w4fLc6IQXsIUV1RsfcC2n0Xz1KrdJwZJ2aR2x70s6T7vu/Y5IglR 7OCefKHouZQ9xxV3dz0wu6SESrjdfxgRK4bufWIYMJQcGu5MDmMtbm/d8nk+khXbweBP yo7w==
X-Gm-Message-State: AG10YOT9/9EHEKm8cyHXRC+F17UqzeLqvRPmnEsgCUwTb3ng6eJuX5eU5d+e5w/cFr6Rig==
X-Received: by 10.141.3.86 with SMTP id f83mr22495245qhd.98.1453732528253; Mon, 25 Jan 2016 06:35:28 -0800 (PST)
Received: from [192.168.1.68] ([191.115.57.165]) by smtp.gmail.com with ESMTPSA id z190sm8858449qkz.16.2016.01.25.06.35.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 06:35:26 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_0DF2F69A-13F7-4D59-95E8-3C6EF9608874"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56A5DFD0.4050902@connect2id.com>
Date: Mon, 25 Jan 2016 11:35:20 -0300
Message-Id: <482DFD5D-EBCC-43F9-B11F-E19588CE11EF@ve7jtb.com>
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.com>  <56A1F249.3020307@pingidentity.com>  <56A5DFD0.4050902@connect2id.com>
To: Vladimir Dzhuvinov 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 14:35:35 -0000

--Apple-Mail=_0DF2F69A-13F7-4D59-95E8-3C6EF9608874
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_067202CF-1166-4252-B211-736B575C9902"


--Apple-Mail=_067202CF-1166-4252-B211-736B575C9902
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Using client secret JWT works as long as long as the attacker doesn=E2=80=99=
t know the client secret of the client_id associated with the =E2=80=9Cgoo=
d AS=E2=80=9D. =20
The reason is that the attacker cannot replay a signed assertion because =
it contains a audience and client_id that would not match.

In the case where the =E2=80=9Cbad AS=E2=80=9D gets the client to =
register and can proxy that registration and create a new client_id at =
the =E2=80=9Cgood AS=E2=80=9D with the client=E2=80=99s redirect URI, =
than this mitigation would not work.
The bad AS would just use the client credential stolen in the proxy =
registration to create a new authentication to the token endpoint.

While as a general principal not giving the attacker your credential =
unencrypted on the wire is a very good thing, if the attacker man in the =
middles the registration then this won=E2=80=99t help.

We did discuss this in Germany.  It was also felt that forcing clients =
to do crypto was overkill.=20

Standardizing doing client secret JWT authentication in OAuth would be a =
good thing, but should be separate.

Based on the assertions draft you only need to define how to use the =
keys and what the values for aud is in the non connect case (I suspect =
the token endpoint URI would be the obvious choice but someone needs to =
write it down to be interoperable).=20

John B.

> On Jan 25, 2016, at 5:41 AM, Vladimir Dzhuvinov =
 wrote:
>=20
> The token endpoint mix-up attack was originally discussed in the =
context of OIDC, in August 2015. Back then John Bradley noted that by =
simply replacing Basic client authentication with JWT (client_secret_jwt =
or private_key_jwt) the attack is successfully prevented. Yes, the authz =
code will be captured, but the bogus AS will not be able to replay it =
with the legitimate AS because the JWT used for client authentication is =
bound (via the "aud" claim) to the original token endpoint.
>=20
> =
https://bitbucket.org/openid/connect/issues/979/discovery-security-conside=
rations-csrf =

>=20
> =
http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication =

>=20
>=20
> Is this going to be added to the list of solutions? Its usefulness is =
limited to confidential clients, but it's a good solution nevertheless.
>=20
> JWT authentication helps in another case also - when the client by =
mistake sends out the token request over plain HTTP.
>=20
> Cheers,
>=20
> Vladimir
>=20
>=20
> On 23/01/16 22:52, Nat Sakimura wrote:
>> Since we have been discussing in another thread and you guys may be a =
aware
>> of it in this thread, here is one of the problem statement for the =
mix-up
>> draft explaining why it does not solve the problem as it is written =
now.
>>=20
>> It can be fixed to solve the problem, but then the overhead size will =
be
>> much larger and involves an extra round trip compared to oauth-meta =
draft.
>>=20
>> See
>> =
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc67=
49/ =

>> for the details.
>>=20
>> Nat
>> 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 18:11 Hans Zandbelt =
 :
>>=20
>>> +1 to everything Mike stated
>>>=20
>>> Hans.
>>>=20
>>> On 1/22/16 2:04 AM, Mike Jones wrote:
>>>> I believe that it=E2=80=99s simpler and more elegant to return an =
issuer, from
>>>> which the discovery metadata document can be retrieved, which =
contains
>>>> **all** the configuration information about the authorization =
server,
>>>> than to return some of the configuration parameters but not most of =
them
>>>> (which is what the oauth-meta proposal does).  There=E2=80=99s lots =
more in a
>>>> typical discovery document than just a few endpoint addresses. For
>>>> instance, there are statements about what response types are =
supported,
>>>> other configuration choices, keys, etc.
>>>>=20
>>>> I also think that returning the issuer is more future-proof than =
trying
>>>> to decide now what all the configuration information is that might =
want
>>>> to be verified by the client and hoping we get it right.  With the
>>>> issuer, assuming that discovery is supported, it can retrieve and =
check
>>>> all of it, should the client want/need to do so.  Even when =
discovery
>>>> isn=E2=80=99t supported, the issuer still provides a concrete =
identifier for the
>>>> authorization server that can be checked for equality.
>>>>=20
>>>> We talked about the value of that approach in the side meetings in
>>>> Yokohama and people were supportive then.
>>>>=20
>>>>                                                                  -- =
Mike
>>>>=20
>>>> *From:*OAuth [mailto:oauth-bounces@ietf.org =
] *On Behalf Of *John Bradley
>>>> *Sent:* Thursday, January 21, 2016 4:48 PM
>>>> *To:* Nat Sakimura  
>>>> *Cc:* oauth@ietf.org  WG  =

>>>> *Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up =
Mitigation
>>>>=20
>>>> I will point out for clarification that this would be like IdP =
discovery
>>>> in openID 2 that everyone did.  I think IdP not doing RP discovery =
in
>>>> openID 2 is a weak argument.
>>>>=20
>>>> There may be other evidence that RP will not do discovery, but if =
that
>>>> is the case why are we doing a OAuth discovery spec?
>>>>=20
>>>> Many people see your spec as discovery as well just in a different =
way.
>>>>=20
>>>> I think both ways can work, but doing both leaves too many options.
>>>>=20
>>>> John B.
>>>>=20
>>>>     On Jan 21, 2016, at 9:38 PM, Nat Sakimura 
>>>>      > wrote:
>>>>=20
>>>>     Still doing the analysis. We spent 1.5 hours today with John,
>>>>     George, nov and me on the OpenID Connect WG call on this issue. =
John
>>>>     explained the mitigation, but none of us was convinced that it =
works.
>>>>=20
>>>>     Then, after the call, I and nov went on with various scenarios. =
The
>>>>     interim conclusion is that:
>>>>=20
>>>>       * client_id response parameter does not help. There are =
legitimate
>>>>         cases that client_id duplicates out there and we cannot ban =
that.
>>>>       * iss response parameter does not help unless the discovery =
is
>>>>         performed and the value of iss is checked against the value =
of
>>>>         OAuth issuer inside the document. (<- Discovery becomes
>>>>         mandatory. =46rom our experience on RP discovery step in =
OpenID
>>>>         2.0, chance of this being done properly seems to be rather =
slim.)
>>>>       * sending the state to the token endpoint helps in the case =
code
>>>>         was stollen, but code should not be stolen to start with.
>>>>=20
>>>>     Cheers,
>>>>=20
>>>>     Nat
>>>>=20
>>>>     2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John Bradley =

>>>>      >:
>>>>=20
>>>>         There have been a lot of discussions. I think Hannes posted =
some
>>>>         minutes of the F2F meeting we had with the security =
researchers.
>>>>=20
>>>>         The problem can=E2=80=99t be mitigated without some action =
on the client
>>>>         side.  It boils down to the client making a request to AS1 =
(From
>>>>         it=E2=80=99s perspective) and getting back a response from =
AS 2 (that it
>>>>         thinks is AS1)
>>>>=20
>>>>         This can be done if AS1 is a good AS but has it=E2=80=99s =
logs
>>>>         compromised so that an attacker can read them. Hans =
Zandbelt
>>>>         built a proof of concept for the attack.
>>>>=20
>>>>         In some cases the attacker gets the code and the credential =
to
>>>>         use it at the good AS token endpoint and in others it just =
gets
>>>>         the code and can replay that at the client to extract
>>>>         information from the API through the client by binding the =
api
>>>>         access to a new account.
>>>>=20
>>>>         PKCE unfortunately mitigates a different attack, where the
>>>>         client is impersonated and trys to replay a intercepted =
code.
>>>>         It however assumes the token endpoint is good, and is no =
help in
>>>>         the case of a compromised token endpoint.
>>>>=20
>>>>         The client in these attacks is vulnerable because it relies =
on
>>>>         some local state, or the value of the state parameter to =
know
>>>>         who the response is coming from.  This allows a =
authorization
>>>>         request that is intercepted to be used to create a new =
request
>>>>         in that browser to a different AS, or trick the client into
>>>>         using a Authorization endpoint for a different =
authorization
>>> server.
>>>>         One problem is that OAuth doesn=E2=80=99t really have a =
unified concept
>>>>         of what a AS is.  Traditionally it is a Authorization =
endpoint
>>>>         URI, token end point URI and resource server URI that some =
one
>>>>         gives the client in some documentation.
>>>>=20
>>>>         As ling as a client only talks to one AS then there is no
>>>>         problem.   However once a client is configured to talk to =
more
>>>>         than one AS, we have problems if one of those AS lies about =
it=E2=80=99s
>>>>         endpoints, or is compromised and used to attack another AS. =
  As
>>>>         a design goal you don=E2=80=99t want the overall  security =
to be limited
>>>>         by the weakest system.
>>>>=20
>>>>         One approach as Nat promotes is to have the authorization
>>>>         endpoint return the next hop, token endpoint for code or RS =
URI
>>>>         for token. The token endpoint must also return the RS URI =
or the
>>>>         client must push the RS URI to the token endpoint or the
>>>>         attacker just replaces the RS URI in the config and =
captures the
>>>>         token that way.
>>>>=20
>>>>         The other way is to provide a name for each AS as part of
>>>>         registration and the client not allow duplicate =
registrations
>>>>         with the same name.  When the response comes back the =
client
>>>>         checks the name against the one it made the request to. If =
the
>>>>         name dereferences to a discovery document then the client =
can
>>>>         check that name at registration or runtime to validate the =
net
>>> hops.
>>>>         I think the two approaches mitigate the attack in similar =
ways.
>>>>         Nat=E2=80=99s is more REST friendly and returns the next =
hop as a
>>>>         parameter of header.
>>>>=20
>>>>         The one Mike and I wrote up based on the meeting in Germany
>>>>         provides identifiers (iss and client_id) that can be =
checked for
>>>>         validity in the simple case and be dereferenced via =
.well-known
>>>>         to get the information Nat=E2=80=99s proposal is providing.
>>>>=20
>>>>         Perhaps the main difference is Nat is using the token =
endpoint
>>>>         as the identifier for the AS and Mike=E2=80=99s is using =
location for a
>>>>         discovery document as the identifier.
>>>>=20
>>>>         I don=E2=80=99t recall the reasons using the token endpoint =
as the
>>>>         identifier was rejected at the meeting.  Perhaps others can =
post
>>>>         the reasons.
>>>>=20
>>>>         We need to close on this quickly, otherwise if we are =
indecisive
>>>>         fixes will not go into products for another year or so =
until
>>>>         this is a RFC.
>>>>=20
>>>>         That is my main concern.
>>>>=20
>>>>         John B.
>>>>=20
>>>>             On Jan 21, 2016, at 11:50 AM, Josh Mandel =

>>>>              > =
wrote:
>>>>=20
>>>>             Thanks Nat - that's helpful. If both mitigations *can* =
work
>>>>             effectively, then I would like to see this group =
consider
>>>>             the decision between them carefully (if that hasn't =
happened
>>>>             yet). Again, don't hesitate to let me know if this is =
the
>>>>             wrong place/time for such discussion.
>>>>=20
>>>>             At a high level, I would rather ask server developers =
to do
>>>>             some "coding", for two reasons:
>>>>=20
>>>>             1. Most OAuth servers talk to many, many clients. So
>>>>             consolidating the security critical work in one place
>>>>             (server) is a net savings of work (rather than asking =
each
>>>>             client to implement these checks.
>>>>=20
>>>>             2. OAuth server developers are typically more =
sophisticated
>>>>             than client developers, and therefore more likely to
>>>>             understand the implications and more likely to get =
these
>>>>             critical details correct. Asking each client developer =
to do
>>>>             something right is likely to result in heterogenius
>>>>             implementation and persistent security holes. But if =
the
>>>>             server does the heavy lifting, and clients just have to =
pass
>>>>             along an extra parameter, this is more likely to see
>>>>             consistent implementation (for example, clients will =
fail to
>>>>             work if misconfigured, which will prompt developers to =
fix
>>>>             them).
>>>>=20
>>>>             On Jan 21, 2016 09:40, "Nat Sakimura" =

>>>>              =
> wrote:
>>>>=20
>>>>                 Hi Josh,
>>>>=20
>>>>                 It is similar but slightly different IMHO.
>>>>=20
>>>>                 Section 4.6.4 of the RFC6819 is the access token
>>>>                 phishing by a counterfeit resource server.
>>>>=20
>>>>                 The mix-up attack described here is the code =
phishing by
>>>>                 a counterfeit token endpoint.
>>>>=20
>>>>                 In my view, both can be mitigated by the server
>>>>                 returning the next step: i.e., authorization =
endpoint
>>>>                 returning the legitimate token endpoint uri, and =
token
>>>>                 endpoint returning legitimate resource endpoint =
uris.
>>>>                 This involves no discovery endpoint, which is good.
>>>>=20
>>>>                 Your way also works. It is just the reverse of my
>>>>                 proposal. The difference being that my proposal =
does not
>>>>                 need any coding on the server but just =
configuration,
>>>>                 and it can return more metadata if needed.
>>>>=20
>>>>                 Cheers,
>>>>=20
>>>>                 Nat
>>>>=20
>>>>                 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 =
Josh Mandel 
>>>>                  =
>:
>>>>=20
>>>>                     Apologies if this is the wrong forum for my =
comment
>>>>                     (and please direct me to the appropriate place =
in
>>>>                     that case), but I have two questions about the
>>>>                     propose mitigation (and the thinking behind it) =
that
>>>>                     I think the write-up could address:
>>>>=20
>>>>                     1. Could the writeup clarify whether/how the =
primary
>>>>                     "mixup" threat differs from what RFC6819 =
identifies
>>>>                     as in section 4.6.4?
>>>>=20
>>>>                     2. Has the workgroup considered a mitigation =
that
>>>>                     puts more responsibility on the authorization
>>>>                     server, and less on the client? For example, if
>>>>                     would be helpful for the writeup to clarify why
>>>>                     having the client send an "audience field" (in =
the
>>>>                     terminology of RFC6819) to the authorization
>>>>                     endpoint would not mitigate the threat. (In =
that
>>>>                     scenario, the authorization server can =
recognize
>>>>                     that the audience does not correspond to a =
resource
>>>>                     server it knows, rather than asking clients to =
make
>>>>                     this check). I assume this approach has been
>>>>                     considered and rejected as an incomplete =
mitigation,
>>>>                     but I don't have visibility into where/how that
>>>>                     discussion went.
>>>>=20
>>>>                     Thanks,
>>>>=20
>>>>                     Josh
>>>>=20
>>>>                     Hi all,
>>>>=20
>>>>                     this is the call for adoption of OAuth 2.0 =
Mix-Up
>>>>                     Mitigation, see
>>>>=20
>>> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 =

>>>>                     Please let us know by Feb 9th whether you =
accept /
>>>>                     object to the
>>>>                     adoption of this document as a starting point =
for
>>>>                     work in the OAuth
>>>>                     working group.
>>>>=20
>>>>                     Note: This call is related to the announcement =
made
>>>>                     on the list earlier
>>>>                     this month, see
>>>>=20
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html =
.
>>>>                     More
>>>>                     time for analysis is provided due to the =
complexity
>>>>                     of the topic.
>>>>=20
>>>>                     Ciao
>>>>                     Hannes & Derek
>>>>=20
>>>>=20
>>>>                     _______________________________________________
>>>>                     OAuth mailing list
>>>>                     OAuth@ietf.org  =
 
>>>>                     https://www.ietf.org/mailman/listinfo/oauth =

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

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

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

>>>>=20
>>> --
>>> Hans Zandbelt              | Sr. Technical Architect
>>> hzandbelt@pingidentity.com  | =
Ping Identity
>>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

>=20
> --=20
> Vladimir Dzhuvinov :: vladimir@connect2id.com =
__________________________________________=
_____
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_067202CF-1166-4252-B211-736B575C9902
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Using client secret JWT works as long as long as the attacker =
doesn=E2=80=99t know the client secret of the client_id associated with =
the =E2=80=9Cgood AS=E2=80=9D.  
The reason is that =
the attacker cannot replay a signed assertion because it contains a =
audience and client_id that would not match.

In the case where the =E2=80=9Cbad =
AS=E2=80=9D gets the client to register and can proxy that registration =
and create a new client_id at the =E2=80=9Cgood AS=E2=80=9D with the =
client=E2=80=99s redirect URI, than this mitigation would not =
work.
The bad AS would just use the client =
credential stolen in the proxy registration to create a new =
authentication to the token endpoint.

While as a general principal not giving =
the attacker your credential unencrypted on the wire is a very good =
thing, if the attacker man in the middles the registration then this =
won=E2=80=99t help.

We did discuss this in Germany.  It was also felt that =
forcing clients to do crypto was overkill. 

Standardizing doing client secret JWT =
authentication in OAuth would be a good thing, but should be =
separate.

Based =
on the assertions draft you only need to define how to use the keys and =
what the values for aud is in the non connect case (I suspect the token =
endpoint URI would be the obvious choice but someone needs to write it =
down to be interoperable). 

John B.

On Jan 25, 2016, at 5:41 AM, Vladimir =
Dzhuvinov <vladimir@connect2id.com> wrote:


 =20
    
 =20
  

    The token endpoint mix-up attack was originally discussed in the
    context of OIDC, in August 2015. Back then John Bradley noted that
    by simply replacing Basic client authentication with JWT
    (client_secret_jwt or private_key_jwt) the attack is successfully
    prevented. Yes, the authz code will be captured, but the bogus AS
    will not be able to replay it with the legitimate AS because the JWT
    used for client authentication is bound (via the "aud" claim) to the
    original token endpoint.

    

https://bitbucket.org/openid/connect/issues/979/disc=
overy-security-considerations-csrf

    

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

    

    

    Is this going to be added to the list of solutions? Its usefulness
    is limited to confidential clients, but it's a good solution
    nevertheless.

    

    JWT authentication helps in another case also - when the client by
    mistake sends out the token request over plain HTTP.

    

    Cheers,

    

    Vladimir

    

    

    
On 23/01/16 22:52, Nat Sakimura =
wrote:

    

    

      
Since we have been discussing in another =
thread and you guys may be a aware
of it in this thread, here is one of the problem statement for the =
mix-up
draft explaining why it does not solve the problem as it is written now.

It can be fixed to solve the problem, but then the overhead size will be
much larger and involves an extra round trip compared to oauth-meta =
draft.

See
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oa=
uth-2-0-rfc6749/
for the details.

Nat
2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 18:11 Hans Zandbelt <hzandbelt@pingidentity.com&=
gt;:



      

        
+1 to everything Mike stated

Hans.

On 1/22/16 2:04 AM, Mike Jones wrote:


        

          
I believe that it=E2=80=99s simpler =
and more elegant to return an issuer, from
which the discovery metadata document can be retrieved, which contains
**all** the configuration information about the authorization server,
than to return some of the configuration parameters but not most of them
(which is what the oauth-meta proposal does).  There=E2=80=99s lots more =
in a
typical discovery document than just a few endpoint addresses. For
instance, there are statements about what response types are supported,
other configuration choices, keys, etc.

I also think that returning the issuer is more future-proof than trying
to decide now what all the configuration information is that might want
to be verified by the client and hoping we get it right.  With the
issuer, assuming that discovery is supported, it can retrieve and check
all of it, should the client want/need to do so.  Even when discovery
isn=E2=80=99t supported, the issuer still provides a concrete identifier =
for the
authorization server that can be checked for equality.

We talked about the value of that approach in the side meetings in
Yokohama and people were supportive then.

                                                                 -- Mike

*From:*OAuth [mailto:oauth-bounces@ietf.org] =
*On Behalf Of *John Bradley
*Sent:* Thursday, January 21, 2016 4:48 PM
*To:* Nat Sakimura <sakimura@gmail.com>
*Cc:* oauth@ietf.org WG <oauth@ietf.org>
*Subject:* Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

I will point out for clarification that this would be like IdP discovery
in openID 2 that everyone did.  I think IdP not doing RP discovery in
openID 2 is a weak argument.

There may be other evidence that RP will not do discovery, but if that
is the case why are we doing a OAuth discovery spec?

Many people see your spec as discovery as well just in a different way.

I think both ways can work, but doing both leaves too many options.

John B.

    On Jan 21, 2016, at 9:38 PM, Nat Sakimura <sakimura@gmail.com
    <mailto:sakimura@gmail.com>&g=
t; wrote:

    Still doing the analysis. We spent 1.5 hours today with John,
    George, nov and me on the OpenID Connect WG call on this issue. John
    explained the mitigation, but none of us was convinced that it =
works.

    Then, after the call, I and nov went on with various scenarios. The
    interim conclusion is that:

      * client_id response parameter does not help. There are legitimate
        cases that client_id duplicates out there and we cannot ban =
that.
      * iss response parameter does not help unless the discovery is
        performed and the value of iss is checked against the value of
        OAuth issuer inside the document. (<- Discovery becomes
        mandatory. =46rom our experience on RP discovery step in OpenID
        2.0, chance of this being done properly seems to be rather =
slim.)
      * sending the state to the token endpoint helps in the case code
        was stollen, but code should not be stolen to start with.

    Cheers,

    Nat

    2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John Bradley =
<ve7jtb@ve7jtb.com
    <mailto:ve7jtb@ve7jtb.com>>=
:

        There have been a lot of discussions. I think Hannes posted some
        minutes of the F2F meeting we had with the security researchers.

        The problem can=E2=80=99t be mitigated without some action on =
the client
        side.  It boils down to the client making a request to AS1 (From
        it=E2=80=99s perspective) and getting back a response from AS 2 =
(that it
        thinks is AS1)

        This can be done if AS1 is a good AS but has it=E2=80=99s logs
        compromised so that an attacker can read them. Hans Zandbelt
        built a proof of concept for the attack.

        In some cases the attacker gets the code and the credential to
        use it at the good AS token endpoint and in others it just gets
        the code and can replay that at the client to extract
        information from the API through the client by binding the api
        access to a new account.

        PKCE unfortunately mitigates a different attack, where the
        client is impersonated and trys to replay a intercepted code.
        It however assumes the token endpoint is good, and is no help in
        the case of a compromised token endpoint.

        The client in these attacks is vulnerable because it relies on
        some local state, or the value of the state parameter to know
        who the response is coming from.  This allows a authorization
        request that is intercepted to be used to create a new request
        in that browser to a different AS, or trick the client into
        using a Authorization endpoint for a different authorization


        

        
server.


        

          
        One problem is that OAuth =
doesn=E2=80=99t really have a unified concept
        of what a AS is.  Traditionally it is a Authorization endpoint
        URI, token end point URI and resource server URI that some one
        gives the client in some documentation.

        As ling as a client only talks to one AS then there is no
        problem.   However once a client is configured to talk to more
        than one AS, we have problems if one of those AS lies about =
it=E2=80=99s
        endpoints, or is compromised and used to attack another AS.   As
        a design goal you don=E2=80=99t want the overall  security to be =
limited
        by the weakest system.

        One approach as Nat promotes is to have the authorization
        endpoint return the next hop, token endpoint for code or RS URI
        for token. The token endpoint must also return the RS URI or the
        client must push the RS URI to the token endpoint or the
        attacker just replaces the RS URI in the config and captures the
        token that way.

        The other way is to provide a name for each AS as part of
        registration and the client not allow duplicate registrations
        with the same name.  When the response comes back the client
        checks the name against the one it made the request to. If the
        name dereferences to a discovery document then the client can
        check that name at registration or runtime to validate the net


        

        
hops.


        

          
        I think the two approaches =
mitigate the attack in similar ways.
        Nat=E2=80=99s is more REST friendly and returns the next hop as =
a
        parameter of header.

        The one Mike and I wrote up based on the meeting in Germany
        provides identifiers (iss and client_id) that can be checked for
        validity in the simple case and be dereferenced via .well-known
        to get the information Nat=E2=80=99s proposal is providing.

        Perhaps the main difference is Nat is using the token endpoint
        as the identifier for the AS and Mike=E2=80=99s is using =
location for a
        discovery document as the identifier.

        I don=E2=80=99t recall the reasons using the token endpoint as =
the
        identifier was rejected at the meeting.  Perhaps others can post
        the reasons.

        We need to close on this quickly, otherwise if we are indecisive
        fixes will not go into products for another year or so until
        this is a RFC.

        That is my main concern.

        John B.

            On Jan 21, 2016, at 11:50 AM, Josh Mandel <jmandel@gmail.com
            <mailto:jmandel@gmail.com>>=
 wrote:

            Thanks Nat - that's helpful. If both mitigations *can* work
            effectively, then I would like to see this group consider
            the decision between them carefully (if that hasn't happened
            yet). Again, don't hesitate to let me know if this is the
            wrong place/time for such discussion.

            At a high level, I would rather ask server developers to do
            some "coding", for two reasons:

            1. Most OAuth servers talk to many, many clients. So
            consolidating the security critical work in one place
            (server) is a net savings of work (rather than asking each
            client to implement these checks.

            2. OAuth server developers are typically more sophisticated
            than client developers, and therefore more likely to
            understand the implications and more likely to get these
            critical details correct. Asking each client developer to do
            something right is likely to result in heterogenius
            implementation and persistent security holes. But if the
            server does the heavy lifting, and clients just have to pass
            along an extra parameter, this is more likely to see
            consistent implementation (for example, clients will fail to
            work if misconfigured, which will prompt developers to fix
            them).

            On Jan 21, 2016 09:40, "Nat Sakimura" <sakimura@gmail.com
            <mailto:sakimura@gmail.com>&g=
t; wrote:

                Hi Josh,

                It is similar but slightly different IMHO.

                Section 4.6.4 of the RFC6819 is the access token
                phishing by a counterfeit resource server.

                The mix-up attack described here is the code phishing by
                a counterfeit token endpoint.

                In my view, both can be mitigated by the server
                returning the next step: i.e., authorization endpoint
                returning the legitimate token endpoint uri, and token
                endpoint returning legitimate resource endpoint uris.
                This involves no discovery endpoint, which is good.

                Your way also works. It is just the reverse of my
                proposal. The difference being that my proposal does not
                need any coding on the server but just configuration,
                and it can return more metadata if needed.

                Cheers,

                Nat

                2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh =
Mandel <jmandel@gmail.com
                <mailto:jmandel@gmail.com>>=
:

                    Apologies if this is the wrong forum for my comment
                    (and please direct me to the appropriate place in
                    that case), but I have two questions about the
                    propose mitigation (and the thinking behind it) that
                    I think the write-up could address:

                    1. Could the writeup clarify whether/how the primary
                    "mixup" threat differs from what RFC6819 identifies
                    as in section 4.6.4?

                    2. Has the workgroup considered a mitigation that
                    puts more responsibility on the authorization
                    server, and less on the client? For example, if
                    would be helpful for the writeup to clarify why
                    having the client send an "audience field" (in the
                    terminology of RFC6819) to the authorization
                    endpoint would not mitigate the threat. (In that
                    scenario, the authorization server can recognize
                    that the audience does not correspond to a resource
                    server it knows, rather than asking clients to make
                    this check). I assume this approach has been
                    considered and rejected as an incomplete mitigation,
                    but I don't have visibility into where/how that
                    discussion went.

                    Thanks,

                    Josh

                    Hi all,

                    this is the call for adoption of OAuth 2.0 Mix-Up
                    Mitigation, see



        

        
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00


        

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

                    Note: This call is related to the announcement made
                    on the list earlier
                    this month, see



        

        
=
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html.


        

          
                    More
                    time for analysis is provided due to the complexity
                    of the topic.

                    Ciao
                    Hannes & Derek


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

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

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



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



        

        
--
Hans Zandbelt              | Sr. Technical Architect
hzandbelt@pingidentity.com =
| Ping Identity



      

      

      

      

      

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


    

    

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

  


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

=

--Apple-Mail=_067202CF-1166-4252-B211-736B575C9902--

--Apple-Mail=_0DF2F69A-13F7-4D59-95E8-3C6EF9608874
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjUxNDM1MjFaMCMGCSqGSIb3DQEJBDEWBBSdDtBFCBYi/gT0nnhZAef2
wCwi1zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBKkS4wuW57Cn00RocXtkVOlmTRYlWI5j7sL5kzNs+wRFTHwAN749kW
D7gDRxQL9MDqbzq/W9fGNRd46ZdEiX5dLuRVyX4x4u4flaxPwSsNVIrW10XzNmEDv7JdwtMFWVri
v7wb+yz1MfN0gxFCCRDkZQ+VukZ1j4mJibdenrEfnDFH4KBB5GNAL1ymj6tyZWAmExFcj53h8HYV
E8z+xLDQN8eAl5oV+okAwKERY04o2TIFLJ5MrpBmWnZNnmXbj3h8iph57Tv8A2ZKIEjsl2IDs9Rg
HXbpRgrXH9HMV/JBnOCyXICkmaMDFLfkulj8CLOboT/LWSoj/WJl6p2pkQrqAAAAAAAA
--Apple-Mail=_0DF2F69A-13F7-4D59-95E8-3C6EF9608874--


From nobody Mon Jan 25 07:30:16 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCB81B2C1B for ; Mon, 25 Jan 2016 07:30:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbyYtJVByWjq for ; Mon, 25 Jan 2016 07:30:14 -0800 (PST)
Received: from omr-a009e.mx.aol.com (omr-a009e.mx.aol.com [204.29.186.49]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CBB1B2BFC for ; Mon, 25 Jan 2016 07:30:14 -0800 (PST)
Received: from mtaout-aan02.mx.aol.com (mtaout-aan02.mx.aol.com [172.27.19.78]) by omr-a009e.mx.aol.com (Outbound Mail Relay) with ESMTP id 4050038001B0; Mon, 25 Jan 2016 10:30:13 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aan02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 5602138000082; Mon, 25 Jan 2016 10:30:12 -0500 (EST)
To: John Bradley , William Denniss 
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <995474C5-62E7-4310-84AF-A5EF1CDEA4DB@ve7jtb.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56A63F82.40104@aol.com>
Date: Mon, 25 Jan 2016 10:30:10 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <995474C5-62E7-4310-84AF-A5EF1CDEA4DB@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------060100050102000805060308"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453735813; bh=JK1Cchf/CRfdTh6E0TQEM8Yj9CTm0OIhgVhbz4DOuqg=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=tkL/TDT/VNg9FqnPLrx6jEmcqZ56E2fZ839MvrGtz7SD4PdDvoG9s3wfXAzc56CUj eZv6YpB6MYZpKOrn12N0DVfQDx3ex2FlnJsFEMSFUIEkwG476kBHrKPR43MzlBwpiB aPzgjc/Rxc2AgZV3CkQwTtG2ucqner1J13Oo2/w0=
x-aol-sid: 3039ac1b134e56a63f84510f
X-AOL-IP: 10.172.102.124
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 15:30:15 -0000

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

I'm still catching up... but to this point specifically...

Doesn't this require that the same client_id NOT be used simultaneously 
at two (or more) Authorization Servers? If so, I don't believe that is a 
viable option. It's a little late in the game to be putting requirements 
on the AS as to how it generates it's client_id.

Thanks,
George

On 1/25/16 9:11 AM, John Bradley wrote:
>
> Returning the iss and client_id from the authorization endpoint per 
> Mike’s draft allows the client to reject the authorization response 
> and not leak the code.


--------------060100050102000805060308
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    I'm still catching up...
      but to this point specifically...

      

      Doesn't this require that the same client_id NOT be used
      simultaneously at two (or more) Authorization Servers? If so, I
      don't believe that is a viable option. It's a little late in the game
      to be putting requirements on the AS as to how it generates it's
      client_id.

      

      Thanks,

      George

    

    
On 1/25/16 9:11 AM, John Bradley wrote:

    

    

      


      

      
Returning the iss and client_id from the
        authorization endpoint per Mike’s draft allows the client to
        reject the authorization response and not leak the code.

    

    

  


--------------060100050102000805060308--


From nobody Mon Jan 25 09:32:15 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E221B3780 for ; Mon, 25 Jan 2016 09:32:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8paXVoGRWNa for ; Mon, 25 Jan 2016 09:32:09 -0800 (PST)
Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 82D791B379A for ; Mon, 25 Jan 2016 09:32:09 -0800 (PST)
Received: by mail-qg0-x22e.google.com with SMTP id e32so114749553qgf.3 for ; Mon, 25 Jan 2016 09:32:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5q5ipLu18k4viw2v3cHjw0Aht3JXLGj1F35SZ/hHLxc=; b=uDV+sZq4nePqpZlj4vxAiGRnFKJsiGYBRt+HnUyssSmVCscglfBfbRpAA3mb48w3wb VCYz534Yx8YYszrg7AWkNAIxWx5uCBo9soDO20vkFftSwVs5e8InoQG4Mue7734bRnsH IWJrTErFpWj0RBK3xuNVfO2o8SAJBK9OrxLvYi/nUP034DSKc7uSNzD5XhS9QPOQic40 z23eezhTIXF0AYx8ZBzIcVnA5TwA0bPYYooPCneU7LBfcx0Oe0rM+Yz5s3uNX+LHsO3Z uaJezkpu92Tv15EsYbGpXAl2DpBSbEWHVAoYivty6UGYMBdConCXYdXorJxvwRA6BGfw Jjsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=5q5ipLu18k4viw2v3cHjw0Aht3JXLGj1F35SZ/hHLxc=; b=LdJ44ajPjBNf9DxiX8DXiZ4qiQyK0GJxNVOyLtTUXQUFcTEc5QVt2x3tk0DuwvfhG/ t1S44WXSqho0SReulv4p4APjqoEUmi/ZggwCuJeB91Wk+tB+Dsd9jZ+toPP5zZSpioon 49N7Ip0pmeCZdsIsPr0abOXpeZVwB2FLjUr60nbBEuphW52D2+4YKDZTC62xe83mhANs OId7g2odYirRgRsvHDHeTUPiuElX35yYlQvHby2FpzXBElkFZhEzTdMbc2XcyDzfKw+b 9tuRxGMdc2aIXoyCtusZjCqvbIEipQMfLL/gm9yo56GFPEnWdSzsDdP5k5UdK1kkVaMH 0Jzg==
X-Gm-Message-State: AG10YOTyAYd+HowQq+gZQ+ANlEeMzoYRhuRaWHDxiOa2/v8w5KerlKPv7RVcDAzyVyUMJw==
X-Received: by 10.140.138.145 with SMTP id 139mr24408700qhk.18.1453743128485;  Mon, 25 Jan 2016 09:32:08 -0800 (PST)
Received: from [192.168.1.68] ([191.115.57.165]) by smtp.gmail.com with ESMTPSA id s64sm9094104qgd.28.2016.01.25.09.32.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 09:32:07 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_F9F1556D-1419-4E98-B454-DD6D826476B5"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56A63F82.40104@aol.com>
Date: Mon, 25 Jan 2016 14:32:01 -0300
Message-Id: <6D8FA56F-EA72-4509-90C1-DC33094FA695@ve7jtb.com>
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <995474C5-62E7-4310-84AF-A5EF1CDEA4DB@ve7jtb.com> <56A63F82.40104@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 17:32:14 -0000

--Apple-Mail=_F9F1556D-1419-4E98-B454-DD6D826476B5
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_D8C96BB1-3C5E-4F93-AC36-9E6664E8EACA"


--Apple-Mail=_D8C96BB1-3C5E-4F93-AC36-9E6664E8EACA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

No, client id_are scoped by issuer. =20

There is no need for AS to make the client_id globally unique.

 The client needs to not allow two AS to provide it with the same issuer =
client_id pair.

That would probably be imposable for many clients anyway.=20

For Connect clients typically manage configurations using issuer as the =
primary key.  I doubt may would support even two client_id from the same =
issuer.

For OAuth what clients do is slightly less clear.  In general they don=92t=
 have more than one AS per API do might try and organize things by RS or =
AS.

In principal a OAuth client might have two different AS each with a =
different client ID and that will be OK as long as the client_id in the =
request is the same as the one in the response.

So going to a new AS and getting back the same iss and client_id that =
you registered someplace else would be an error for the client.

I don=92t think that is unreasonable.

John B.


> On Jan 25, 2016, at 12:30 PM, George Fletcher  =
wrote:
>=20
> I'm still catching up... but to this point specifically...
>=20
> Doesn't this require that the same client_id NOT be used =
simultaneously at two (or more) Authorization Servers? If so, I don't =
believe that is a viable option. It's a little late in the game to be =
putting requirements on the AS as to how it generates it's client_id.
>=20
> Thanks,
> George
>=20
> On 1/25/16 9:11 AM, John Bradley wrote:
>>=20
>> Returning the iss and client_id from the authorization endpoint per =
Mike=92s draft allows the client to reject the authorization response =
and not leak the code.
>=20


--Apple-Mail=_D8C96BB1-3C5E-4F93-AC36-9E6664E8EACA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

No, client id_are scoped by issuer.  

There is no need for AS to make the =
client_id globally unique.

 The client needs to not allow two AS to provide it with =
the same issuer client_id pair.

That would probably be imposable for =
many clients anyway. 

For Connect clients typically manage configurations using =
issuer as the primary key.  I doubt may would support even two =
client_id from the same issuer.

For OAuth what clients do is slightly =
less clear.  In general they don=92t have more than one AS per API =
do might try and organize things by RS or AS.

In principal a OAuth client might have =
two different AS each with a different client ID and that will be OK as =
long as the client_id in the request is the same as the one in the =
response.

So =
going to a new AS and getting back the same iss and client_id that you =
registered someplace else would be an error for the client.

I don=92t think that is =
unreasonable.

John B.


On Jan 25, 2016, at 12:30 PM, George Fletcher <gffletch@aol.com> =
wrote:


 =20
    
 =20
  

    I'm still =
catching up...
      but to this point specifically...

      

      Doesn't this require that the same client_id NOT be used
      simultaneously at two (or more) Authorization Servers? If so, I
      don't believe that is a viable option. It's a little late in the =
game
      to be putting requirements on the AS as to how it generates it's
      client_id.

      

      Thanks,

      George

    

    
On 1/25/16 9:11 AM, John Bradley =
wrote:

    

    

      


      

      
Returning the iss and client_id from the
        authorization endpoint per Mike=92s draft allows the client to
        reject the authorization response and not leak the code.

    

    

  




=

--Apple-Mail=_D8C96BB1-3C5E-4F93-AC36-9E6664E8EACA--

--Apple-Mail=_F9F1556D-1419-4E98-B454-DD6D826476B5
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjUxNzMyMDFaMCMGCSqGSIb3DQEJBDEWBBTD4/Al5fqLqMpMyxpxVQea
oBxQajCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCVDqyi74mN7xlKQeiw3EQTYOR3uoODC/ark5NnzlzN7u0ZL0rLGK3c
/LkGD/NG8N+T+fpzpWBWkd8kJJIvf4b/FrDn3PeoT5/V/RUf47M3J8oTbGFyE4b3YqmD+VTieCuQ
KivjaXYj7Y5KHmcqyaASXUJnG+kUJ4VS+BvYhb0NohBlMoryqgq7SJlGvleyc0Faa/ib+u7t3s6A
VV3yulJzKaOllZZ6gUfj1z32qAN3yIAuhQ7pJQkMioPwjPMWfC8Ya2VGloQgTSkm3bsGAnxLpi15
MAwvkpdwATwlegeWv8ZLB4m1pFTzbC5Um8zgIHmPNWBy8ENTgZVsI6KAmG+DAAAAAAAA
--Apple-Mail=_F9F1556D-1419-4E98-B454-DD6D826476B5--


From nobody Mon Jan 25 10:10:48 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA251B381D for ; Mon, 25 Jan 2016 10:10:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Csr4t0OVyP9f for ; Mon, 25 Jan 2016 10:10:44 -0800 (PST)
Received: from omr-m008e.mx.aol.com (omr-m008e.mx.aol.com [204.29.186.7]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E7C1B383D for ; Mon, 25 Jan 2016 10:10:44 -0800 (PST)
Received: from mtaout-mce01.mx.aol.com (mtaout-mce01.mx.aol.com [172.29.27.205]) by omr-m008e.mx.aol.com (Outbound Mail Relay) with ESMTP id 6E9F33800127; Mon, 25 Jan 2016 13:10:43 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mce01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id CED5F38000081; Mon, 25 Jan 2016 13:10:42 -0500 (EST)
To: John Bradley 
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <995474C5-62E7-4310-84AF-A5EF1CDEA4DB@ve7jtb.com> <56A63F82.40104@aol.com> <6D8FA56F-EA72-4509-90C1-DC33094FA695@ve7jtb.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56A66522.1090804@aol.com>
Date: Mon, 25 Jan 2016 13:10:42 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <6D8FA56F-EA72-4509-90C1-DC33094FA695@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------040801030900020809060906"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453745443; bh=bsUROEeqCslZSszJMBBjiBZ9X5nc8aRZ2d0kwlF8bw8=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=jNZJjjBvY7LDESHQVBJ0Kk4pDtC4rDc0XJUmZdwClozDdK8RGqBW1vblLIUlEv3fD jlbIXePTDbDGF/9VifdSgN8Fei8/EaB/piL16t7+Zm6zuPUmoy6I2YUS3tWiTXCXz1 uqY1s5G3tQC//uGAjYdnA3XJt3fpFENw8Rf6OIac=
x-aol-sid: 3039ac1d1bcd56a665223f47
X-AOL-IP: 10.172.102.124
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 18:10:46 -0000

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

Comments inline

On 1/25/16 12:32 PM, John Bradley wrote:
> No, client id_are scoped by issuer.
This makes sense, but I'm not sure it's a current assumption by OAuth2 
implementations :)
>
> There is no need for AS to make the client_id globally unique.
>
>  The client needs to not allow two AS to provide it with the same 
> issuer client_id pair.
>
> That would probably be imposable for many clients anyway.
I would rather say that the results of two client_ids being the same 
from two different issuers is undefined.
>
> For Connect clients typically manage configurations using issuer as 
> the primary key.  I doubt may would support even two client_id from 
> the same issuer.
If scoped by issuer this makes sense, though the concept of "issuer" as 
a comparable entity wasn't really talked about with OAuth2.
>
> For OAuth what clients do is slightly less clear.  In general they 
> don’t have more than one AS per API do might try and organize things 
> by RS or AS.
I agree that not many clients support dynamic client registration. 
However, I would say there a number that support multiple AS that are 
"fixed" within the code (including fixed endpoint URIs). So I would say 
that the associations would be fixed in code. There wouldn't necessarily 
be an association outside of the code which maps button A to AS1 and 
button B to AS2.
>
> In principal a OAuth client might have two different AS each with a 
> different client ID and that will be OK as long as the client_id in 
> the request is the same as the one in the response.
>
> So going to a new AS and getting back the same iss and client_id that 
> you registered someplace else would be an error for the client.
>
> I don’t think that is unreasonable.
I agree that this is reasonable with the assumption that client_id's are 
scoped by "issuer". It's just likely that most clients in the field do 
not have this sort of explicit association. The OAuth2 Dynamic Client 
Registration spec does not define an "issuer" in the response. For the 
OAuth2 use cases, what is the proposed "issuer" equivalent URI that is 
being used to scope the client_id?
>
> John B.
>
>
>> On Jan 25, 2016, at 12:30 PM, George Fletcher > > wrote:
>>
>> I'm still catching up... but to this point specifically...
>>
>> Doesn't this require that the same client_id NOT be used 
>> simultaneously at two (or more) Authorization Servers? If so, I don't 
>> believe that is a viable option. It's a little late in the game to be 
>> putting requirements on the AS as to how it generates it's client_id.
>>
>> Thanks,
>> George
>>
>> On 1/25/16 9:11 AM, John Bradley wrote:
>>>
>>> Returning the iss and client_id from the authorization endpoint per 
>>> Mike’s draft allows the client to reject the authorization response 
>>> and not leak the code.
>>
>

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


--------------040801030900020809060906
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Comments inline

    

    
On 1/25/16 12:32 PM, John Bradley
      wrote:

    

    

      
      No, client id_are scoped by issuer.  

    

    This makes sense, but I'm not sure it's a current assumption by
    OAuth2 implementations :)

    

      


      

      
There is no need for AS to make the client_id
        globally unique.

      


      

      
 The client needs to not allow two AS to provide it
        with the same issuer client_id pair.

        


        

        
That would probably be imposable for many clients
          anyway. 

        

      

    

    I would rather say that the results of two client_ids being the same
    from two different issuers is undefined.

    

      

        


        

        
For Connect clients typically manage
          configurations using issuer as the primary key.  I doubt may
          would support even two client_id from the same issuer.

      

    

    If scoped by issuer this makes sense, though the concept of "issuer"
    as a comparable entity wasn't really talked about with OAuth2.

    

      

        


        

        
For OAuth what clients do is slightly less clear.
           In general they don’t have more than one AS per API do might
          try and organize things by RS or AS.

      

    

    I agree that not many clients support dynamic client registration.
    However, I would say there a number that support multiple AS that
    are "fixed" within the code (including fixed endpoint URIs). So I
    would say that the associations would be fixed in code. There
    wouldn't necessarily be an association outside of the code which
    maps button A to AS1 and button B to AS2.

    

      

        


        

        
In principal a OAuth client might have two
          different AS each with a different client ID and that will be
          OK as long as the client_id in the request is the same as the
          one in the response.

        


        

        
So going to a new AS and getting back the same iss
          and client_id that you registered someplace else would be an
          error for the client.

        


        

        
I don’t think that is unreasonable.

      

    

    I agree that this is reasonable with the assumption that client_id's
    are scoped by "issuer". It's just likely that most clients in the
    field do not have this sort of explicit association. The OAuth2
    Dynamic Client Registration spec does not define an "issuer" in the
    response. For the OAuth2 use cases, what is the proposed "issuer"
    equivalent URI that is being used to scope the client_id? 

    

      

        


        

        
John B.

        


        

        


          

            

              
On Jan 25, 2016, at 12:30 PM, George
                Fletcher <gffletch@aol.com>
                wrote:

              

              

                
                
 I'm
                    still catching up... but to this point
                    specifically...

                    

                    Doesn't this require that the same client_id NOT be
                    used simultaneously at two (or more) Authorization
                    Servers? If so, I don't believe that is a viable
                    option. It's a little late in the game to be putting
                    requirements on the AS as to how it generates it's
                    client_id.

                    

                    Thanks,

                    George

                  

                  
On 1/25/16 9:11 AM, John
                    Bradley wrote:

                  

                  

                    


                    

                    
Returning the iss and client_id from
                      the authorization endpoint per Mike’s draft allows
                      the client to reject the authorization response
                      and not leak the code.

                  

                  

                

              

            

          

          

        

      

    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------040801030900020809060906--


From nobody Mon Jan 25 10:22:39 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BF21B3888 for ; Mon, 25 Jan 2016 10:22:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RSNMom0JtZt for ; Mon, 25 Jan 2016 10:22:34 -0800 (PST)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d: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 29F991B3885 for ; Mon, 25 Jan 2016 10:22:33 -0800 (PST)
Received: by mail-qk0-x22b.google.com with SMTP id s68so57643364qkh.3 for ; Mon, 25 Jan 2016 10:22:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=qmckDpVinYYpg7umiwWS6uMj/Dpl/NYtHE2DcorIXbA=; b=vuXdEptg5Fu+QXQG5tUuLQcsG2e1A91WU/Bd9pOQpGvvWw8BCoJy9c1l3jGlngjHBw Lyc37+4XWptU0EQ+RvqrThmT13su9NeejmeOvbEwXF7PZb2/CSfnF/AaMbYeAso/viXz EiSKWLFFm8gZzE0jVLQzkWng0uZCw2cwvDbr6U1YHkZwOirAq5WA/z/ZWlGBEq93pdJE A+Jdn16ZVYef1C3UmTWvuBc54rmkiOK0UKm1KxgkPfszDrnp5yPI1FCqYpFOTOFEdBbr YwlJjWJyomX1CC513Er2iowA2HzP5LSaLTSSxOXfK7lRigVzBH9dqPqzgxWnBJ/6MrgS 7zkg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=qmckDpVinYYpg7umiwWS6uMj/Dpl/NYtHE2DcorIXbA=; b=TJNI7u5BccWhcrik1OA7XMzPZmNV519/kStvRTi554tGvxGqJjfL/Rj2gaytqkexs0 vrVZY+VvZ7xVe0O7LtFTaEjrl4P9miaNBGGbxbRloSt/wlz9fkSSXygsSw5czeS+w3Xb ZZnbxR7ID3uIsTDgTsZoVpcV4vVrFbT0YhmHUa3DEcVXsO9qCRJnVKrQ/kOmNSGogN6k ygkiTruiGYg7nhcMRS3L272zrlh3mo1n3f3+nz1YildgMLWetQisWIjDFZlkDkFNCI+2 ZhpVbgimC3r2tPWhCVptF7NqB61143Z9efJ/IpOvWU0Odd2Jyuz1ZFsY1r2Vk8hPPjYO pn1w==
X-Gm-Message-State: AG10YOQphS10rXWTN49I8Ce3N344vkSKLKfCXzhoWYWg7yJfnl3n0vUYqhTVUhFykpMTSg==
X-Received: by 10.55.53.207 with SMTP id c198mr22804784qka.24.1453746152965; Mon, 25 Jan 2016 10:22:32 -0800 (PST)
Received: from [192.168.1.68] ([191.115.87.160]) by smtp.gmail.com with ESMTPSA id f34sm9166824qgf.42.2016.01.25.10.22.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 10:22:32 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_7713E2B2-5CF1-4B7A-ABFD-76AAF5ECEA01"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56A66522.1090804@aol.com>
Date: Mon, 25 Jan 2016 15:22:21 -0300
Message-Id: <23E34900-5C05-4295-AFC5-7DEBA6449AA7@ve7jtb.com>
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <995474C5-62E7-4310-84AF-A5EF1CDEA4DB@ve7jtb.com> <56A63F82.40104@aol.com> <6D8FA56F-EA72-4509-90C1-DC33094FA695@ve7jtb.com> <56A66522.1090804@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 18:22:37 -0000

--Apple-Mail=_7713E2B2-5CF1-4B7A-ABFD-76AAF5ECEA01
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_9B86677B-368A-448A-A40A-195883C03352"


--Apple-Mail=_9B86677B-368A-448A-A40A-195883C03352
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

The presumption is that registration would need to add a issuer, as an =
identifier of the AS, and that would be optionally be used in discovery.

OAuth as is supports the single AS model.

To support multiple AS for a single client something needs to change.    =
Adding issuer and client_id to the response with optional discovery was =
seen as the least disruptive at the Germany meeting.

 The other way to do it is to return discovery info from the the =
authorization and token endpoints, however the request probably also =
need to be modified so that the AS knows what the resource is, otherwise=20=

other things will break.   =20

It is possible now to have one authorization endpoint provide code for =
per Tennent token endpoints.(No I don=92t know of any one doing it).

Anything we add to tighten up the trust model will have impacts on what =
can be done with OAuth. =20

John B.
> On Jan 25, 2016, at 3:10 PM, George Fletcher  wrote:
>=20
> Comments inline
>=20
> On 1/25/16 12:32 PM, John Bradley wrote:
>> No, client id_are scoped by issuer. =20
> This makes sense, but I'm not sure it's a current assumption by OAuth2 =
implementations :)
>>=20
>> There is no need for AS to make the client_id globally unique.
>>=20
>>  The client needs to not allow two AS to provide it with the same =
issuer client_id pair.
>>=20
>> That would probably be imposable for many clients anyway.=20
> I would rather say that the results of two client_ids being the same =
from two different issuers is undefined.
>>=20
>> For Connect clients typically manage configurations using issuer as =
the primary key.  I doubt may would support even two client_id from the =
same issuer.
> If scoped by issuer this makes sense, though the concept of "issuer" =
as a comparable entity wasn't really talked about with OAuth2.
>>=20
>> For OAuth what clients do is slightly less clear.  In general they =
don=92t have more than one AS per API do might try and organize things =
by RS or AS.
> I agree that not many clients support dynamic client registration. =
However, I would say there a number that support multiple AS that are =
"fixed" within the code (including fixed endpoint URIs). So I would say =
that the associations would be fixed in code. There wouldn't necessarily =
be an association outside of the code which maps button A to AS1 and =
button B to AS2.
>>=20
>> In principal a OAuth client might have two different AS each with a =
different client ID and that will be OK as long as the client_id in the =
request is the same as the one in the response.
>>=20
>> So going to a new AS and getting back the same iss and client_id that =
you registered someplace else would be an error for the client.
>>=20
>> I don=92t think that is unreasonable.
> I agree that this is reasonable with the assumption that client_id's =
are scoped by "issuer". It's just likely that most clients in the field =
do not have this sort of explicit association. The OAuth2 Dynamic Client =
Registration spec does not define an "issuer" in the response. For the =
OAuth2 use cases, what is the proposed "issuer" equivalent URI that is =
being used to scope the client_id?=20
>>=20
>> John B.
>>=20
>>=20
>>> On Jan 25, 2016, at 12:30 PM, George Fletcher > wrote:
>>>=20
>>> I'm still catching up... but to this point specifically...
>>>=20
>>> Doesn't this require that the same client_id NOT be used =
simultaneously at two (or more) Authorization Servers? If so, I don't =
believe that is a viable option. It's a little late in the game to be =
putting requirements on the AS as to how it generates it's client_id.
>>>=20
>>> Thanks,
>>> George
>>>=20
>>> On 1/25/16 9:11 AM, John Bradley wrote:
>>>>=20
>>>> Returning the iss and client_id from the authorization endpoint per =
Mike=92s draft allows the client to reject the authorization response =
and not leak the code.
>>>=20
>>=20
>=20
> --=20
> Chief Architect                  =20
> Identity Services Engineering     Work: george.fletcher@teamaol.com =

> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch =

> Office: +1-703-265-2544           Photos: =
http://georgefletcher.photography 


--Apple-Mail=_9B86677B-368A-448A-A40A-195883C03352
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

The presumption is that registration would need to add a =
issuer, as an identifier of the AS, and that would be optionally be used =
in discovery.

OAuth =
as is supports the single AS model.

To support multiple AS for a single =
client something needs to change.    Adding issuer and =
client_id to the response with optional discovery was seen as the least =
disruptive at the Germany meeting.

 The other way to do it is to =
return discovery info from the the authorization and token endpoints, =
however the request probably also need to be modified so that the AS =
knows what the resource is, otherwise 
other =
things will break.    

It is possible now to have one =
authorization endpoint provide code for per Tennent token endpoints.(No =
I don=92t know of any one doing it).

Anything we add to tighten up the trust =
model will have impacts on what can be done with OAuth.  

John B.
On =
Jan 25, 2016, at 3:10 PM, George Fletcher <gffletch@aol.com> =
wrote:

Comments =
inline

On 1/25/16 12:32 PM, John Bradley wrote:
No, client id_are scoped by issuer.  
This makes sense, but I'm not sure it's a =
current assumption by OAuth2 implementations :)

There is =
no need for AS to make the client_id globally unique.

 The client needs =
to not allow two AS to provide it with the same issuer client_id =
pair.

That would probably be imposable for many clients =
anyway. 
I would rather say that the results of two =
client_ids being the same from two different issuers is =
undefined.

For Connect clients typically manage configurations using =
issuer as the primary key.  I doubt may would support even two =
client_id from the same issuer.
If scoped by issuer =
this makes sense, though the concept of "issuer" as a comparable entity =
wasn't really talked about with OAuth2.

For OAuth what clients do is slightly less clear.  In =
general they don=92t have more than one AS per API do might try and =
organize things by RS or AS.
I agree that not =
many clients support dynamic client registration. However, I would say =
there a number that support multiple AS that are "fixed" within the code =
(including fixed endpoint URIs). So I would say that the associations =
would be fixed in code. There wouldn't necessarily be an association =
outside of the code which maps button A to AS1 and button B to =
AS2.

In principal a OAuth client might have two different AS each =
with a different client ID and that will be OK as long as the client_id =
in the request is the same as the one in the response.

So going to a new AS and =
getting back the same iss and client_id that you registered someplace =
else would be an error for the client.

I don=92t think that is =
unreasonable.
I agree that this is reasonable with the =
assumption that client_id's are scoped by "issuer". It's just likely =
that most clients in the field do not have this sort of explicit =
association. The OAuth2 Dynamic Client Registration spec does not define =
an "issuer" in the response. For the OAuth2 use cases, what is the =
proposed "issuer" equivalent URI that is being used to scope the =
client_id? 

John B.


On Jan 25, 2016, at 12:30 PM, George Fletcher =
<gffletch@aol.com> wrote:

I'm still catching up... but to =
this point specifically...

Doesn't this =
require that the same client_id NOT be used simultaneously at two (or =
more) Authorization Servers? If so, I don't believe that is a viable =
option. It's a little late in the game to be putting requirements on the =
AS as to how it generates it's client_id.

Thanks,
George

On 1/25/16 9:11 AM, John =
Bradley wrote:

Returning=
 the iss and client_id from the authorization endpoint per Mike=92s =
draft allows the client to reject the authorization response and not =
leak the code.



--=20
Chief Architect                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photogra=
phy


=

--Apple-Mail=_9B86677B-368A-448A-A40A-195883C03352--

--Apple-Mail=_7713E2B2-5CF1-4B7A-ABFD-76AAF5ECEA01
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjUxODIyMjJaMCMGCSqGSIb3DQEJBDEWBBSVJhK6jU3hPFwpx3wpidCj
puYt+zCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAJe2hLI+jPnwI5okCqzAk21c5QcPDNQkaQMMpYdLd6Xi2dsOPqic/j
+zaG5HeFNlChfOIwUWceU0STNa7zyFwlxzx3NEUyHyAfSm1Mz5t7gkKhZcGNn0xZD8hDcPoNfNFO
JmGYYZQSsARqAgHe01b9KiLAbQYvh3FJ8/2SxVb+WIZsDch+eE3bSDBUZNjJ3a+Nf2cK0Wkrrf70
n29Y0JhcKKETVa2zgQq3t0tN1Rx4g+9r+8ZiVZ42gbsu/8IxWcp8qep4hopA7BscnHGXvKLqEhtU
bSaZi6Vh6wquaKaKP2ZMzln6b5r6Ty4KZasDeEMCalsqh/7+F977rG0iQDI8AAAAAAAA
--Apple-Mail=_7713E2B2-5CF1-4B7A-ABFD-76AAF5ECEA01--


From nobody Mon Jan 25 10:34:13 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701D31B38B3 for ; Mon, 25 Jan 2016 10:34:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYSJ6ycwrNO0 for ; Mon, 25 Jan 2016 10:34:09 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2F01B38B2 for ; Mon, 25 Jan 2016 10:34:09 -0800 (PST)
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 u0PIY2nf031834 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Jan 2016 18:34:03 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u0PIY1uM002116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jan 2016 18:34:02 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u0PIY10J000878; Mon, 25 Jan 2016 18:34:01 GMT
Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Jan 2016 10:34:00 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_AD66F3AF-BAA0-4FB5-B010-BD6304ADBD89"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: 
Date: Mon, 25 Jan 2016 10:33:58 -0800
Message-Id: 
References: <568D24DD.3050501@connect2id.com>   <568D5610.6000506@lodderstedt.net>     <10631235-AF1B-4122-AEAE-D56BBF38F87E@ve7jtb.com> 
To: Nat Sakimura 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 18:34:11 -0000

--Apple-Mail=_AD66F3AF-BAA0-4FB5-B010-BD6304ADBD89
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1

Phil

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






> On Jan 21, 2016, at 6:26 AM, Nat Sakimura  wrote:
>=20
> +1. Even as the main editor of the spec., I tend to forget the history =
;-)
>=20
> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:17 John Bradley =
>:
> The code_challenge and code_challenge_method parameter names predate =
calling the spec PKCE. =20
>=20
> Given that some of us deployed early versions of PKCE in products and =
opensource to mitigate the problem before the spec was completed we =
decided not to rename the parameter names from code_verifier_method to =
pkce_verifier_method. =20
>=20
> For consistency we should stick with code_verifier_methods_supported =
in discovery.
>=20
> John B.
>=20
>> On Jan 21, 2016, at 3:12 AM, William Denniss > wrote:
>>=20
>> "code_challenge_methods_supported" definitely works for me.
>>=20
>> Any objections to moving forward with that? I would like to update =
our discovery doc shortly.
>>=20
>> On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura > wrote:
>> Ah, OK. That's actually reasonable.=20
>>=20
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matake =
>:
>> I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since =
the registered parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, =
not =E2=80=9Cpkce_method".
>>=20
>>> On Jan 19, 2016, at 11:58, William Denniss > wrote:
>>>=20
>>> Seems like we agree this should be added. How should it look?
>>>=20
>>> Two ideas:
>>>=20
>>> "code_challenge_methods_supported": ["plain", "S256"]
>>>=20
>>> or
>>>=20
>>> "pkce_methods_supported": ["plain", "S256"]
>>>=20
>>>=20
>>>=20
>>> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt =
> wrote:
>>> +1
>>>=20
>>>=20
>>> Am 06.01.2016 um 18:25 schrieb William Denniss:
>>>> +1
>>>>=20
>>>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley > wrote:
>>>> Good point.  Now that PKCE is a RFC we should add it to discovery.
>>>>=20
>>>> John B.
>>>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov =
> wrote:
>>>> >
>>>> > I just noticed PKCE support is missing from the discovery =
metadata.
>>>> >
>>>> > Is it a good idea to add it?
>>>> >
>>>> > Cheers,
>>>> >
>>>> > Vladimir
>>>> >
>>>> > --
>>>> > 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
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth =

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

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

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

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


--Apple-Mail=_AD66F3AF-BAA0-4FB5-B010-BD6304ADBD89
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1








On Jan 21, 2016, at 6:26 AM, Nat Sakimura <sakimura@gmail.com> =
wrote:

+1. Even as the main editor of the spec., I tend =
to forget the history ;-)

2016=E5=B9=B41=E6=9C=882=
1=E6=97=A5(=E6=9C=A8) 23:17 John Bradley <ve7jtb@ve7jtb.com>:
The code_challenge =
and code_challenge_method parameter names predate calling the spec =
PKCE.  

Given =
that some of us deployed early versions of PKCE in products and =
opensource to mitigate the problem before the spec was completed we =
decided not to rename the parameter names from code_verifier_method to =
pkce_verifier_method.  

For consistency we should stick with =
code_verifier_methods_supported in discovery.

John B.

On Jan 21, 2016, at 3:12 AM, William Denniss <wdenniss@google.com> wrote:

"code_challenge_methods_supported" =
definitely works for me.

Any objections to =
moving forward with that? I would like to update our discovery doc =
shortly.

On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura =
<sakimura@gmail.com> wrote:
Ah, OK. That's actually reasonable. 

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matake =
<matake@gmail.com>:
I =
prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since the =
registered parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, =
not =E2=80=9Cpkce_method".

On Jan 19, 2016, at 11:58, =
William Denniss <wdenniss@google.com> wrote:

Seems like we =
agree this should be added. How should it look?

Two ideas:

"code_challenge_methods_supported": ["plain", "S256"]

or

"pkce_methods_supported": =
["plain", "S256"]



On Wed, Jan 6, 2016 at 9:59 AM, =
Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

 =20
   =20
 =20
  

    +1


    

    
Am 06.01.2016 um 18:25 schrieb William
      Denniss:

    

    

      
+1

      


        
On Wed, Jan 6, 2016 at 6:40 AM, John
          Bradley <ve7jtb@ve7jtb.com>
          wrote:

          
Good
            point.  Now that PKCE is a RFC we should add it to
            discovery.

            

            John B.

            

              
> On Jan 6, 2016, at 9:29 AM, Vladimir
                Dzhuvinov <vladimir@connect2id.com>
                wrote:

                >

                > I just noticed PKCE support is missing from the
                discovery metadata.

                >

                > Is it a good idea to add it?

                >

                > Cheers,

                >

                > Vladimir

                >

                > --

                > 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

          

        

        

      

      

      

      

      
_______________________________________________
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


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

=

--Apple-Mail=_AD66F3AF-BAA0-4FB5-B010-BD6304ADBD89--


From nobody Mon Jan 25 10:35:36 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38391B38B3 for ; Mon, 25 Jan 2016 10:35:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.201
X-Spam-Level: 
X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pIgTZYoIxS4 for ; Mon, 25 Jan 2016 10:35:31 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3519E1B38B8 for ; Mon, 25 Jan 2016 10:35:29 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0PIZOtD018736 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 25 Jan 2016 18:35:25 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u0PIZNFs015966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 25 Jan 2016 18:35:23 GMT
Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userv0122.oracle.com (8.14.4/8.13.8) with ESMTP id u0PIZNZT007787; Mon, 25 Jan 2016 18:35:23 GMT
Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Jan 2016 10:35:22 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_0EBD37B6-95B8-4B57-A6FC-67A65421D897"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: <56A12010.6090700@aol.com>
Date: Mon, 25 Jan 2016 10:35:18 -0800
Message-Id: <790CD065-F04F-47EF-BFAD-ECE658ACC780@oracle.com>
References: <569E2231.1010107@gmx.net>  <6ADAA1B5-7EF9-49EA-A3D9-6EFC57275EB9@ve7jtb.com>    <9062E913-39FB-4610-80FE-70796CBDEAC1@ve7jtb.com>    <56A12010.6090700@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 18:35:35 -0000

--Apple-Mail=_0EBD37B6-95B8-4B57-A6FC-67A65421D897
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1. I think this helps clarify some mis-conceptions that are out there.

Phil

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






> On Jan 21, 2016, at 10:14 AM, George Fletcher  =
wrote:
>=20
> I'm also +1 for adoption
>=20
> On 1/21/16 2:56 AM, Roland Hedberg wrote:
>> +1 for adoption
>>=20
>>> 21 jan 2016 kl. 07:11 skrev William Denniss  =
:
>>>=20
>>> I believe this is important work.
>>>=20
>>> The original OAuth 2 spec left the topic of native apps largely =
undefined which is fair enough, the mobile-first revolution had yet to =
really take hold and people didn't have much implementation experience =
for OAuth on mobile. But we've come a long way since then, we have the =
experience now and I think there is a need for leadership in this space, =
and that it makes sense for the OAUTH-WG to continue our work and =
provide that leadership.
>>>=20
>>> The risk of not defining a best practice for native apps is dilution =
of the open standards =E2=80=93 if everyone implements OAuth differently =
for native apps, and RPs have to write IDP-specific code then what is =
the point of having OAuth as a standard in the first place? Security is =
a major concern as well, there are a lot of ways to mess this up and the =
security situation for OAuth in many native apps is not nearly as good =
as it could be.
>>>=20
>>> By providing leadership in the form of a working group document, we =
can present community advice with the hope that IDPs and RPs alike will =
follow our recommendations, resulting in more interoperability, better =
usability and higher security.
>>>=20
>>> The best part about this spec is that it's pure OAuth! Just wrapped =
with some native app specific recommendations for both RPs and IDPs, to =
achieve the desired levels of usability and security on mobile.
>>>=20
>>> I will point out that we have rough consensus and running code. The =
rough consensus can be seen from the WG votes, and the sentiment on this =
thread (your dissenting opinion notwithstanding). Regarding running =
code, my team is in the process of open sourcing libraries that will =
implement this best practice to the letter (and the code's already =
running, I assure you). The proprietary Google Sign-in and Facebook =
Sign-in SDKs are also using in-app browser tabs for OAuth flows in =
production today, which I think is further evidence that this is a =
viable pattern.
>>>=20
>>> This document and proposal was never part of the OpenID working =
group that you refer to below.
>>>=20
>>> I'm not saying the document is perfect, and it is definitely in need =
of an update! But I'm committed to listening to the community and taking =
it forward. Now that the dependencies have launched, and our library =
implementations are done, I plan to update the doc with the feedback =
from this community, and the lessons we and others have learnt from our =
implementations.
>>>=20
>>> I hope the working group will consider adopting this document.
>>>=20
>>> Kind Regards,
>>> William
>>>=20
>>>=20
>>> On Thu, Jan 21, 2016 at 12:33 PM, Anthony Nadalin =
  wrote:
>>> This work had many issues in the OpenID WG where it failed why =
should this be a WG item here ? The does meet the requirements for =
experimental, there is a fine line between informational and =
experimental, I would be OK with either but prefer experimental, I =
don=E2=80=99t think that this should become a standard.
>>>=20
>>>=20
>>>=20
>>> From: OAuth [mailto:oauth-bounces@ietf.org =
] On Behalf Of John Bradley
>>> Sent: Wednesday, January 20, 2016 12:11 PM
>>> To: Nat Sakimura  
>>> Cc: oauth@ietf.org 
>>> Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps
>>>=20
>>>=20
>>>=20
>>> PS as you probably suspected I am in favour of moving this forward.
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> On Jan 20, 2016, at 5:08 PM, Nat Sakimura  =
 wrote:
>>>=20
>>>=20
>>>=20
>>> +1 for moving this forward.
>>>=20
>>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5=E6=9C=A8=E6=9B=9C=E6=97=A5=E3=80=81=
John Bradley =
=E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=
=81=BE=E3=81=97=E3=81=9F:
>>>=20
>>> Yes more is needed.   It was theoretical at that point.  Now we have =
implementation experience.
>>>=20
>>>=20
>>>=20
>>> On Jan 20, 2016, at 3:38 PM, Brian Campbell =
  wrote:
>>>=20
>>>=20
>>>=20
>>> There is =
https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#appendix-A=
 =
 which has some mention of SFSafariViewController and Chrome Custom =
Tabs.
>>>=20
>>> Maybe more is needed?
>>>=20
>>>=20
>>>=20
>>> On Wed, Jan 20, 2016 at 10:45 AM, John Bradley  =
 wrote:
>>>=20
>>> Yes, in July we recommended using the system browser rather than =
WebViews.
>>>=20
>>>=20
>>>=20
>>> About that time Apple announced Safari view controller and Google =
Chrome custom tabs.   The code in the OS is now stable and we have done =
a fair amount of testing.
>>>=20
>>>=20
>>>=20
>>> The OIDF will shortly be publishing reference libraries for iOS and =
Android to how how to best use View Controllers, and PKCE in native apps =
on those platforms.
>>>=20
>>>=20
>>>=20
>>> We do need to update this doc to reflect what we have learned in the =
last 6 months.
>>>=20
>>>=20
>>>=20
>>> One problem we do still have is not having someone with Win 10 =
mobile experience to help document the best practices for that platform.
>>>=20
>>> I don=E2=80=99t understand that platform well enough yet to include =
anything.
>>>=20
>>>=20
>>>=20
>>> John B.
>>>=20
>>>=20
>>>=20
>>> On Jan 20, 2016, at 12:40 PM, Aaron Parecki  =
 wrote:
>>>=20
>>>=20
>>>=20
>>> The section on embedded web views doesn't mention the new iOS 9 =
SFSafariViewController which allows apps to display a system browser =
within the application. The new API doesn't give the calling application =
access to anything inside the browser, so it is acceptable for using =
with OAuth flows. I think it's important to mention this new capability =
for apps to leverage since it leads to a better user experience.
>>>=20
>>>=20
>>>=20
>>> I'm sure that can be addressed in the coming months if this document =
is just the starting point.
>>>=20
>>>=20
>>>=20
>>> I definitely agree that a document about native apps is necessary =
since the core leaves a lot of guessing room for an implementation.
>>>=20
>>>=20
>>>=20
>>> For reference, =
https://developer.apple.com/library/prerelease/ios/releasenotes/General/Wh=
atsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElem=
entID_26 =

>>>=20
>>>=20
>>>=20
>>> And see the attached screenshot for an example of what it looks =
like.
>>>=20
>>>=20
>>>=20
>>> 
>>>=20
>>>=20
>>>=20
>>> ----
>>>=20
>>> Aaron Parecki
>>>=20
>>> aaronparecki.com
>>>=20
>>> @aaronpk
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig =
  wrote:
>>>=20
>>> Hi all,
>>>=20
>>> this is the call for adoption of OAuth 2.0 for Native Apps, see
>>> http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/ =

>>>=20
>>> Please let us know by Feb 2nd whether you accept / object to the
>>> adoption of this document as a starting point for work in the OAuth
>>> working group.
>>>=20
>>> Note: If you already stated your opinion at the IETF meeting in =
Yokohama
>>> then you don't need to re-state your opinion, if you want.
>>>=20
>>> The feedback at the Yokohama IETF meeting was the following: 16 =
persons
>>> for doing the work / 0 persons against / 2 persons need more info
>>>=20
>>> Ciao
>>> Hannes & Derek
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

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

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

>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>> Nat Sakimura (=3Dnat)
>>>=20
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/ 
>>> @_nat_en
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

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

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

>=20
> --=20
> Chief Architect                  =20
> Identity Services Engineering     Work: george.fletcher@teamaol.com =

> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch =

> Office: +1-703-265-2544           Photos: =
http://georgefletcher.photography 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_0EBD37B6-95B8-4B57-A6FC-67A65421D897
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1. I think this helps clarify some mis-conceptions that are =
out there.








On Jan 21, 2016, at 10:14 AM, George Fletcher <gffletch@aol.com> =
wrote:


 =20
    
 =20
  

    I'm also +1 =
for adoption

    

    
On 1/21/16 2:56 AM, Roland Hedberg
      wrote:

    

    

      
+1 for adoption



      

        
21 jan 2016 kl. 07:11 skrev William =
Denniss <wdenniss@google.com>:

I believe this is important work.

The original OAuth 2 spec left the topic of native apps largely =
undefined which is fair enough, the mobile-first revolution had yet to =
really take hold and people didn't have much implementation experience =
for OAuth on mobile. But we've come a long way since then, we have the =
experience now and I think there is a need for leadership in this space, =
and that it makes sense for the OAUTH-WG to continue our work and =
provide that leadership.

The risk of not defining a best practice for native apps is dilution of =
the open standards =E2=80=93 if everyone implements OAuth differently =
for native apps, and RPs have to write IDP-specific code then what is =
the point of having OAuth as a standard in the first place? Security is =
a major concern as well, there are a lot of ways to mess this up and the =
security situation for OAuth in many native apps is not nearly as good =
as it could be.

By providing leadership in the form of a working group document, we can =
present community advice with the hope that IDPs and RPs alike will =
follow our recommendations, resulting in more interoperability, better =
usability and higher security.

The best part about this spec is that it's pure OAuth! Just wrapped with =
some native app specific recommendations for both RPs and IDPs, to =
achieve the desired levels of usability and security on mobile.

I will point out that we have rough consensus and running code. The =
rough consensus can be seen from the WG votes, and the sentiment on this =
thread (your dissenting opinion notwithstanding). Regarding running =
code, my team is in the process of open sourcing libraries that will =
implement this best practice to the letter (and the code's already =
running, I assure you). The proprietary Google Sign-in and Facebook =
Sign-in SDKs are also using in-app browser tabs for OAuth flows in =
production today, which I think is further evidence that this is a =
viable pattern.

This document and proposal was never part of the OpenID working group =
that you refer to below.

I'm not saying the document is perfect, and it is definitely in need of =
an update! But I'm committed to listening to the community and taking it =
forward. Now that the dependencies have launched, and our library =
implementations are done, I plan to update the doc with the feedback =
from this community, and the lessons we and others have learnt from our =
implementations.

I hope the working group will consider adopting this document.

Kind Regards,
William


On Thu, Jan 21, 2016 at 12:33 PM, Anthony Nadalin <tonynad@microsoft.com> =
wrote:
This work had many issues in the OpenID WG where it failed why should =
this be a WG item here ? The does meet the requirements for =
experimental, there is a fine line between informational and =
experimental, I would be OK with either but prefer experimental, I =
don=E2=80=99t think that this should become a standard.



From: OAuth [mailto:oauth-bounces@ietf.org] =
On Behalf Of John Bradley
Sent: Wednesday, January 20, 2016 12:11 PM
To: Nat Sakimura <sakimura@gmail.com>
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for adoption: OAuth 2.0 for Native Apps



PS as you probably suspected I am in favour of moving this forward.





On Jan 20, 2016, at 5:08 PM, Nat Sakimura <sakimura@gmail.com> wrote:



+1 for moving this forward.

2016=E5=B9=B41=E6=9C=8821=E6=97=A5=E6=9C=A8=E6=9B=9C=E6=97=A5=E3=80=81John=
 Bradley<ve7jtb@ve7jtb.com>=E3=81=95=E3=
=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=97=E3=81=9F:

Yes more is needed.   It was theoretical at that point.  Now we have =
implementation experience.



On Jan 20, 2016, at 3:38 PM, Brian Campbell <bcampbell@pingidentity.com&=
gt; wrote:



There is https://tools.ietf.org/html/draft-wdenniss-oauth-native-apps-00#=
appendix-A which has some mention of SFSafariViewController and =
Chrome Custom Tabs.

Maybe more is needed?



On Wed, Jan 20, 2016 at 10:45 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

Yes, in July we recommended using the system browser rather than =
WebViews.



About that time Apple announced Safari view controller and Google Chrome =
custom tabs.   The code in the OS is now stable and we have done a fair =
amount of testing.



The OIDF will shortly be publishing reference libraries for iOS and =
Android to how how to best use View Controllers, and PKCE in native apps =
on those platforms.



We do need to update this doc to reflect what we have learned in the =
last 6 months.



One problem we do still have is not having someone with Win 10 mobile =
experience to help document the best practices for that platform.

I don=E2=80=99t understand that platform well enough yet to include =
anything.



John B.



On Jan 20, 2016, at 12:40 PM, Aaron Parecki <aaron@parecki.com> wrote:



The section on embedded web views doesn't mention the new iOS 9 =
SFSafariViewController which allows apps to display a system browser =
within the application. The new API doesn't give the calling application =
access to anything inside the browser, so it is acceptable for using =
with OAuth flows. I think it's important to mention this new capability =
for apps to leverage since it leads to a better user experience.



I'm sure that can be addressed in the coming months if this document is =
just the starting point.



I definitely agree that a document about native apps is necessary since =
the core leaves a lot of guessing room for an implementation.



For reference, https://developer.apple.com/library/prerelease/ios/relea=
senotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP400=
16198-DontLinkElementID_26



And see the attached screenshot for an example of what it looks like.



<embedded-oauth-view.png>



----

Aaron Parecki

aaronparecki.com

@aaronpk





On Tue, Jan 19, 2016 at 3:46 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net>=
; wrote:

Hi all,

this is the call for adoption of OAuth 2.0 for Native Apps, see
http://datatracker.ietf.org/doc/draft-wdenniss-oauth-native-apps/

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

Note: If you already stated your opinion at the IETF meeting in Yokohama
then you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 16 persons
for doing the work / 0 persons against / 2 persons need more info

Ciao
Hannes & Derek


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



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




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







--
Nat Sakimura (=3Dnat)

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






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


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


      

      

      

      

      

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


    

    

    
--=20
Chief Architect                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photogra=
phy


  


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

=

--Apple-Mail=_0EBD37B6-95B8-4B57-A6FC-67A65421D897--


From nobody Mon Jan 25 10:39:49 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502811B38DC for ; Mon, 25 Jan 2016 10:39:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYLdz3tybnRD for ; Mon, 25 Jan 2016 10:39:44 -0800 (PST)
Received: from omr-a005e.mx.aol.com (omr-a005e.mx.aol.com [204.29.186.50]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3476E1B38D3 for ; Mon, 25 Jan 2016 10:39:44 -0800 (PST)
Received: from mtaout-aac01.mx.aol.com (mtaout-aac01.mx.aol.com [172.27.2.33]) by omr-a005e.mx.aol.com (Outbound Mail Relay) with ESMTP id 6FBEB3800099; Mon, 25 Jan 2016 13:39:43 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aac01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B04D138000084; Mon, 25 Jan 2016 13:39:42 -0500 (EST)
To: John Bradley 
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <995474C5-62E7-4310-84AF-A5EF1CDEA4DB@ve7jtb.com> <56A63F82.40104@aol.com> <6D8FA56F-EA72-4509-90C1-DC33094FA695@ve7jtb.com> <56A66522.1090804@aol.com> <23E34900-5C05-4295-AFC5-7DEBA6449AA7@ve7jtb.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56A66BED.3090505@aol.com>
Date: Mon, 25 Jan 2016 13:39:41 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <23E34900-5C05-4295-AFC5-7DEBA6449AA7@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------070400050909060501000100"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453747183; bh=7xas7XagrWS00du5fiqB72WRUL4ke3j206Eo20uKmfc=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=aL1czyL2pDV7aGbMQyqBMx4TnyYqojt9Zp1M85Ee7RhkEtU9njZGf10ktOBL4C54x 8BnH2MPHkVcMbQOnLQuMt4DB2MMoz24gzfcAExkUVaePkPtkcisLcoQPPyAeZUdB5v mY+I4Pa+yvW5JuModF0PGkl+QEXcikFWdj5yT/vM=
x-aol-sid: 3039ac1b022156a66bee66dd
X-AOL-IP: 10.172.102.124
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 18:39:47 -0000

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

So now, in addition to the dynamic client registration spec, the client 
would need to support OAuth2 Discovery.

I guess my concern is that it feels like we are adding a lot of little 
things to try and mitigate these attacks in OAuth2 and it's confusing 
when they are needed and when they aren't.

For me it would be simpler to say that OAuth2 with a single 
pre-configured AS is fine. If a client wants to support multiple 
Authorization Servers (a la dynamic client registration or some other 
method) then here are all the things that need to be done. Maybe this 
would be simpler as a profile of OAuth2 (in the vein of OpenID Connect) 
that adds the necessary requirements to mitigate these attacks.

This way an OAuth2 developer knows which spec to follow based on their 
requirements and all the necessary steps would be in "one" place.

Thanks,
George

On 1/25/16 1:22 PM, John Bradley wrote:
> The presumption is that registration would need to add a issuer, as an 
> identifier of the AS, and that would be optionally be used in discovery.
>
> OAuth as is supports the single AS model.
>
> To support multiple AS for a single client something needs to change. 
>    Adding issuer and client_id to the response with optional discovery 
> was seen as the least disruptive at the Germany meeting.
>
>  The other way to do it is to return discovery info from the the 
> authorization and token endpoints, however the request probably also 
> need to be modified so that the AS knows what the resource is, otherwise
> other things will break.
>
> It is possible now to have one authorization endpoint provide code for 
> per Tennent token endpoints.(No I don’t know of any one doing it).
>
> Anything we add to tighten up the trust model will have impacts on 
> what can be done with OAuth.
>
> John B.
>> On Jan 25, 2016, at 3:10 PM, George Fletcher > > wrote:
>>
>> Comments inline
>>
>> On 1/25/16 12:32 PM, John Bradley wrote:
>>> No, client id_are scoped by issuer.
>> This makes sense, but I'm not sure it's a current assumption by 
>> OAuth2 implementations :)
>>>
>>> There is no need for AS to make the client_id globally unique.
>>>
>>>  The client needs to not allow two AS to provide it with the same 
>>> issuer client_id pair.
>>>
>>> That would probably be imposable for many clients anyway.
>> I would rather say that the results of two client_ids being the same 
>> from two different issuers is undefined.
>>>
>>> For Connect clients typically manage configurations using issuer as 
>>> the primary key.  I doubt may would support even two client_id from 
>>> the same issuer.
>> If scoped by issuer this makes sense, though the concept of "issuer" 
>> as a comparable entity wasn't really talked about with OAuth2.
>>>
>>> For OAuth what clients do is slightly less clear.  In general they 
>>> don’t have more than one AS per API do might try and organize things 
>>> by RS or AS.
>> I agree that not many clients support dynamic client registration. 
>> However, I would say there a number that support multiple AS that are 
>> "fixed" within the code (including fixed endpoint URIs). So I would 
>> say that the associations would be fixed in code. There wouldn't 
>> necessarily be an association outside of the code which maps button A 
>> to AS1 and button B to AS2.
>>>
>>> In principal a OAuth client might have two different AS each with a 
>>> different client ID and that will be OK as long as the client_id in 
>>> the request is the same as the one in the response.
>>>
>>> So going to a new AS and getting back the same iss and client_id 
>>> that you registered someplace else would be an error for the client.
>>>
>>> I don’t think that is unreasonable.
>> I agree that this is reasonable with the assumption that client_id's 
>> are scoped by "issuer". It's just likely that most clients in the 
>> field do not have this sort of explicit association. The OAuth2 
>> Dynamic Client Registration spec does not define an "issuer" in the 
>> response. For the OAuth2 use cases, what is the proposed "issuer" 
>> equivalent URI that is being used to scope the client_id?
>>>
>>> John B.
>>>
>>>
>>>> On Jan 25, 2016, at 12:30 PM, George Fletcher >>> > wrote:
>>>>
>>>> I'm still catching up... but to this point specifically...
>>>>
>>>> Doesn't this require that the same client_id NOT be used 
>>>> simultaneously at two (or more) Authorization Servers? If so, I 
>>>> don't believe that is a viable option. It's a little late in the 
>>>> game to be putting requirements on the AS as to how it generates 
>>>> it's client_id.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>> On 1/25/16 9:11 AM, John Bradley wrote:
>>>>>
>>>>> Returning the iss and client_id from the authorization endpoint 
>>>>> per Mike’s draft allows the client to reject the authorization 
>>>>> response and not leak the code.
>>>>
>>>
>>
>> -- 
>> Chief Architect
>> Identity Services Engineering     Work:george.fletcher@teamaol.com
>> AOL Inc.                          AIM:  gffletch
>> Mobile: +1-703-462-3494           Twitter:http://twitter.com/gffletch
>> Office: +1-703-265-2544           Photos:http://georgefletcher.photography
>

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


--------------070400050909060501000100
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    So now, in addition to the
      dynamic client registration spec, the client would need to support
      OAuth2 Discovery.

      

      I guess my concern is that it feels like we are adding a lot of
      little things to try and mitigate these attacks in OAuth2 and it's
      confusing when they are needed and when they aren't.

      

      For me it would be simpler to say that OAuth2 with a single
      pre-configured AS is fine. If a client wants to support multiple
      Authorization Servers (a la dynamic client registration or some
      other method) then here are all the things that need to be done.
      Maybe this would be simpler as a profile of OAuth2 (in the vein of
      OpenID Connect) that adds the necessary requirements to mitigate
      these attacks.

      

      This way an OAuth2 developer knows which spec to follow based on
      their requirements and all the necessary steps would be in "one"
      place.

      

      Thanks,

      George

    

    
On 1/25/16 1:22 PM, John Bradley wrote:

    

    

      
      The presumption is that registration would need to add a issuer,
      as an identifier of the AS, and that would be optionally be used
      in discovery.
      


      

      
OAuth as is supports the single AS model.

      


      

      
To support multiple AS for a single client something
        needs to change.    Adding issuer and client_id to the response
        with optional discovery was seen as the least disruptive at the
        Germany meeting.

      


      

      
 The other way to do it is to return discovery info
        from the the authorization and token endpoints, however the
        request probably also need to be modified so that the AS knows
        what the resource is, otherwise 

      
other things will break.    

      


      

      
It is possible now to have one authorization
        endpoint provide code for per Tennent token endpoints.(No I
        don’t know of any one doing it).

      


      

      
Anything we add to tighten up the trust model will
        have impacts on what can be done with OAuth.  

      


      

      
John B.

      

        

          

            
On Jan 25, 2016, at 3:10 PM, George Fletcher
              <gffletch@aol.com>
              wrote:

            

            
Comments inline

              

              
On 1/25/16 12:32 PM, John Bradley
                wrote:

              

              
No,
                client id_are scoped by issuer.  

              

              This makes sense, but I'm not sure
                it's a current assumption by OAuth2 implementations :)

              

                


                

                
There is no need for AS to make the
                  client_id globally unique.

                


                

                
 The client needs to not allow two AS to
                  provide it with the same issuer client_id pair.

                  


                  

                  
That would probably be imposable for
                    many clients anyway. 

                  

                

              

              I would rather say that the
                results of two client_ids being the same from two
                different issuers is undefined.

              

                

                  


                  

                  
For Connect clients typically manage
                    configurations using issuer as the primary key.  I
                    doubt may would support even two client_id from the
                    same issuer.

                

              

              If scoped by issuer this makes
                sense, though the concept of "issuer" as a comparable
                entity wasn't really talked about with OAuth2.

              

                

                  


                  

                  
For OAuth what clients do is slightly
                    less clear.  In general they don’t have more than
                    one AS per API do might try and organize things by
                    RS or AS.

                

              

              I agree that not many clients
                support dynamic client registration. However, I would
                say there a number that support multiple AS that are
                "fixed" within the code (including fixed endpoint URIs).
                So I would say that the associations would be fixed in
                code. There wouldn't necessarily be an association
                outside of the code which maps button A to AS1 and
                button B to AS2.

              

                

                  


                  

                  
In principal a OAuth client might have
                    two different AS each with a different client ID and
                    that will be OK as long as the client_id in the
                    request is the same as the one in the response.

                  


                  

                  
So going to a new AS and getting back
                    the same iss and client_id that you registered
                    someplace else would be an error for the client.

                  


                  

                  
I don’t think that is unreasonable.

                

              

              I agree that this is reasonable
                with the assumption that client_id's are scoped by
                "issuer". It's just likely that most clients in the
                field do not have this sort of explicit association. The
                OAuth2 Dynamic Client Registration spec does not define
                an "issuer" in the response. For the OAuth2 use cases,
                what is the proposed "issuer" equivalent URI that is
                being used to scope the client_id? 

              

                

                  


                  

                  
John B.

                  


                  

                  


                    

                      

                        
On Jan 25, 2016, at 12:30 PM,
                          George Fletcher <gffletch@aol.com>
                          wrote:

                        

                        

                          
I'm still catching up... but
                              to this point specifically...

                              

                              Doesn't this require that the same
                              client_id NOT be used simultaneously at
                              two (or more) Authorization Servers? If
                              so, I don't believe that is a viable
                              option. It's a little late in the game to
                              be putting requirements on the AS as to
                              how it generates it's client_id.

                              

                              Thanks,

                              George

                            

                            
On 1/25/16 9:11
                              AM, John Bradley wrote:

                            

                            

                              


                              

                              
Returning the iss and
                                client_id from the authorization
                                endpoint per Mike’s draft allows the
                                client to reject the authorization
                                response and not leak the code.

                            

                            

                          

                        

                      

                    

                    

                  

                

              

              

              
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


            

          

        

        

      

    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------070400050909060501000100--


From nobody Mon Jan 25 10:42:07 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD761B38F4 for ; Mon, 25 Jan 2016 10:42:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ET8IJjl5l2UP for ; Mon, 25 Jan 2016 10:42:04 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDBB61B38DA for ; Mon, 25 Jan 2016 10:42:03 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0PIfw1P009768 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 25 Jan 2016 18:41:58 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u0PIfvrk003552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 25 Jan 2016 18:41:57 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.13.8) with ESMTP id u0PIfvsL011509; Mon, 25 Jan 2016 18:41:57 GMT
Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Jan 2016 10:41:57 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_4617FC26-DBB8-4FD4-BFD5-F4D09D28887C"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: 
Date: Mon, 25 Jan 2016 10:41:46 -0800
Message-Id: <558BEED7-2716-4B63-9F0C-5E740D6839C8@oracle.com>
References: <569E2260.4080904@gmx.net>   
To: Nat Sakimura 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 18:42:06 -0000

--Apple-Mail=_4617FC26-DBB8-4FD4-BFD5-F4D09D28887C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

+1.  I agree with Nat=E2=80=99s comment re the title.

Also, I would like to have a discussion in the WG around organization of =
the docs. What can we amend as errata (to give some of this stuff more =
prominence), and what new docs we should have?  With PKCE, mix-up, and =
this, we may end up causing more confusion or at the very least by =
having multiple =E2=80=9Cpoint=E2=80=9D issue specs.

Phil

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






> On Jan 21, 2016, at 6:28 AM, Nat Sakimura  wrote:
>=20
> +1 apart from the title... It sounds like the spec is implementing =
OAuth Open Redirector...=20
> Something like "preventing OAuth open redirector" or so might be more =
descriptive.=20
>=20
> Nat
>=20
> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:08 John Bradley =
>:
> +1 for adoption
>=20
>> On Jan 21, 2016, at 3:18 AM, William Denniss > wrote:
>>=20
>> +1 for adoption.
>>=20
>> On Tue, Jan 19, 2016 at 7:47 PM, Hannes Tschofenig =
> wrote:
>> Hi all,
>>=20
>> this is the call for adoption of OAuth 2.0 Security: OAuth Open
>> Redirector, see
>> https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02 =

>>=20
>> Please let us know by Feb 2nd whether you accept / object to the
>> adoption of this document as a starting point for work in the OAuth
>> working group.
>>=20
>> Note: At the IETF Yokohama we asked for generic feedback about doing
>> security work in the OAuth working group and there was very positive
>> feedback. However, for the adoption call we need to ask for =
individual
>> documents. Hence, you need to state your view again.
>>=20
>> Ciao
>> Hannes & Derek
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

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

>=20
> _______________________________________________
> 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=_4617FC26-DBB8-4FD4-BFD5-F4D09D28887C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

+1.  I agree with Nat=E2=80=99s comment re the =
title.

Also, I would =
like to have a discussion in the WG around organization of the docs. =
What can we amend as errata (to give some of this stuff more =
prominence), and what new docs we should have?  With PKCE, mix-up, =
and this, we may end up causing more confusion or at the very least by =
having multiple =E2=80=9Cpoint=E2=80=9D issue specs.








On Jan 21, 2016, at 6:28 AM, Nat Sakimura <sakimura@gmail.com> =
wrote:

+1 apart from the title... It sounds like the =
spec is implementing OAuth Open Redirector... 
Something like "preventing OAuth open redirector" or so might =
be more descriptive. 

Nat

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) =
23:08 John Bradley <ve7jtb@ve7jtb.com>:
+1 =
for adoption

On Jan 21, 2016, at 3:18 AM, William Denniss =
<wdenniss@google.com> wrote:

+1 for adoption.

On Tue, =
Jan 19, 2016 at 7:47 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> =
wrote:
Hi all,



this is the call for adoption of OAuth 2.0 Security: OAuth Open

Redirector, see

https://tools.ietf.org/html/draft-bradley-oauth-open-redirector=
-02



Please let us know by Feb 2nd whether you accept / object to the

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

working group.



Note: At the IETF Yokohama we asked for generic feedback about doing

security work in the OAuth working group and there was very positive

feedback. However, for the adoption call we need to ask for =
individual

documents. Hence, you need to state your view again.



Ciao

Hannes & Derek










_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



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

=

--Apple-Mail=_4617FC26-DBB8-4FD4-BFD5-F4D09D28887C--


From nobody Mon Jan 25 10:44:58 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A491B38FA for ; Mon, 25 Jan 2016 10:44:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RbNnIxsvBYG for ; Mon, 25 Jan 2016 10:44:54 -0800 (PST)
Received: from omr-m020e.mx.aol.com (omr-m020e.mx.aol.com [204.29.186.20]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013E11B38F6 for ; Mon, 25 Jan 2016 10:44:53 -0800 (PST)
Received: from mtaout-aag01.mx.aol.com (mtaout-aag01.mx.aol.com [172.26.126.77]) by omr-m020e.mx.aol.com (Outbound Mail Relay) with ESMTP id 24A213800057; Mon, 25 Jan 2016 13:44:53 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aag01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 43D063800012E; Mon, 25 Jan 2016 13:44:52 -0500 (EST)
To: Phil Hunt , Nat Sakimura 
References: <569E2260.4080904@gmx.net>    <558BEED7-2716-4B63-9F0C-5E740D6839C8@oracle.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56A66D23.7080906@aol.com>
Date: Mon, 25 Jan 2016 13:44:51 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <558BEED7-2716-4B63-9F0C-5E740D6839C8@oracle.com>
Content-Type: multipart/alternative; boundary="------------020007000508000602060303"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453747493; bh=aXITLoCzCTZsCffUpjG1nY3iyP55Ej/CVaYQwNLlTsk=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=K/QC4ml/Gpn/jPzBVq11VP28352AMG9ej32c9oD62MPswftGFZ55a4/EiVY5UbUQO K1dWMOhCGjW2dfbah+OSYg8R5ufOSJ5y3DC6VbUltaOrN9wpGAkGoUMzTIjydU8ZII qXICBhmyesuve1+STbGLfB5GHHJIlyBqf7YdkZhQ=
x-aol-sid: 3039ac1a7e4d56a66d240d03
X-AOL-IP: 10.172.102.124
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Security: OAuth Open Redirector
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 18:44:56 -0000

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

+1

On 1/25/16 1:41 PM, Phil Hunt wrote:
> Also, I would like to have a discussion in the WG around organization 
> of the docs. What can we amend as errata (to give some of this stuff 
> more prominence), and what new docs we should have?  With PKCE, 
> mix-up, and this, we may end up causing more confusion or at the very 
> least by having multiple “point†issue specs.
>
> Phil
>
> @independentid
> www.independentid.com 
> phil.hunt@oracle.com 
>
>
>
>
>
>> On Jan 21, 2016, at 6:28 AM, Nat Sakimura > > wrote:
>>
>> +1 apart from the title... It sounds like the spec is implementing 
>> OAuth Open Redirector...
>> Something like "preventing OAuth open redirector" or so might be more 
>> descriptive.
>>
>> Nat
>>
>> 2016年1月21日(木) 23:08 John Bradley > >:
>>
>>     +1 for adoption
>>
>>>     On Jan 21, 2016, at 3:18 AM, William Denniss
>>>     > wrote:
>>>
>>>     +1 for adoption.
>>>
>>>     On Tue, Jan 19, 2016 at 7:47 PM, Hannes Tschofenig
>>>     >
>>>     wrote:
>>>
>>>         Hi all,
>>>
>>>         this is the call for adoption of OAuth 2.0 Security: OAuth Open
>>>         Redirector, see
>>>         https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02
>>>
>>>         Please let us know by Feb 2nd whether you accept / object to the
>>>         adoption of this document as a starting point for work in
>>>         the OAuth
>>>         working group.
>>>
>>>         Note: At the IETF Yokohama we asked for generic feedback
>>>         about doing
>>>         security work in the OAuth working group and there was very
>>>         positive
>>>         feedback. However, for the adoption call we need to ask for
>>>         individual
>>>         documents. Hence, you need to state your view again.
>>>
>>>         Ciao
>>>         Hannes & Derek
>>>
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         OAuth mailing list
>>>         OAuth@ietf.org 
>>>         https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>     _______________________________________________
>>>     OAuth mailing list
>>>     OAuth@ietf.org 
>>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>>     _______________________________________________
>>     OAuth mailing list
>>     OAuth@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


--------------020007000508000602060303
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    +1

    

    
On 1/25/16 1:41 PM, Phil Hunt wrote:

    

    

      
      
Also, I would like to have a discussion in the WG
        around organization of the docs. What can we amend as errata (to
        give some of this stuff more prominence), and what new docs we
        should have?  With PKCE, mix-up, and this, we may end up causing
        more confusion or at the very least by having multiple “pointâ€
        issue specs.

        


        

        

          
          

          

            

              
On Jan 21, 2016, at 6:28 AM, Nat Sakimura
                <sakimura@gmail.com>
                wrote:

              

              

                
+1 apart from the title... It
                  sounds like the spec is implementing OAuth Open
                  Redirector... 

                  
Something like "preventing OAuth open
                    redirector" or so might be more descriptive. 

                  


                  

                  
Nat

                

                

                

                  
2016年1月21日(木) 23:08 John
                    Bradley <ve7jtb@ve7jtb.com>:

                  

                  

                    
+1 for
                      adoption

                    

                      


                        

                          

                            
On Jan 21, 2016, at 3:18 AM,
                              William Denniss <wdenniss@google.com>
                              wrote:

                            

                            

                              
+1 for adoption.

                              


                                
On Tue, Jan 19,
                                  2016 at 7:47 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net>
                                  wrote:

                                  
Hi all,

                                    

                                    this is the call for adoption of
                                    OAuth 2.0 Security: OAuth Open

                                    Redirector, see

                                    https://tools.ietf.org/html/draft-bradley-oauth-open-redirector-02

                                    

                                    Please let us know by Feb 2nd
                                    whether you accept / object to the

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

                                    working group.

                                    

                                    Note: At the IETF Yokohama we asked
                                    for generic feedback about doing

                                    security work in the OAuth working
                                    group and there was very positive

                                    feedback. However, for the adoption
                                    call we need to ask for individual

                                    documents. Hence, you need to state
                                    your view again.

                                    

                                    Ciao

                                    Hannes & Derek

                                    

                                    

                                    

                                    

                                    

_______________________________________________

                                    OAuth mailing list

                                    OAuth@ietf.org

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

                                    

                                  

                                

                                

                              

_______________________________________________

                              OAuth mailing list

                              OAuth@ietf.org

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

                            

                          

                        

                        

                      

                    

                    _______________________________________________

                    OAuth mailing list

                    OAuth@ietf.org

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

                  

                

                _______________________________________________

                OAuth mailing list

                OAuth@ietf.org

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

              

            

          

          

        

      

      

      

      

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


    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------020007000508000602060303--


From nobody Mon Jan 25 10:58:30 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246BC1B3918 for ; Mon, 25 Jan 2016 10:58:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-pcjhYmBTmZ for ; Mon, 25 Jan 2016 10:58:28 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21AE21B38DE for ; Mon, 25 Jan 2016 10:58:28 -0800 (PST)
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 u0PIwOrC032714 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Jan 2016 18:58:25 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 u0PIwOBl008191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 25 Jan 2016 18:58:24 GMT
Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u0PIwNEn013120; Mon, 25 Jan 2016 18:58:24 GMT
Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Jan 2016 10:58:23 -0800
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: <56A66BED.3090505@aol.com>
Date: Mon, 25 Jan 2016 10:58:21 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <8EBCD2DD-D9D8-4AFD-A12F-A8C5C9DC4C06@oracle.com>
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <995474C5-62E7-4310-84AF-A5EF1CDEA4DB@ve7jtb.com> <56A63F82.40104@aol.com> <6D8FA56F-EA72-4509-90C1-DC33094FA695@ve7jtb.com> <56A66522.1090804@aol.com> <23E34900-5C05-4295-AFC5-7DEBA6449AA7@ve7jtb.com> <56A66BED.3090505@aol.com>
To: George Fletcher 
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 18:58:29 -0000

I recall making this point in Germany. 99% of existing use is fine. OIDC is p=
robably the largest community that *might* have an issue.=20

I recall proposing a new security document that covers oauth security for dy=
namic scenarios. "Dynamic" being broadly defined to mean:
* clients who have configured at runtime or install time (including clients t=
hat do discovery)
* clients that communicate with more than one endpoint
* clients that are deployed in large volume and may update frequently (more d=
iscussion of "public" cases)
* clients that are script based (loaded into browser on the fly)
* others?

Phil

> On Jan 25, 2016, at 10:39, George Fletcher  wrote:
>=20
> would


From nobody Mon Jan 25 12:12:03 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB331A00E6 for ; Mon, 25 Jan 2016 12:12:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level: 
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQfr9KM49ndF for ; Mon, 25 Jan 2016 12:12:00 -0800 (PST)
Received: from omr-a002e.mx.aol.com (omr-a002e.mx.aol.com [204.29.186.56]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329C41A00E4 for ; Mon, 25 Jan 2016 12:11:58 -0800 (PST)
Received: from mtaout-maa01.mx.aol.com (mtaout-maa01.mx.aol.com [172.26.222.141]) by omr-a002e.mx.aol.com (Outbound Mail Relay) with ESMTP id 3F7C03800072; Mon, 25 Jan 2016 15:11:57 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-maa01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 98D8B3800009C; Mon, 25 Jan 2016 15:11:56 -0500 (EST)
To: Mike Jones , "oauth@ietf.org" 
References: 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56A6818C.2090808@aol.com>
Date: Mon, 25 Jan 2016 15:11:56 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020400080000070800030902"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453752717; bh=0IiBCrVhHeKWoelYfN4mIg6OAr2qu62MTzjsIVtgrwg=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=FutnaG5YK7zUYeyO5bQinwVZr+npkJGkKnpxPbbQkrUwYYL/e6SDVLgnbc/jOxy12 O7thYJOOT/voJQFgO5nXLSOAPLalOdsjB/WwAeQEwBnm/nu9p7loYkaJsPB/HS3nYx U51bMAqHkTM8YfGusqVHtpTiiQbEKo5k+MVaPvEM=
x-aol-sid: 3039ac1ade8d56a6818c3c92
X-AOL-IP: 10.172.102.124
Archived-At: 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 20:12:02 -0000

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

Thanks for the write up John and Mike!

1. Editorial: I'd add something like the following to the last paragraph 
in section 2. "However, if the authorization server does not support 
OAuth Discovery, then it MUST publicly define it's AS issuer URI." The 
point being that the client has to have a way to obtain this value so 
that it can compare it later on in the protocol.

2. Question: If OAuth2 discovery is not required, how does a simple 
issuer compare prevent the attack? It seems like the malicious AS could 
get the client to statically configure Good Issuer, Good AuthZ, Bad 
Token endpoint and assign the client a client_id that is valid at the 
Good AS. When the Good AS returns the response data it would include 
it's iss and the client_id which would match and the client would still 
send the code and client credentials to the Bad AS. I believe that 
supporting OAuth discovery is going to be required to fully mitigate 
this attack.

3. Question: In section 7.3 the phrase "unsigned cookie" is used but 
it's not clear exactly what that means. While the attacker can set 
cookies in the forged response, they shouldn't be able to set cookies on 
the specific domain of the AS. If the cookie identifying the AS session 
is HTTP Only and Secure, then the attacker should not be able to see or 
forge a value for this cookie. The attacker could bypass the browser 
completely and just forge a request to the client specifying whatever 
values they like. These could be taken from a valid session the attacker 
created and can see from their browser. It seems like the key protection 
in this case is binding the state value into the code so the code can't 
be substituted.

Thanks,
George

On 1/21/16 1:28 AM, Mike Jones wrote:
>
> John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up 
> Mitigation draft.  Changes were:
>
> ·Simplified by no longer specifying the signed JWT method for 
> returning the mitigation information.
>
> ·Simplified by no longer depending upon publication of a discovery 
> metadata document.
>
> ·Added the “state” token request parameter.
>
> ·Added examples.
>
> ·Added John Bradley as an editor.
>
> The specification is available at:
>
> ·http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01
>
> An HTML-formatted version is also available at:
>
> ·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html
>
> -- Mike
>
> P.S.  This note was also posted athttp://self-issued.info/?p=1526 and 
> as @selfissued .
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


--------------020400080000070800030902
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Thanks for the write up
      John and Mike!

      

      1. Editorial: I'd add something like the following to the last
      paragraph in section 2. "However, if the authorization server does
      not support OAuth Discovery, then it MUST publicly define it's AS
      issuer URI." The point being that the client has to have a way to
      obtain this value so that it can compare it later on in the protocol.

      

      2. Question: If OAuth2 discovery is not required, how does a
      simple issuer compare prevent the attack? It seems like the
      malicious AS could get the client to statically configure Good
      Issuer, Good AuthZ, Bad Token endpoint and assign the client a
      client_id that is valid at the Good AS. When the Good AS returns
      the response data it would include it's iss and the client_id
      which would match and the client would still send the code and
      client credentials to the Bad AS. I believe that supporting OAuth
      discovery is going to be required to fully mitigate this attack.

      

      3. Question: In section 7.3 the phrase "unsigned cookie" is used
      but it's not clear exactly what that means. While the attacker can
      set cookies in the forged response, they shouldn't be able to set
      cookies on the specific domain of the AS. If the cookie
      identifying the AS session is HTTP Only and Secure, then the
      attacker should not be able to see or forge a value for this
      cookie. The attacker could bypass the browser completely and just
      forge a request to the client specifying whatever values they
      like. These could be taken from a valid session the attacker
      created and can see from their browser. It seems like the key
      protection in this case is binding the state value into the code
      so the code can't be substituted.

      

      Thanks,

      George

    

    
On 1/21/16 1:28 AM, Mike Jones wrote:

    

    

      
      
      
      

        
John Bradley and I collaborated to create
          the second OAuth 2.0 Mix-Up Mitigation draft.  Changes were:

        
·      
              Simplified by no longer
          specifying the signed JWT method for returning the mitigation
          information.

        
·      
              Simplified by no longer
          depending upon publication of a discovery metadata document.
          

        
·      
              Added the “state”
          token request parameter.

        
·      
              Added examples.

        
·      
              Added John Bradley as
          an editor.

        
 

        
The specification is available at:

        
·      
              http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01

        
 

        
An HTML-formatted version is also available
          at:

        
·      
              http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html

        
 

        
                                                         
          -- Mike

        
 

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

        
 

      

      

      

      

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


    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------020400080000070800030902--


From nobody Mon Jan 25 13:12:27 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14FEE1A0267 for ; Mon, 25 Jan 2016 13:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAEaBBmxux6J for ; Mon, 25 Jan 2016 13:12:24 -0800 (PST)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417D41A0266 for ; Mon, 25 Jan 2016 13:12:24 -0800 (PST)
Received: by mail-oi0-x233.google.com with SMTP id k206so97233279oia.1 for ; Mon, 25 Jan 2016 13:12:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mICYPr25sdvZA87MUcBsz3PL1ntvFqlrMZhpGFHk3aM=; b=WVs2srmXJIm/kVDL6cLD+nx/9XvaHM9xMJCQjafhFYARNnJ3togzUpMvbVIBcxn5Z5 3oG0o8CyG8ZeE9rARfILJ9XYK9xNhkLGE9YtWLEFMjKwzzYdInwOzWXyL060vjvIN/+6 bvdieNJBxV3SSVF2R7MG+2Ko5MWuNXPY++vcFUAgRUfPtM9euZa2Wd6GAbqQ0KIDaR6t w5yUach2y7kfV3Xhnf06mzaa98gWZhQv55zl2oC7XTysMcHbN/CWiIO5hg89wdoLMcZ9 09qFC/bhqflphfY9oUhBbdrvgP81vXZ8maq+2YrC1MKyUA96a2zi9uHDYdI46cus0I2+ pM2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mICYPr25sdvZA87MUcBsz3PL1ntvFqlrMZhpGFHk3aM=; b=UNAYCvW89Y/YSeQCsJ3hKONBlaLhxckIXI9nGiAn4S831YpK3o+2xIJpYI9nV9ftcf r2TcGdBs7cByeKnfcdfWe/witZ/bIBmr28iLf8sFREOP1osgqHU7z8Zzo81IZw9zu2z4 a21zN+sFD/X/25X3BqducptUS7to+GWcshEQTnVdaGyYwEkY5f6RTQW9E9RXCqveS1q+ XNPdHkNckilbUs3p0Je+lInOtq/ATLGfipbXHVinRj6N6JqiXWmLcl8n+xu4Ji/LzkkL uZNBUUA1t5HNyhmSJSs9jyNm6ucjx7rbRbpVgddPH1BX2bAKpuZ1X3AG5jQ9KrHlskv/ LJBw==
X-Gm-Message-State: AG10YOTxVsHzHkDFi7Uicu2KJTtII7nOU+ogh8GF0kpKFeo/Iksg1b+DQhmEujmuh2C7FxWbdgEeskZbU+Tlu8AX
X-Received: by 10.202.48.6 with SMTP id w6mr14432742oiw.97.1453756343526; Mon, 25 Jan 2016 13:12:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.227.39 with HTTP; Mon, 25 Jan 2016 13:12:04 -0800 (PST)
In-Reply-To: <10631235-AF1B-4122-AEAE-D56BBF38F87E@ve7jtb.com>
References: <568D24DD.3050501@connect2id.com>   <568D5610.6000506@lodderstedt.net>     <10631235-AF1B-4122-AEAE-D56BBF38F87E@ve7jtb.com>
From: William Denniss 
Date: Mon, 25 Jan 2016 13:12:04 -0800
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=001a113cd986727228052a2f06cb
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 21:12:26 -0000

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

On Thu, Jan 21, 2016 at 6:17 AM, John Bradley  wrote:

> The code_challenge and code_challenge_method parameter names predate
> calling the spec PKCE.
>
> Given that some of us deployed early versions of PKCE in products and
> opensource to mitigate the problem before the spec was completed we decid=
ed
> not to rename the parameter names from code_verifier_method to
> pkce_verifier_method.
>
> For consistency we should stick with code_verifier_methods_supported in
> discovery.
>

To clarify, did you mean "code_challenge_methods_supported"?  That is,
building on the param name "code_challenge_method" from Section 4.3
?


>
> John B.
>
> On Jan 21, 2016, at 3:12 AM, William Denniss  wrote:
>
> "code_challenge_methods_supported" definitely works for me.
>
> Any objections to moving forward with that? I would like to update our
> discovery doc shortly.
>
> On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura  wrote:
>
>> Ah, OK. That's actually reasonable.
>>
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matake :
>>
>>> I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since the =
registered
>>> parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, not =E2=80=
=9Cpkce_method".
>>>
>>> On Jan 19, 2016, at 11:58, William Denniss  wrote:
>>>
>>> Seems like we agree this should be added. How should it look?
>>>
>>> Two ideas:
>>>
>>> "code_challenge_methods_supported": ["plain", "S256"]
>>>
>>> or
>>>
>>> "pkce_methods_supported": ["plain", "S256"]
>>>
>>>
>>>
>>> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt <
>>> torsten@lodderstedt.net> wrote:
>>>
>>>> +1
>>>>
>>>>
>>>> Am 06.01.2016 um 18:25 schrieb William Denniss:
>>>>
>>>> +1
>>>>
>>>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley  wrote=
:
>>>>
>>>>> Good point.  Now that PKCE is a RFC we should add it to discovery.
>>>>>
>>>>> John B.
>>>>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <
>>>>> vladimir@connect2id.com> wrote:
>>>>> >
>>>>> > I just noticed PKCE support is missing from the discovery metadata.
>>>>> >
>>>>> > Is it a good idea to add it?
>>>>> >
>>>>> > Cheers,
>>>>> >
>>>>> > Vladimir
>>>>> >
>>>>> > --
>>>>> > 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
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing listOAuth@ietf.orghttps://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
>
>
>

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




On Thu, Jan 21, 2016 at 6:17 AM, John Bradley <ve7jtb@ve7jtb.com&g=
t; wrote:
Th=
e code_challenge and=C2=A0code_challenge_method parameter names predate cal=
ling the spec PKCE. =C2=A0

Given that some of us deploye=
d early versions of PKCE in products and opensource to mitigate the problem=
 before the spec was completed we decided not to rename the parameter names=
 from code_verifier_method to pkce_verifier_method. =C2=A0

For consistency we should stick with code_verifier_methods_support=
ed in discovery.

To clarify, di=
d you mean "code_challenge_methods_supported"?=C2=A0 That is, bui=
lding on the param name "code_challenge_method" from Section 4.3?
=
=C2=A0
<=
br>
John B.

On Jan 21, 2016, at 3:12 AM, William Denniss <wdenniss@google.com&=
gt; wrote:

"code_challenge_methods_suppor=
ted" definitely works for me.<=
/span>

Any objections to moving forward with that? I would=
 like to update our discovery doc shortly.

On Thu, Jan 21, 2016 at 1:37 PM=
, Nat Sakimura <sakimura@gmail.com> wrote:
Ah, OK. That's actually reasonable.=C2=A0
2016=E5=B9=B41=E6=9C=8821=E6=
=97=A5(=E6=9C=A8) 9:31 nov matake <matake@gmail.com>:
I prefer =E2=80=9Ccode_challenge_me=
thods_supported=E2=80=9D, since the registered parameter name is =E2=80=9Cc=
ode_challenge_method=E2=80=9D, not =E2=80=9Cpkce_method".

O=
n Jan 19, 2016, at 11:58, William Denniss <wdenniss@google.com> wrote:

Seems like we agree this should be added. How should it =
look?

Two ideas:

"code_challenge_methods_supported"=
: ["plain", "S256"]

or
"pkce_methods_supported": ["plain", "S256&qu=
ot;]



On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

 =20
   =20
 =20
  

    +1


    

    
Am 06.01.2016 um 18:25 schrieb William
      Denniss:

    

    

      
+1

      


        
On Wed, Jan 6, 2016 at 6:40 AM, John
          Bradley <ve7jtb@ve7jtb.com>
          wrote:

          
Good
            point.=C2=A0 Now that PKCE is a RFC we should add it to
            discovery.

            

            John B.

            

              
> On Jan 6, 2016, at 9:29 AM, Vladimir
                Dzhuvinov <vladimir@connect2id.com>
                wrote:

                >

                > I just noticed PKCE support is missing from the
                discovery metadata.

                >

                > Is it a good idea to add it?

                >

                > Cheers,

                >

                > Vladimir

                >

                > --

                > Vladimir Dzhuvinov

                >

                >

              

            

            > _______________________________________________

            > OAuth mailing list

            > OAuth@=
ietf.org

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

            

            _______________________________________________

            OAuth mailing list

            OAuth@ietf.=
org

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

          

        

        

      

      

      

      

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


    

    

  





_______________________________________________
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






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



--001a113cd986727228052a2f06cb--


From nobody Mon Jan 25 14:11:26 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D581A1A7F for ; Mon, 25 Jan 2016 14:11:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR4ss1JIT1bM for ; Mon, 25 Jan 2016 14:11:22 -0800 (PST)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E101F1A1A7B for ; Mon, 25 Jan 2016 14:11:21 -0800 (PST)
Received: by mail-qg0-x231.google.com with SMTP id 6so120240795qgy.1 for ; Mon, 25 Jan 2016 14:11:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=eW+6icJc5f7YpVtHt477PbhIACohV1+CR2hhGBKuE5U=; b=QBvzl3PqXO/fmUEBZLxc8ov3Z0p3LtHzvRobDziG7bbIE71olROiUkIKy560sA0cUV E6kSHL+s5K486wzXn2kwldVpd2y2Bx7EhPTfL2KY6aKHbchWEjhQQFfI10L6Xz48v+a8 Ej745hT0lB3rmoxbba7M5ciDbPs/ybowmbSoZFIxby3EmMCXH53GbOnehpn5wHXDypWS bLwk8lTirebVTNkoYYjTC22DZqBmSmdHq2qk9lm3QdSoGj3UAqtH9WO6PUNYBFzZI98H zBjD3tdeVrfCRXUWo75uVMj7g+gGzMZ9yhrtMdHHXUJEnPSphfPBqYR4HHDLShLiwOwp j9Vg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=eW+6icJc5f7YpVtHt477PbhIACohV1+CR2hhGBKuE5U=; b=YHdWsKjiLjx2T86nke2/eRNIPuU7fEGe3N6FrmIffl2yx5iCNNgIuESHZkfk2Hn6Nd lIh/HSfT8f2THzkOGQXTAxt+Mb0sKhgnucMksdls23JmgaqbSIRrdYx2TupWSHn1M+yv hZZy6y7u3jUSwj4CUbTMbyIraNLTFvfoNhUlq1eGGYvTTLRWinnBucAD4SuWjgCebH1c bsjnOejpkAWwa/x53ztSNT36OLns3MtnEk1IJGSziuhV7lLawKlDf8Bq49pnGrTOwiEl G9CurBGuOqCXqey46ZqGxVnrLwr98pxMHuaHjuDVcdi3uzXPUZR2fUDExmem0accnwSy sM6w==
X-Gm-Message-State: AG10YOQD2phKqILbkI/qxaZve3vhC/hwbO+jAk5xZHfaf0uhFK+BjxMwnazTtUB3G/cXHw==
X-Received: by 10.140.94.68 with SMTP id f62mr24504991qge.0.1453759880978; Mon, 25 Jan 2016 14:11:20 -0800 (PST)
Received: from [192.168.8.101] ([181.202.242.181]) by smtp.gmail.com with ESMTPSA id s90sm9544198qgs.13.2016.01.25.14.11.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 14:11:20 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_FC0CF0E8-DBC5-45BC-B8DA-022FF6F764C1"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Mon, 25 Jan 2016 19:11:17 -0300
Message-Id: <6F32C1CF-EA2A-4A74-A694-F52FD19DBA5C@ve7jtb.com>
References: <568D24DD.3050501@connect2id.com>   <568D5610.6000506@lodderstedt.net>     <10631235-AF1B-4122-AEAE-D56BBF38F87E@ve7jtb.com> 
To: William Denniss 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 22:11:25 -0000

--Apple-Mail=_FC0CF0E8-DBC5-45BC-B8DA-022FF6F764C1
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_36D68B53-6F32-41F5-A56A-1E47D7082749"


--Apple-Mail=_36D68B53-6F32-41F5-A56A-1E47D7082749
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes sorry.   code_challenge_method is the query parameter so =
code_challenge_methods_supported


> On Jan 25, 2016, at 6:12 PM, William Denniss  =
wrote:
>=20
>=20
>=20
> On Thu, Jan 21, 2016 at 6:17 AM, John Bradley > wrote:
> The code_challenge and code_challenge_method parameter names predate =
calling the spec PKCE. =20
>=20
> Given that some of us deployed early versions of PKCE in products and =
opensource to mitigate the problem before the spec was completed we =
decided not to rename the parameter names from code_verifier_method to =
pkce_verifier_method. =20
>=20
> For consistency we should stick with code_verifier_methods_supported =
in discovery.
>=20
> To clarify, did you mean "code_challenge_methods_supported"?  That is, =
building on the param name "code_challenge_method" from Section 4.3 =
?
> =20
>=20
> John B.
>=20
>> On Jan 21, 2016, at 3:12 AM, William Denniss > wrote:
>>=20
>> "code_challenge_methods_supported" definitely works for me.
>>=20
>> Any objections to moving forward with that? I would like to update =
our discovery doc shortly.
>>=20
>> On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura > wrote:
>> Ah, OK. That's actually reasonable.=20
>>=20
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matake =
>:
>> I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since =
the registered parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, =
not =E2=80=9Cpkce_method".
>>=20
>>> On Jan 19, 2016, at 11:58, William Denniss > wrote:
>>>=20
>>> Seems like we agree this should be added. How should it look?
>>>=20
>>> Two ideas:
>>>=20
>>> "code_challenge_methods_supported": ["plain", "S256"]
>>>=20
>>> or
>>>=20
>>> "pkce_methods_supported": ["plain", "S256"]
>>>=20
>>>=20
>>>=20
>>> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt =
> wrote:
>>> +1
>>>=20
>>>=20
>>> Am 06.01.2016 um 18:25 schrieb William Denniss:
>>>> +1
>>>>=20
>>>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley > wrote:
>>>> Good point.  Now that PKCE is a RFC we should add it to discovery.
>>>>=20
>>>> John B.
>>>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov =
> wrote:
>>>> >
>>>> > I just noticed PKCE support is missing from the discovery =
metadata.
>>>> >
>>>> > Is it a good idea to add it?
>>>> >
>>>> > Cheers,
>>>> >
>>>> > Vladimir
>>>> >
>>>> > --
>>>> > 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
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth =

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

>>=20
>> _______________________________________________
>> 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


--Apple-Mail=_36D68B53-6F32-41F5-A56A-1E47D7082749
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Yes sorry. =
  code_challenge_method is the query parameter so code_challenge_methods_supported


On Jan 25, 2016, at 6:12 PM, William Denniss <wdenniss@google.com>=
 wrote:



On Thu, Jan 21, 2016 at 6:17 AM, =
John Bradley <ve7jtb@ve7jtb.com> wrote:
The code_challenge and code_challenge_method parameter =
names predate calling the spec PKCE.  

Given that some of us deployed early =
versions of PKCE in products and opensource to mitigate the problem =
before the spec was completed we decided not to rename the parameter =
names from code_verifier_method to pkce_verifier_method. =
 

For =
consistency we should stick with code_verifier_methods_supported in =
discovery.

To clarify, did you mean =
"code_challenge_methods_supported"?  That is, building on the param =
name "code_challenge_method" from Section 4.3?
 

John =
B.

On Jan 21, 2016, at 3:12 AM, William Denniss <wdenniss@google.com> wrote:

"code_challenge_methods_supported" =
definitely works for me.

Any objections to =
moving forward with that? I would like to update our discovery doc =
shortly.

On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura =
<sakimura@gmail.com> wrote:
Ah, OK. =
That's actually reasonable. 

2016=E5=B9=B41=E6=9C=882=
1=E6=97=A5(=E6=9C=A8) 9:31 nov matake <matake@gmail.com>:
I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, =
since the registered parameter name is =E2=80=9Ccode_challenge_method=E2=80=
=9D, not =E2=80=9Cpkce_method".

On Jan 19, 2016, at 11:58, =
William Denniss <wdenniss@google.com> wrote:

Seems like we =
agree this should be added. How should it look?

Two ideas:

"code_challenge_methods_supported": ["plain", "S256"]

or

"pkce_methods_supported": =
["plain", "S256"]



On Wed, Jan 6, 2016 at 9:59 AM, =
Torsten Lodderstedt <torsten@lodderstedt.net> wrote:

 =20
   =20
 =20
  

    +1


    

    
Am 06.01.2016 um 18:25 schrieb William
      Denniss:

    

    

      
+1

      


        
On Wed, Jan 6, 2016 at 6:40 AM, John
          Bradley <ve7jtb@ve7jtb.com>
          wrote:

          
Good
            point.  Now that PKCE is a RFC we should add it to
            discovery.

            

            John B.

            

              
> On Jan 6, 2016, at 9:29 AM, Vladimir
                Dzhuvinov <vladimir@connect2id.com>
                wrote:

                >

                > I just noticed PKCE support is missing from the
                discovery metadata.

                >

                > Is it a good idea to add it?

                >

                > Cheers,

                >

                > Vladimir

                >

                > --

                > 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

          

        

        

      

      

      

      

      
_______________________________________________
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=_36D68B53-6F32-41F5-A56A-1E47D7082749--

--Apple-Mail=_FC0CF0E8-DBC5-45BC-B8DA-022FF6F764C1
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjUyMjExMTdaMCMGCSqGSIb3DQEJBDEWBBSvlM+io863IyAu4YeIpTlY
Se/oXTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBUM4zaYkAYoTZ1w60smREPDN4VHfwUtcp7ShVS2ejFC6iwD9FpJewL
x6oCnyf+bDQsYySA4C+O6NeTlzi+VEpItGXIKTKYjivo/Jy0W3PHmeBTaFmSAlDgUzM7akfVlYRT
7Es4bcPT//XueImVDSdqSao8h9JTl6ezyH849R+9csjBmUraV86HHx6nGhJM27hLuuvzDn/mS95I
2J0OTKnyov4nlUzC9aDiVezjzWpF++uGAjVcRY3U1cwfmF6TSibwgAlXrb4bBm6OuTft0R30hoMQ
zhB1u8l6ekePZhvFDtYFo6tvgWPRw+exFRnyfWqOCYfxRg+yz37V+dTpY06NAAAAAAAA
--Apple-Mail=_FC0CF0E8-DBC5-45BC-B8DA-022FF6F764C1--


From nobody Mon Jan 25 14:29:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978D51A0033 for ; Mon, 25 Jan 2016 14:29:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id za8FZo8KesJ4 for ; Mon, 25 Jan 2016 14:29:39 -0800 (PST)
Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 6DDF11A1A75 for ; Mon, 25 Jan 2016 14:29:39 -0800 (PST)
Received: by mail-ob0-x22a.google.com with SMTP id zv1so27563157obb.2 for ; Mon, 25 Jan 2016 14:29:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=5pTuojGGz3oUxKIrwvP2sQR8QYsccvrzg0of/kmegWA=; b=jkFMvaDarc8lfEv645q3g0UzhTmaU6xJuNQWe/WBH5ujclv9ZlOr1s5is2gc6eHa5L yrFhBa/jaDPHZ1UrYHUfjB5uR9q7oJfBSS2n32wKu88DEmANH8BXEFVS+lQFt4rTTCLG gtX3ReKJlfBeoNc45WckkIuh1dCJWqaBwIYx56c7lTkyO7VfS2gXIctOOO9ZVVEAIYp1 qvDG+e2IuC+E6HCbQ0FzryB+hr30Ta2FnhZPMn/iaeT1cph3Snnl+c5r5P9pKON0qJYu O7QmsWWE1LpI7Im4hjVTjwDINb3z0Wuv0khIRwSDGR+61AJomKvop/jsLy4bJOwsy84m uvpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5pTuojGGz3oUxKIrwvP2sQR8QYsccvrzg0of/kmegWA=; b=Q1p1Ej6wROLyRNUs8qSX/hQRjDX+iNPb+uFupxCXbnR+f7Nj38QqRk1aKoUO1b81l+ 6vFLpRN2uBzxp5FmTrylJ9eLVpFtTKZRneAXXjji6MKC+ayaqtGKxkkVx3EueQKw/e7H EIeGv5448xbDt2j9RN+wYOvWK226zAj/6iOnh25GrQxNuekkKmlQfxceWFahoR3FbE5J zfEJAEnydDpuaTSgQESQUfsaqiCCe0XuYnaC68JwVVXzODUFPVwVNrD3AYoPFImIEKxG XBnpXSnIvtqjeXWmV/uRaUrR1KWncXh6/xPbuzQkQtqgz6CXdEKEFtMK2lgE87FB/9LZ Xuuw==
X-Gm-Message-State: AG10YOQfip1GVwlWA+oTU81rLzHOir5daADdmGjcCdTt1+aiQkEs7Z/h111MR8JTRZgZFp+zwQU1ccFGjl8zr09l
X-Received: by 10.182.214.40 with SMTP id nx8mr16066189obc.20.1453760978568; Mon, 25 Jan 2016 14:29:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.227.39 with HTTP; Mon, 25 Jan 2016 14:29:19 -0800 (PST)
In-Reply-To: <6F32C1CF-EA2A-4A74-A694-F52FD19DBA5C@ve7jtb.com>
References: <568D24DD.3050501@connect2id.com>   <568D5610.6000506@lodderstedt.net>     <10631235-AF1B-4122-AEAE-D56BBF38F87E@ve7jtb.com>  <6F32C1CF-EA2A-4A74-A694-F52FD19DBA5C@ve7jtb.com>
From: William Denniss 
Date: Mon, 25 Jan 2016 14:29:19 -0800
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=e89a8ff1c01eb7c98a052a301a06
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 22:29:41 -0000

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

OK great! It seems that we have consensus on this. So this is what we plan
to add to our discovery doc, based on this discussion:

"code_challenge_methods_supported": ["plain","S256"]

What are the next steps? Can we we add it to
https://tools.ietf.org/html/draft-jones-oauth-discovery directly? I see
that the IANA registry created by that draft is "Specification Required",
but PKCE is already an RFC without this param being registered.


On Mon, Jan 25, 2016 at 2:11 PM, John Bradley  wrote:

> Yes sorry.   code_challenge_method is the query parameter so
> code_challenge_methods_supported
>
>
> On Jan 25, 2016, at 6:12 PM, William Denniss  wrote:
>
>
>
> On Thu, Jan 21, 2016 at 6:17 AM, John Bradley  wrote:
>
>> The code_challenge and code_challenge_method parameter names predate
>> calling the spec PKCE.
>>
>> Given that some of us deployed early versions of PKCE in products and
>> opensource to mitigate the problem before the spec was completed we deci=
ded
>> not to rename the parameter names from code_verifier_method to
>> pkce_verifier_method.
>>
>> For consistency we should stick with code_verifier_methods_supported in
>> discovery.
>>
>
> To clarify, did you mean "code_challenge_methods_supported"?  That is,
> building on the param name "code_challenge_method" from Section 4.3
> ?
>
>
>>
>> John B.
>>
>> On Jan 21, 2016, at 3:12 AM, William Denniss  wrote=
:
>>
>> "code_challenge_methods_supported" definitely works for me.
>>
>> Any objections to moving forward with that? I would like to update our
>> discovery doc shortly.
>>
>> On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura  wrote=
:
>>
>>> Ah, OK. That's actually reasonable.
>>>
>>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matake :
>>>
>>>> I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since the=
 registered
>>>> parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, not =E2=80=
=9Cpkce_method".
>>>>
>>>> On Jan 19, 2016, at 11:58, William Denniss  wrote=
:
>>>>
>>>> Seems like we agree this should be added. How should it look?
>>>>
>>>> Two ideas:
>>>>
>>>> "code_challenge_methods_supported": ["plain", "S256"]
>>>>
>>>> or
>>>>
>>>> "pkce_methods_supported": ["plain", "S256"]
>>>>
>>>>
>>>>
>>>> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt <
>>>> torsten@lodderstedt.net> wrote:
>>>>
>>>>> +1
>>>>>
>>>>>
>>>>> Am 06.01.2016 um 18:25 schrieb William Denniss:
>>>>>
>>>>> +1
>>>>>
>>>>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley 
>>>>> wrote:
>>>>>
>>>>>> Good point.  Now that PKCE is a RFC we should add it to discovery.
>>>>>>
>>>>>> John B.
>>>>>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <
>>>>>> vladimir@connect2id.com> wrote:
>>>>>> >
>>>>>> > I just noticed PKCE support is missing from the discovery metadata=
.
>>>>>> >
>>>>>> > Is it a good idea to add it?
>>>>>> >
>>>>>> > Cheers,
>>>>>> >
>>>>>> > Vladimir
>>>>>> >
>>>>>> > --
>>>>>> > 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing listOAuth@ietf.orghttps://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
>>
>>
>>
>
>

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


OK great! It seems that we have consensus on this. So this=
 is what we plan to add to our discovery doc, based on this discussion:
"code_challenge_methods_supported": ["plain&=
quot;,"S256"]


On Mon, Jan 25, 2016 at 2:11 PM, John Bradley <ve7jtb@ve7=
jtb.com> wrote:
Yes sorry. =C2=A0=C2=A0code_challenge_method is the query=C2=A0parameter=C2=A0=
so=C2=A0code_challenge_methods_s=
upported


<=
div>
On Jan 25, 2016, at 6:12 PM, William Den=
niss <wdenniss@=
google.com> wrote:



On Thu, Jan 21, 2016 at 6:17 AM=
, John Bradley <ve7jtb@ve7jtb.com> wrote:
The code_challenge and=C2=A0code_chal=
lenge_method parameter names predate calling the spec PKCE. =C2=A0

=

Given that some of us deployed early versions of PKCE in product=
s and opensource to mitigate the problem before the spec was completed we d=
ecided not to rename the parameter names from code_verifier_method to pkce_=
verifier_method. =C2=A0

For consistency we should =
stick with code_verifier_methods_supported in discovery.

To clarify, did you mean "code_challenge_met=
hods_supported"?=C2=A0 That is, building on the param name "code_=
challenge_method" from Section 4.3?
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">

Joh=
n B.

On Jan 21,=
 2016, at 3:12 AM, William Denniss <wdenniss@google.com> wrote:

"code_challenge_methods_<=
/span>supported" definitely works for me.

Any ob=
jections to moving forward with that? I would like to update our discovery =
doc shortly.

On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura <sakimura@gma=
il.com> wrote:
Ah, OK. T=
hat's actually reasonable.=C2=A0

2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matak=
e <matake@gmail.co=
m>:
I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since =
the registered parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, n=
ot =E2=80=9Cpkce_method".

On Jan 19, 2016, at 11:58, Willia=
m Denniss <wden=
niss@google.com> wrote:

Seems like we=
 agree this should be added. How should it look?

Two ideas:

&=
quot;code_challenge_methods_supported": ["plain", "S256=
"]

or

"pkce_methods_support=
ed": ["plain", "S256"]



On Wed, Jan 6, =
2016 at 9:59 AM, Torsten Lodderstedt <torsten@lodderstedt.net>=
; wrote:

 =20
   =20
 =20
  

    +1


    

    
Am 06.01.2016 um 18:25 schrieb William
      Denniss:

    

    

      
+1

      


        
On Wed, Jan 6, 2016 at 6:40 AM, John
          Bradley <ve7jtb@ve7jtb.com>
          wrote:

          
Good
            point.=C2=A0 Now that PKCE is a RFC we should add it to
            discovery.

            

            John B.

            

              
> On Jan 6, 2016, at 9:29 AM, Vladimir
                Dzhuvinov <vladimir@connect2id.com>
                wrote:

                >

                > I just noticed PKCE support is missing from the
                discovery metadata.

                >

                > Is it a good idea to add it?

                >

                > Cheers,

                >

                > Vladimir

                >

                > --

                > Vladimir Dzhuvinov

                >

                >

              

            

            > _______________________________________________

            > OAuth mailing list

            > OAuth@=
ietf.org

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

            

            _______________________________________________

            OAuth mailing list

            OAuth@ietf.=
org

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

          

        

        

      

      

      

      

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


    

    

  





_______________________________________________
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






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






--e89a8ff1c01eb7c98a052a301a06--


From nobody Mon Jan 25 14:49:29 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E49031A1B7F for ; Mon, 25 Jan 2016 14:49:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LyB3KS9Nr9k for ; Mon, 25 Jan 2016 14:49:24 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0111.outbound.protection.outlook.com [65.55.169.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5DBE1A1B87 for ; Mon, 25 Jan 2016 14:49:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mt+qm3MLhwfrSMJG5pkywfGZIDtNgU04pgPzAndwfsU=; b=Au2M/raExirB0+lBFUMuoF1R4ua/Tz7SivkUqqAYSEuHKlVGXYBwvssXbXsWvxfgPmivvuNwsyjmilFT5ewSHdEX593VoLDYZUHsMG5M1GscCS6yq1PnWHkDLR2Xh7PxYM6mywYAZM1V0a25RQNm5KRCIWhG2XLEjJ14jCnp4T0=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB444.namprd03.prod.outlook.com (10.141.141.154) with Microsoft SMTP Server (TLS) id 15.1.365.19; Mon, 25 Jan 2016 22:49:18 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Mon, 25 Jan 2016 22:49:18 +0000
From: Mike Jones 
To: William Denniss , John Bradley 
Thread-Topic: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)
Thread-Index: AQHRSI65X4CzZd1mF0OC0DV6nH1wn57uj0gAgAAuDYCAAAmZAIATcoqAgAL7boCAAFXCgIAACbMAgACHgYCABr0aAIAAEIyAgAAFCoCAAAWVcw==
Date: Mon, 25 Jan 2016 22:49:18 +0000
Message-ID: 
References: <568D24DD.3050501@connect2id.com>   <568D5610.6000506@lodderstedt.net>     <10631235-AF1B-4122-AEAE-D56BBF38F87E@ve7jtb.com>  <6F32C1CF-EA2A-4A74-A694-F52FD19DBA5C@ve7jtb.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; 
x-originating-ip: [166.170.47.127]
x-ms-office365-filtering-correlation-id: 8a21c8af-3b58-4726-1ca6-08d325d9c22b
x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:LBVG/vCKQMxkV+zFeKqHdhT4ix+vylNG3UGE4oZHSD5aK6k2sGERI2VGb7DJ2xd7L56ljp9F5ZR/LeixsN8FUNhOxwn98GMKkRrrCm+GVL/sSzLuziaq2y/nj2g+c7dx3rXcasXc6YZKa+OohiYUkQ==; 24:yF4WisrqrYgGfcT6ph7lVLHaukc7evWMdGkmXZGBtHBZy/yQNW10IVvezZ5CxzCDNmTcnGU+IHb9nVRA/SBoPzIMPj9dnKBmqkIcBDuJDTk=
x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; UriScan:; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; 
x-forefront-prvs: 083289FD26
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(189002)(164054003)(24454002)(199003)(4326007)(10400500002)(19580405001)(122556002)(87936001)(5005710100001)(2906002)(10290500002)(8990500004)(92566002)(86362001)(40100003)(93886004)(86612001)(5004730100002)(230783001)(1220700001)(102836003)(77096005)(76576001)(1096002)(2900100001)(11100500001)(5001960100002)(15975445007)(74316001)(54356999)(3846002)(2950100001)(19617315012)(16236675004)(97736004)(3280700002)(33656002)(5001770100001)(6116002)(81156007)(19580395003)(189998001)(101416001)(99286002)(66066001)(50986999)(106356001)(105586002)(5008740100001)(106116001)(5003600100002)(586003)(76176999)(5002640100001)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444; H:BY2PR03MB442.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB44214DF2BDECA8050E819F6F5C70BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2016 22:49:18.2451 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 22:49:29 -0000

--_000_BY2PR03MB44214DF2BDECA8050E819F6F5C70BY2PR03MB442namprd_
Content-Type: text/plain; charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

I'll add it to the discovery draft in the next day or so.  Also, please see=
 my questions in the message "[OAUTH-WG] Discovery document updates planned=
". I was waiting for that feedback before doing the update.

Thanks,
-- Mike
________________________________
From: William Denniss
Sent: =FD1/=FD25/=FD2016 2:29 PM
To: John Bradley
Cc: Nat Sakimura; oauth@ietf.org; Mike Jones
Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draf=
t-jones-oauth-discovery-00)

OK great! It seems that we have consensus on this. So this is what we plan =
to add to our discovery doc, based on this discussion:

"code_challenge_methods_supported": ["plain","S256"]

What are the next steps? Can we we add it to https://tools.ietf.org/html/dr=
aft-jones-oauth-discovery directly? I see that the IANA registry created by=
 that draft is "Specification Required", but PKCE is already an RFC without=
 this param being registered.


On Mon, Jan 25, 2016 at 2:11 PM, John Bradley > wrote:
Yes sorry.   code_challenge_method is the query parameter so code_challenge=
_methods_supported


On Jan 25, 2016, at 6:12 PM, William Denniss > wrote:



On Thu, Jan 21, 2016 at 6:17 AM, John Bradley > wrote:
The code_challenge and code_challenge_method parameter names predate callin=
g the spec PKCE.

Given that some of us deployed early versions of PKCE in products and opens=
ource to mitigate the problem before the spec was completed we decided not =
to rename the parameter names from code_verifier_method to pkce_verifier_me=
thod.

For consistency we should stick with code_verifier_methods_supported in dis=
covery.

To clarify, did you mean "code_challenge_methods_supported"?  That is, buil=
ding on the param name "code_challenge_method" from Section 4.3?


John B.

On Jan 21, 2016, at 3:12 AM, William Denniss > wrote:

"code_challenge_methods_supported" definitely works for me.

Any objections to moving forward with that? I would like to update our disc=
overy doc shortly.

On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura > wrote:
Ah, OK. That's actually reasonable.

2016?1?21?(?) 9:31 nov matake >:
I prefer =93code_challenge_methods_supported=94, since the registered param=
eter name is =93code_challenge_method=94, not =93pkce_method".

On Jan 19, 2016, at 11:58, William Denniss > wrote:

Seems like we agree this should be added. How should it look?

Two ideas:

"code_challenge_methods_supported": ["plain", "S256"]

or

"pkce_methods_supported": ["plain", "S256"]



On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt > wrote:
+1


Am 06.01.2016 um 18:25 schrieb William Denniss:
+1

On Wed, Jan 6, 2016 at 6:40 AM, John Bradley > wrote:
Good point.  Now that PKCE is a RFC we should add it to discovery.

John B.
> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov > wrote:
>
> I just noticed PKCE support is missing from the discovery metadata.
>
> Is it a good idea to add it?
>
> Cheers,
>
> Vladimir
>
> --
> 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




_______________________________________________
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





--_000_BY2PR03MB44214DF2BDECA8050E819F6F5C70BY2PR03MB442namprd_
Content-Type: text/html; charset="windows-1256"
Content-Transfer-Encoding: quoted-printable










I'll add it t=
o the discovery draft in the next day or so.  Also, please see my ques=
tions in the message "[OAUTH-WG] Discovery document updates planned&qu=
ot;. I was waiting for that feedback before doing
 the update.



Thanks,

-- Mike







From:
William Denniss

Sent:
=FD1/=
=FD25/=FD2016 2:29 PM

To:
John Bradley

Cc:
Nat Sakimura;
oauth@ietf.org; 
Mike Jones

Subject:
Re: [=
OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-=
discovery-00)








OK great! It seems that we have consensus on this. So this=
 is what we plan to add to our discovery doc, based on this discussion:






"code_challenge_methods_supported": ["plain","=
;S256"]







What are the next steps? Can we we add it to https://tools.ietf.org/html=
/draft-jones-oauth-discovery directly? I see that the IANA
 registry created by that draft is "Specification Required", but PKCE is a=
lready an RFC without this param being registered.
















On Mon, Jan 25, 2016 at 2:11 PM, John Bradley 
<ve7jtb@ve7jtb.co=
m> wrote:






Yes sorry.   code_challe=
nge_method is the query parameter=
 so code_challenge_methods_supported




















On Jan 25, 2016, at 6:12 PM, William Denniss <wdenniss@google.com> wrote:











On Thu, Jan 21, 2016 at 6:17 AM, John Bradley 
<ve7jtb@ve7jtb.co=
m> wrote:




The code_challenge and code_challe=
nge_method parameter names predate calling the spec PKCE.  






Given that some of us deployed early versions of PKCE in products and =
opensource to mitigate the problem before the spec was completed we decided=
 not to rename the parameter names from code_verifier_method to pkce_verifi=
er_method.  







For consistency we should stick with code_verifier_methods_supported i=
n discovery.











To clarify, did you mean "code_challenge_methods_supported"?=
  That is, building on the param name "code_challenge_method"=
; from
Section 4.3?


 













John B.













On Jan 21, 2016, at 3:12 AM, William Denniss <wdenniss@google.com> wrote:





"code_challenge_meth=
ods_supported" definitely works for me.






Any objections to moving forward with=
 that? I would like to update our discovery doc shortly.







On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura 
<sakimura@gmail.=
com> wrote:




Ah, OK. That's actually reasonable. 






2016年1月21日(木) 9:31 nov matake =
<matake@gmail.com<=
/a>>:










I prefer =93code_challenge_methods_supp=
orted=94, since the registered parameter name is =93code_challenge_method=
=94, not =93pkce_method".
















Seems like we agree this should be added. How should it lo=
ok?



Two ideas:



"code_challenge_methods_supported": ["plain", "S25=
6"]






or





"pkce_methods_supported": ["plain", "S256&quo=
t;]















On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderst=
edt 
<torsten@lo=
dderstedt.net> wrote:




+1








Am 06.01.2016 um 18:25 schrieb William Denniss:






+1





On Wed, Jan 6, 2016 at 6:40 AM, John Bradley 
<ve7jtb@ve7jtb.co=
m> wrote:



Good point.  Now that PKCE is a RFC we should add it to discovery.



John B.




> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <vladimir@connect2id.com&=
gt; wrote:

>

> I just noticed PKCE support is missing from the discovery metadata.
>

> Is it a good idea to add it?

>

> Cheers,

>

> Vladimir

>

> --

> 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












 


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




















_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth













_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

















_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth






















































--_000_BY2PR03MB44214DF2BDECA8050E819F6F5C70BY2PR03MB442namprd_--


From nobody Mon Jan 25 14:58:58 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98081A1BB9 for ; Mon, 25 Jan 2016 14:58:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZ4J3JzSdVns for ; Mon, 25 Jan 2016 14:58:55 -0800 (PST)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8C141A1BA9 for ; Mon, 25 Jan 2016 14:58:54 -0800 (PST)
Received: by mail-qg0-x231.google.com with SMTP id e32so122124470qgf.3 for ; Mon, 25 Jan 2016 14:58:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=idEewZHzD0Rh2UC8AMBhSxnux+KCd2u22mOXSUxULug=; b=RHjGroou6UhWzzPv29D2aVotPxn+pmHgagBbQM6PxEyeJDoRkQc/PrejzSisH82iiJ KQGVrzeoN8gpKSmIQkJxxRIn5NDXPcgQEjyPReNt0/INkKP+HR4tCbGTNTp9aKT+0Xz0 wXrFvpXJK2gs14idHAoOP7rpovseN3+wHcgQMcGyMdz+zhKAvTpXnI/NrMOzM94Ylmnb l2VfN4g/yUe5Nwx8gxOcd+JtChaSQuOpckfigTilLmnQLHJCVLUrgrlidhtUnIOn+dE5 GZ1ic3L1E4+yRGWHPV5x48WcAdSGiUIgIevDqn9SNo4m5BsaqpSl7L54ubU2OgkwKMuz 7F/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=idEewZHzD0Rh2UC8AMBhSxnux+KCd2u22mOXSUxULug=; b=O3xwx5awNniLFJ46p7VGOYmJXNCyzu9FJmJChClfqg0jVHAaJzJxLtyXqT0/ETNJZq qNX+eMBOfLIy5Ou/Pq9ilPc9aKGcLpGc6TKRNTuOjI65QSmUZQh/qeMgY5vsjvKNGSbP PP/Sp+xNBXxFtCs3qfBUO+jvKtSucgT3fQvhiJcAC/rCN+sz4R09fQq+rTIGcZqJLEAf FUmyb9qO+cN7yTGdS7hXA0l/igK4zNH+Y9xfLJa+wik+Bz9qo8Z0chJnoDvACubZk3AE c5YRi41TzyfjksTXs06+Q4oa7uMwYm/PAuf1FiPWT4bEcPYB7wSPoDqPWqFyMYyIMVeV Ad3A==
X-Gm-Message-State: AG10YOTU+hgp/Gwl3s84+T7t2HDb6Ib/Apovx0CD7ozU2EH9CI0Gojd3r/5YjHp6nB+vP1uEwDADsULzHNjs8Q==
X-Received: by 10.140.18.136 with SMTP id 8mr24304109qgf.64.1453762734171; Mon, 25 Jan 2016 14:58:54 -0800 (PST)
MIME-Version: 1.0
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <995474C5-62E7-4310-84AF-A5EF1CDEA4DB@ve7jtb.com> <56A63F82.40104@aol.com> <6D8FA56F-EA72-4509-90C1-DC33094FA695@ve7jtb.com> <56A66522.1090804@aol.com> <23E34900-5C05-4295-AFC5-7DEBA6449AA7@ve7jtb.com> <56A66BED.3090505@aol.com> <8EBCD2DD-D9D8-4AFD-A12F-A8C5C9DC4C06@oracle.com>
In-Reply-To: <8EBCD2DD-D9D8-4AFD-A12F-A8C5C9DC4C06@oracle.com>
From: Nat Sakimura 
Date: Mon, 25 Jan 2016 22:58:44 +0000
Message-ID: 
To: "Phil Hunt (IDM)" , George Fletcher 
Content-Type: multipart/alternative; boundary=001a113546425bb579052a308309
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 22:58:56 -0000

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

Hi Phil,

Since I was not in Darmstadt, I really do not know what was discussed
there, but with the compromised developer documentation described in
http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/, all
RFC6749 clients with a naive implementer will be affected. The client does
not need to be talking to multiple IdPs.

Nat

2016=E5=B9=B41=E6=9C=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) :

> I recall making this point in Germany. 99% of existing use is fine. OIDC
> is probably the largest community that *might* have an issue.
>
> I recall proposing a new security document that covers oauth security for
> dynamic scenarios. "Dynamic" being broadly defined to mean:
> * clients who have configured at runtime or install time (including
> clients that do discovery)
> * clients that communicate with more than one endpoint
> * clients that are deployed in large volume and may update frequently
> (more discussion of "public" cases)
> * clients that are script based (loaded into browser on the fly)
> * others?
>
> Phil
>
> > On Jan 25, 2016, at 10:39, George Fletcher  wrote:
> >
> > would
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Hi Phil,=C2=A0

Since I was not in Darms=
tadt, I really do not know what was discussed there, but with the compromis=
ed developer documentation described in=C2=A0http://nat.sakimura.or=
g/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/, all RFC6749 clients w=
ith a naive implementer will be affected. The client does not need to be ta=
lking to multiple IdPs.=C2=A0

Nat
=


2016=E5=B9=B41=E6=9C=
=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) <phil.hunt@oracle.com>:
I recall making this point in Germany. 99% of existing use is fi=
ne. OIDC is probably the largest community that *might* have an issue.



I recall proposing a new security document that covers oauth security for d=
ynamic scenarios. "Dynamic" being broadly defined to mean:

* clients who have configured at runtime or install time (including clients=
 that do discovery)

* clients that communicate with more than one endpoint

* clients that are deployed in large volume and may update frequently (more=
 discussion of "public" cases)

* clients that are script based (loaded into browser on the fly)

* others?



Phil



> On Jan 25, 2016, at 10:39, George Fletcher <gffletch@aol.com> wrote:

>

> would



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--001a113546425bb579052a308309--


From nobody Mon Jan 25 15:22:56 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25B91A1EEA for ; Mon, 25 Jan 2016 15:22:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZaCw5oqnpUC for ; Mon, 25 Jan 2016 15:22:52 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62531A1B30 for ; Mon, 25 Jan 2016 15:22:52 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0PNMpW9004565 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 25 Jan 2016 23:22:51 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u0PNMpJa027825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 25 Jan 2016 23:22:51 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u0PNMo9X026275 for ; Mon, 25 Jan 2016 23:22:51 GMT
Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Jan 2016 15:22:50 -0800
From: Phil Hunt 
Content-Type: multipart/alternative; boundary="Apple-Mail=_C537EB57-D4D1-43D6-AB73-33EF2A9A242D"
Date: Mon, 25 Jan 2016 15:22:48 -0800
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com>
To: "oauth@ietf.org WG" 
Message-Id: <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com>
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 23:22:54 -0000

--Apple-Mail=_C537EB57-D4D1-43D6-AB73-33EF2A9A242D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Sorry, meant to reply-all.

Phil

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






> Begin forwarded message:
>=20
> From: Phil Hunt 
> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
> Date: January 25, 2016 at 3:20:19 PM PST
> To: Nat Sakimura 
>=20
> I am having trouble with the very first assumption. The user-agent =
sets up a non TLS protected connection to the RP? That=E2=80=99s a =
fundamental violation of 6749.
>=20
> Also, the second statement says the RP (assuming it acts as OAuth =
client) is talking to two IDPs.  That=E2=80=99s still a multi-AS case is =
it not?
>=20
> Phil
>=20
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>=20
>=20
>=20
>=20
>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura > wrote:
>>=20
>> Hi Phil,=20
>>=20
>> Since I was not in Darmstadt, I really do not know what was discussed =
there, but with the compromised developer documentation described in =
http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/ =
, =
all RFC6749 clients with a naive implementer will be affected. The =
client does not need to be talking to multiple IdPs.=20
>>=20
>> Nat
>>=20
>> 2016=E5=B9=B41=E6=9C=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) =
>:
>> I recall making this point in Germany. 99% of existing use is fine. =
OIDC is probably the largest community that *might* have an issue.
>>=20
>> I recall proposing a new security document that covers oauth security =
for dynamic scenarios. "Dynamic" being broadly defined to mean:
>> * clients who have configured at runtime or install time (including =
clients that do discovery)
>> * clients that communicate with more than one endpoint
>> * clients that are deployed in large volume and may update frequently =
(more discussion of "public" cases)
>> * clients that are script based (loaded into browser on the fly)
>> * others?
>>=20
>> Phil
>>=20
>> > On Jan 25, 2016, at 10:39, George Fletcher > wrote:
>> >
>> > would
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth =

>=20


--Apple-Mail=_C537EB57-D4D1-43D6-AB73-33EF2A9A242D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Sorry, meant to reply-all.









Begin forwarded message:

From: =
Phil Hunt <phil.hunt@oracle.com>
Subject: =
Re: [OAUTH-WG] =
Call for Adoption: OAuth 2.0 Mix-Up Mitigation
Date: =
January 25, 2016 at 3:20:19 PM =
PST
To: =
Nat Sakimura <sakimura@gmail.com>

I am having trouble with the very first =
assumption. The user-agent sets up a non TLS protected connection to the =
RP? That=E2=80=99s a fundamental violation of 6749.

Also, the second statement says the RP =
(assuming it acts as OAuth client) is talking to two IDPs. =
 That=E2=80=99s still a multi-AS case is it not?










On Jan 25, 2016, at 2:58 PM, Nat Sakimura <sakimura@gmail.com> =
wrote:

Hi Phil, 

Since I was not in Darmstadt, I really =
do not know what was discussed there, but with the compromised developer =
documentation described in http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-r=
fc6749/, all RFC6749 clients with a naive implementer will be =
affected. The client does not need to be talking to multiple =
IdPs. 

Nat

2016=E5=B9=B41=E6=9C=882=
6=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) <phil.hunt@oracle.com>:
I recall making this point in Germany. 99% of =
existing use is fine. OIDC is probably the largest community that =
*might* have an issue.



I recall proposing a new security document that covers oauth security =
for dynamic scenarios. "Dynamic" being broadly defined to mean:

* clients who have configured at runtime or install time (including =
clients that do discovery)

* clients that communicate with more than one endpoint

* clients that are deployed in large volume and may update frequently =
(more discussion of "public" cases)

* clients that are script based (loaded into browser on the fly)

* others?



Phil



> On Jan 25, 2016, at 10:39, George Fletcher <gffletch@aol.com> wrote:

>

> would



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






=

--Apple-Mail=_C537EB57-D4D1-43D6-AB73-33EF2A9A242D--


From nobody Mon Jan 25 15:24:57 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F49B1A1EEC for ; Mon, 25 Jan 2016 15:24:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdct5P5gYDKl for ; Mon, 25 Jan 2016 15:24:55 -0800 (PST)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003: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 1DC851A1EEA for ; Mon, 25 Jan 2016 15:24:55 -0800 (PST)
Received: by mail-oi0-x235.google.com with SMTP id o124so97916054oia.3 for ; Mon, 25 Jan 2016 15:24:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=41ZQDoBXrmL08xaa+1j/ttSjlCOsywGg45OKUuPl2Bc=; b=jVb4HZYiXXiAaLThCR34lwdG0bj0z1SySrWkaW+EPpYpzuHcgjcYiHsUNA8aNlQE1o xf3UtE6JCsyrZ0MWCTy1R0ZXjHFVYmKxcCYx9CTP0/QcdgIZMntZWHrNXCdOEUkZsVao hkXZEx+YkCSKFx7bB0hZCgvzlaEmgQmJ6kwxmGh0HHqMLZy+xpzgUmmamrh43thzReIc G09ODwI9BJl9eZ0igh7fIhlTQtuF2lejineYaz1HFzWH/l9IDpsFQPfvpv6DlG6XelyX tX6msz30KOvMnIHm95QsA+WcuXPuC9tw8vGJaPflOjfQHC/akbGZk7lXj9odUYn1SEjQ O9TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=41ZQDoBXrmL08xaa+1j/ttSjlCOsywGg45OKUuPl2Bc=; b=BQlbBKigh12vNTVf/kZ+AoHYNIlXlZN6oco3xAHvR1NpMkHIOVLB//OV7CKOJJnJSz CFSrIXc+oPhI/1cavFxLB7V438pJy1iY3bg/hG/umkStUXWtgQzzSgd3Dd13zWliJJaU LlXVnz/PlHZv9lH7vtURjHbBzLRyve+F1cm6hI7SfsVt6UNTY37qGWszpF7zRUfkqBMp IuVjEtO9fSZPKWkn8KHu0Dnv8++9ny6vrLzoqpbZ1S0n60eGNEJTka1fXZJd3dMWpfLj YtNMlQgVyXuiI0++7DGcRNKhwFLNxekbeGOaOQKNvOn+++NlrqPh6jbzn53pXiGMThEE vJiw==
X-Gm-Message-State: AG10YOQH6r27/TfEzH3xG7pjd0plO4IqKdqav3n0cbW3YP6mz5fb/gWLGqXzxP1s4Bo8P1DH4uVm4ztJ9RQAoEPj
X-Received: by 10.202.75.10 with SMTP id y10mr3751334oia.13.1453764294447; Mon, 25 Jan 2016 15:24:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.227.39 with HTTP; Mon, 25 Jan 2016 15:24:34 -0800 (PST)
In-Reply-To: 
References: 
From: William Denniss 
Date: Mon, 25 Jan 2016 15:24:34 -0800
Message-ID: 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=001a11c17d7e5bd8b6052a30e03d
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Discovery document updates planned
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 23:24:56 -0000

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

On Thu, Jan 21, 2016 at 10:37 PM, Mike Jones 
wrote:

> Tomorrow I plan to apply updates to the OAuth Discovery document that hav=
e
> been requested since the -00 version was published.  Updates on my list t=
o
> make are:
>
> =C2=B7       Adding an equivalent of token_endpoint_auth_methods_supporte=
d for
> the revocation endpoint
>
i.e. revocation_endpoint_auth_methods_supported ?

=C2=B7       Adding an equivalent of token_endpoint_auth_methods_supported =
for
> the introspection endpoint
>
i.e.  introspection_endpoint_auth_methods_supported ?


> =C2=B7       Adding code_challenge_methods_supported
>
> LGTM.


>
>
> Did I miss capturing any metadata values that it makes sense to add at
> this point?
>
>
>
>                                                           Thanks all,
>
>                                                           -- Mike
>

Looks good to me.


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

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



On Thu, Jan 21, 2016 at 10:37 PM, Mike Jones &=
lt;Michael=
.Jones@microsoft.com> wrote:











Tomorrow I plan to apply updates to the OAuth Discov=
ery document that have been requested since the -00 version was published.=
=C2=A0 Updates on my list to make are:


=C2=B7=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Adding an equivalent of 
token_endpoint_auth_methods_supported for the revocation endpoint
i.e.=C2=A0revocation_endpoint_auth_methods_supported ?

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
Adding an equivalent of 
token_endpoint_auth_methods_supported for the introspection endpoint=

i.e. =C2=A0introspection_endpoint_auth_meth=
ods_supported ?
=C2=A0


=C2=B7=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Adding 
code_challenge_methods_supported


LGTM.
=

=C2=A0
=C2=A0


Did I miss capturing any metadata values that it mak=
es sense to add at this point?


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks a=
ll,


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

Looks good to me.
=C2=A0







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a11c17d7e5bd8b6052a30e03d--


From nobody Mon Jan 25 15:53:42 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56341A88BC for ; Mon, 25 Jan 2016 15:53:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drSzHu2BxqsG for ; Mon, 25 Jan 2016 15:53:38 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id C8A051A8833 for ; Mon, 25 Jan 2016 15:53:37 -0800 (PST)
X-AuditID: 12074422-f79c46d000006aa7-28-56a6b580f45b
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 40.0A.27303.085B6A65; Mon, 25 Jan 2016 18:53:36 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u0PNrZPd015224; Mon, 25 Jan 2016 18:53:36 -0500
Received: from [192.168.128.48] (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 u0PNrX5S022964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Jan 2016 18:53:34 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_3E91D8C8-4A06-4581-9925-6B6020F87B8E"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: <56A66BED.3090505@aol.com>
Date: Mon, 25 Jan 2016 18:53:33 -0500
Message-Id: <522B7197-F14F-44AD-9217-63480CA558F2@mit.edu>
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <995474C5-62E7-4310-84AF-A5EF1CDEA4DB@ve7jtb.com> <56A63F82.40104@aol.com> <6D8FA56F-EA72-4509-90C1-DC33094FA695@ve7jtb.com> <56A66522.1090804@aol.com> <23E34900-5C05-4295-AFC5-7DEBA6449AA7@ve7jtb.com> <56A66BED.3090505@aol.com>
To: George Fletcher 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHKsWRmVeSWpSXmKPExsUixG6nrtuwdVmYwZ4TOhZ3ulawW5x8+4rN YvXdv2wOzB73d69k91iy5CeTx+3bG1kCmKO4bFJSczLLUov07RK4MpYsbmAt2PKBsaLx2jrm BsaeFYxdjJwcEgImEqf+zoWyxSQu3FvP1sXIxSEksJhJ4uLF70wQzkZGiXf737FDOLeZJGav PgXUwsHBLJAg0Xw6GKSbV0BP4tWty6wgtrCAm8TKA5fZQGw2AVWJ6WtamEBsTgF1idP7n4LF WYDi328vYwaxmQU8JfY8u8AIMcdKYsKf01BXXGSRmP5gH1iRiICaRNPKNVCnykrs/v2IaQKj wCyEM2YhOWMW2FhtiWULXzND2AYSTztfYRHXl3jzbg7TAka2VYyyKblVurmJmTnFqcm6xcmJ eXmpRbqmermZJXqpKaWbGMGR4KK0g/HnQaVDjAIcjEo8vBsKloUJsSaWFVfmHmKU5GBSEuVN WAwU4kvKT6nMSCzOiC8qzUktPsQowcGsJMKbsAEox5uSWFmVWpQPk5LmYFES593VMTdMSCA9 sSQ1OzW1ILUIJivDwaEkwRu5BahRsCg1PbUiLTOnBCHNxMEJMpwHaHgISA1vcUFibnFmOkT+ FKMxx751d9Yycbya93AtkxBLXn5eqpQ47waQUgGQ0ozSPLhpoGSW8Paw6StGcaDnhHkDQKp4 gIkQbt4roFVMQKv+ai4GWVWSiJCSamDUb00MXMBSEbmrUyaEY9F9IYHkVVurjz84mf3rd++j Z6m3TWeLixTtsYnwKat8c4/vs+qitP7TuofnuaiELX3h/FGA7eLEw9E2stk256adSuVcdM7B 7Ji44NnrbKm8f9crFak6Ll102DPsv8W0v3Ubkhv03sp43L2Y5Ti9MIFjApdZN8dBzw1KLMUZ iYZazEXFiQCCzeKyQQMAAA==
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 25 Jan 2016 23:53:41 -0000

--Apple-Mail=_3E91D8C8-4A06-4581-9925-6B6020F87B8E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

+1

> On Jan 25, 2016, at 1:39 PM, George Fletcher  wrote:
>=20
> So now, in addition to the dynamic client registration spec, the =
client would need to support OAuth2 Discovery.
>=20
> I guess my concern is that it feels like we are adding a lot of little =
things to try and mitigate these attacks in OAuth2 and it's confusing =
when they are needed and when they aren't.
>=20
> For me it would be simpler to say that OAuth2 with a single =
pre-configured AS is fine. If a client wants to support multiple =
Authorization Servers (a la dynamic client registration or some other =
method) then here are all the things that need to be done. Maybe this =
would be simpler as a profile of OAuth2 (in the vein of OpenID Connect) =
that adds the necessary requirements to mitigate these attacks.
>=20
> This way an OAuth2 developer knows which spec to follow based on their =
requirements and all the necessary steps would be in "one" place.
>=20
> Thanks,
> George
>=20
> On 1/25/16 1:22 PM, John Bradley wrote:
>> The presumption is that registration would need to add a issuer, as =
an identifier of the AS, and that would be optionally be used in =
discovery.
>>=20
>> OAuth as is supports the single AS model.
>>=20
>> To support multiple AS for a single client something needs to change. =
   Adding issuer and client_id to the response with optional discovery =
was seen as the least disruptive at the Germany meeting.
>>=20
>>  The other way to do it is to return discovery info from the the =
authorization and token endpoints, however the request probably also =
need to be modified so that the AS knows what the resource is, otherwise=20=

>> other things will break.   =20
>>=20
>> It is possible now to have one authorization endpoint provide code =
for per Tennent token endpoints.(No I don=92t know of any one doing it).
>>=20
>> Anything we add to tighten up the trust model will have impacts on =
what can be done with OAuth. =20
>>=20
>> John B.
>>> On Jan 25, 2016, at 3:10 PM, George Fletcher > wrote:
>>>=20
>>> Comments inline
>>>=20
>>> On 1/25/16 12:32 PM, John Bradley wrote:
>>>> No, client id_are scoped by issuer. =20
>>> This makes sense, but I'm not sure it's a current assumption by =
OAuth2 implementations :)
>>>>=20
>>>> There is no need for AS to make the client_id globally unique.
>>>>=20
>>>>  The client needs to not allow two AS to provide it with the same =
issuer client_id pair.
>>>>=20
>>>> That would probably be imposable for many clients anyway.=20
>>> I would rather say that the results of two client_ids being the same =
from two different issuers is undefined.
>>>>=20
>>>> For Connect clients typically manage configurations using issuer as =
the primary key.  I doubt may would support even two client_id from the =
same issuer.
>>> If scoped by issuer this makes sense, though the concept of "issuer" =
as a comparable entity wasn't really talked about with OAuth2.
>>>>=20
>>>> For OAuth what clients do is slightly less clear.  In general they =
don=92t have more than one AS per API do might try and organize things =
by RS or AS.
>>> I agree that not many clients support dynamic client registration. =
However, I would say there a number that support multiple AS that are =
"fixed" within the code (including fixed endpoint URIs). So I would say =
that the associations would be fixed in code. There wouldn't necessarily =
be an association outside of the code which maps button A to AS1 and =
button B to AS2.
>>>>=20
>>>> In principal a OAuth client might have two different AS each with a =
different client ID and that will be OK as long as the client_id in the =
request is the same as the one in the response.
>>>>=20
>>>> So going to a new AS and getting back the same iss and client_id =
that you registered someplace else would be an error for the client.
>>>>=20
>>>> I don=92t think that is unreasonable.
>>> I agree that this is reasonable with the assumption that client_id's =
are scoped by "issuer". It's just likely that most clients in the field =
do not have this sort of explicit association. The OAuth2 Dynamic Client =
Registration spec does not define an "issuer" in the response. For the =
OAuth2 use cases, what is the proposed "issuer" equivalent URI that is =
being used to scope the client_id?=20
>>>>=20
>>>> John B.
>>>>=20
>>>>=20
>>>>> On Jan 25, 2016, at 12:30 PM, George Fletcher > wrote:
>>>>>=20
>>>>> I'm still catching up... but to this point specifically...
>>>>>=20
>>>>> Doesn't this require that the same client_id NOT be used =
simultaneously at two (or more) Authorization Servers? If so, I don't =
believe that is a viable option. It's a little late in the game to be =
putting requirements on the AS as to how it generates it's client_id.
>>>>>=20
>>>>> Thanks,
>>>>> George
>>>>>=20
>>>>> On 1/25/16 9:11 AM, John Bradley wrote:
>>>>>>=20
>>>>>> Returning the iss and client_id from the authorization endpoint =
per Mike=92s draft allows the client to reject the authorization =
response and not leak the code.
>>>>>=20
>>>>=20
>>>=20
>>> --=20
>>> Chief Architect                  =20
>>> Identity Services Engineering     Work: george.fletcher@teamaol.com =

>>> AOL Inc.                          AIM:  gffletch
>>> Mobile: +1-703-462-3494           Twitter: =
http://twitter.com/gffletch 
>>> Office: +1-703-265-2544           Photos: =
http://georgefletcher.photography 
>>=20
>=20
> --=20
> Chief Architect                  =20
> Identity Services Engineering     Work: george.fletcher@teamaol.com =

> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch =

> Office: +1-703-265-2544           Photos: =
http://georgefletcher.photography 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_3E91D8C8-4A06-4581-9925-6B6020F87B8E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

+1

On Jan 25, 2016, at 1:39 PM, =
George Fletcher <gffletch@aol.com> wrote:



 =20
  

    So now, in =
addition to the
      dynamic client registration spec, the client would need to support
      OAuth2 Discovery.

      

      I guess my concern is that it feels like we are adding a lot of
      little things to try and mitigate these attacks in OAuth2 and it's
      confusing when they are needed and when they aren't.

      

      For me it would be simpler to say that OAuth2 with a single
      pre-configured AS is fine. If a client wants to support multiple
      Authorization Servers (a la dynamic client registration or some
      other method) then here are all the things that need to be done.
      Maybe this would be simpler as a profile of OAuth2 (in the vein of
      OpenID Connect) that adds the necessary requirements to mitigate
      these attacks.

      

      This way an OAuth2 developer knows which spec to follow based on
      their requirements and all the necessary steps would be in "one"
      place.

      

      Thanks,

      George

    

    
On 1/25/16 1:22 PM, John Bradley =
wrote:

    

    

     =20
      The presumption is that registration would need to add a issuer,
      as an identifier of the AS, and that would be optionally be used
      in discovery.
      


      

      
OAuth as is supports the single AS model.

      


      

      
To support multiple AS for a single client =
something
        needs to change.    Adding issuer and client_id to the =
response
        with optional discovery was seen as the least disruptive at the
        Germany meeting.

      


      

      
 The other way to do it is to return =
discovery info
        from the the authorization and token endpoints, however the
        request probably also need to be modified so that the AS knows
        what the resource is, otherwise 

      
other things will break.    

      


      

      
It is possible now to have one authorization
        endpoint provide code for per Tennent token endpoints.(No I
        don=92t know of any one doing it).

      


      

      
Anything we add to tighten up the trust model will
        have impacts on what can be done with OAuth.  

      


      

      
John B.

      

        

          

            
On Jan 25, 2016, at 3:10 PM, George Fletcher
              <gffletch@aol.com>
              wrote:

            

            
Comments =
inline

              

              
On 1/25/16 12:32 PM, John Bradley
                wrote:

              

              
No,
                client id_are scoped by issuer.  

              

              This makes sense, but I'm not =
sure
                it's a current assumption by OAuth2 implementations =
:)

              

                


                

                
There is no need for AS to make the
                  client_id globally unique.

                


                

                
 The client needs to not allow two =
AS to
                  provide it with the same issuer client_id pair.

                  


                  

                  
That would probably be imposable for
                    many clients anyway. 

                  

                

              

              I would rather say that the
                results of two client_ids being the same from two
                different issuers is undefined.

              

                

                  


                  

                  
For Connect clients typically manage
                    configurations using issuer as the primary key. =
 I
                    doubt may would support even two client_id from the
                    same issuer.

                

              

              If scoped by issuer this makes
                sense, though the concept of "issuer" as a comparable
                entity wasn't really talked about with OAuth2.

              

                

                  


                  

                  
For OAuth what clients do is slightly
                    less clear.  In general they don=92t have more =
than
                    one AS per API do might try and organize things by
                    RS or AS.

                

              

              I agree that not many clients
                support dynamic client registration. However, I would
                say there a number that support multiple AS that are
                "fixed" within the code (including fixed endpoint URIs).
                So I would say that the associations would be fixed in
                code. There wouldn't necessarily be an association
                outside of the code which maps button A to AS1 and
                button B to AS2.

              

                

                  


                  

                  
In principal a OAuth client might have
                    two different AS each with a different client ID and
                    that will be OK as long as the client_id in the
                    request is the same as the one in the =
response.

                  


                  

                  
So going to a new AS and getting back
                    the same iss and client_id that you registered
                    someplace else would be an error for the =
client.

                  


                  

                  
I don=92t think that is =
unreasonable.

                

              

              I agree that this is reasonable
                with the assumption that client_id's are scoped by
                "issuer". It's just likely that most clients in the
                field do not have this sort of explicit association. The
                OAuth2 Dynamic Client Registration spec does not define
                an "issuer" in the response. For the OAuth2 use cases,
                what is the proposed "issuer" equivalent URI that is
                being used to scope the client_id? 

              

                

                  


                  

                  
John B.

                  


                  

                  


                    

                      

                        
On Jan 25, 2016, at 12:30 PM,
                          George Fletcher <gffletch@aol.com>
                          wrote:

                        

                        

                          
I'm still catching up... but
                              to this point specifically...
=

                              

                              Doesn't this require that the same
                              client_id NOT be used simultaneously at
                              two (or more) Authorization Servers? If
                              so, I don't believe that is a viable
                              option. It's a little late in the game to
                              be putting requirements on the AS as to
                              how it generates it's client_id.

                              

                              Thanks,

                              George

                            

                            
On 1/25/16 =
9:11
                              AM, John Bradley wrote:

                            

                            

                              


                              

                              
Returning the iss and
                                client_id from the authorization
                                endpoint per Mike=92s draft allows the
                                client to reject the authorization
                                response and not leak the code.

                            

                            

                          

                        

                      

                    

                    

                  

                

              

              

              
--=20
Chief Architect                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photogra=
phy


            

          

        

        

      

    

    

    
--=20
Chief Architect                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photogra=
phy


  


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

=

--Apple-Mail=_3E91D8C8-4A06-4581-9925-6B6020F87B8E--


From nobody Mon Jan 25 16:09:00 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FF71A895C for ; Mon, 25 Jan 2016 16:08:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UweQ4jblPzpo for ; Mon, 25 Jan 2016 16:08:57 -0800 (PST)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::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 335311A8958 for ; Mon, 25 Jan 2016 16:08:56 -0800 (PST)
Received: by mail-ob0-x231.google.com with SMTP id zv1so29391772obb.2 for ; Mon, 25 Jan 2016 16:08:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Wa4qvacl2X4Z4OVQMgmSMjeQzvMw8n3qpFw7AtEpSVg=; b=jHTIIEuBEvYJFabyg59Lnw2AR+8gu8xRuqSRkbJP4OhyzjWfjNHCoTyNfjtjFDzemZ W0Q8hdQiDKFDJW2Me+opuvU/8d2KmBBv9gjZRdY3PhLF/zeoJUgx3Fp0fwIMv+nPY88Q 5xDxDyHUFmR8LF341wd2k2q69KG/mkFZndLlFUq0z6BnQCEKEl8ornaf+kz8qCagajLa STbNktBNNyNrOtfxTpM+NwQOX5f/M9lHVs5wafCdz1NjFJiNAkt1lcphihCRDYaBlL+l JPyX0UlAPLkFqNHdRXCLNc19gChc9m3el7DJfznFD/wdhGRvbAr5B2Rv2kw2gu1FZ3xq /3dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Wa4qvacl2X4Z4OVQMgmSMjeQzvMw8n3qpFw7AtEpSVg=; b=iC2tga3I4IRQE1k27NNewOfYOmqFZvrRa8k6YexN+43ZlP2Fa5F0f6/PdseW11G4Ua LUEC8UKy96Z+oC8QB8DdqToDRSL7JcBwrGH5u7Sm7BYTV8ANTwosnsLRV/vR9+GNWHFv zy40Lhz750iSTzGJvfvWwgBASh9UjagSd0Zk17dqd8VWgQQMcHG7n2YZLvZIEFhgwUK2 4jffsuM2Y83q2QTo33pNX90uinbRs8a1VYRQPxvJYfNZvw+8/7c/BdAKdWqBNYDu+WdH 2oqO5+Ojb9jKiCOPUUAFrrKrToRmEN7phB4izVpvbvU+uGYKelJlqYsr7o3CnK0s4kP6 pZaA==
X-Gm-Message-State: AG10YOQ8nSIeW38l0IeHqY5kQrgOGsHTjPQkAfjYOYEjcpRviGAWMIzlTutwFXRmpMs43kocc3i3yQ5Qk6d7+19K
X-Received: by 10.60.67.34 with SMTP id k2mr15562363oet.67.1453766936221; Mon, 25 Jan 2016 16:08:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.227.39 with HTTP; Mon, 25 Jan 2016 16:08:36 -0800 (PST)
In-Reply-To: 
References: <568D24DD.3050501@connect2id.com>   <568D5610.6000506@lodderstedt.net>     <10631235-AF1B-4122-AEAE-D56BBF38F87E@ve7jtb.com>  <6F32C1CF-EA2A-4A74-A694-F52FD19DBA5C@ve7jtb.com>  
From: William Denniss 
Date: Mon, 25 Jan 2016 16:08:36 -0800
Message-ID: 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=001a11c2e298d21ab4052a317d77
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-discovery-00)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 00:08:59 -0000

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

Thanks Mike, looking forward to the update. I reviewed the other thread.

On Mon, Jan 25, 2016 at 2:49 PM, Mike Jones 
wrote:

> I'll add it to the discovery draft in the next day or so.  Also, please
> see my questions in the message "[OAUTH-WG] Discovery document updates
> planned". I was waiting for that feedback before doing the update.
>
> Thanks,
> -- Mike
> ------------------------------
> From: William Denniss 
> Sent: =E2=80=8E1/=E2=80=8E25/=E2=80=8E2016 2:29 PM
> To: John Bradley 
> Cc: Nat Sakimura ; oauth@ietf.org; Mike Jones
> 
> Subject: Re: [OAUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery
> (draft-jones-oauth-discovery-00)
>
> OK great! It seems that we have consensus on this. So this is what we pla=
n
> to add to our discovery doc, based on this discussion:
>
> "code_challenge_methods_supported": ["plain","S256"]
>
> What are the next steps? Can we we add it to
> https://tools.ietf.org/html/draft-jones-oauth-discovery directly? I see
> that the IANA registry created by that draft is "Specification Required",
> but PKCE is already an RFC without this param being registered.
>
>
> On Mon, Jan 25, 2016 at 2:11 PM, John Bradley  wrote:
>
>> Yes sorry.   code_challenge_method is the query parameter so
>> code_challenge_methods_supported
>>
>>
>> On Jan 25, 2016, at 6:12 PM, William Denniss  wrote=
:
>>
>>
>>
>> On Thu, Jan 21, 2016 at 6:17 AM, John Bradley  wrote:
>>
>>> The code_challenge and code_challenge_method parameter names predate
>>> calling the spec PKCE.
>>>
>>> Given that some of us deployed early versions of PKCE in products and
>>> opensource to mitigate the problem before the spec was completed we dec=
ided
>>> not to rename the parameter names from code_verifier_method to
>>> pkce_verifier_method.
>>>
>>> For consistency we should stick with code_verifier_methods_supported in
>>> discovery.
>>>
>>
>> To clarify, did you mean "code_challenge_methods_supported"?  That is,
>> building on the param name "code_challenge_method" from Section 4.3
>> ?
>>
>>
>>>
>>> John B.
>>>
>>> On Jan 21, 2016, at 3:12 AM, William Denniss 
>>> wrote:
>>>
>>> "code_challenge_methods_supported" definitely works for me.
>>>
>>> Any objections to moving forward with that? I would like to update our
>>> discovery doc shortly.
>>>
>>> On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura 
>>> wrote:
>>>
>>>> Ah, OK. That's actually reasonable.
>>>>
>>>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov matake :
>>>>
>>>>> I prefer =E2=80=9Ccode_challenge_methods_supported=E2=80=9D, since th=
e registered
>>>>> parameter name is =E2=80=9Ccode_challenge_method=E2=80=9D, not =E2=80=
=9Cpkce_method".
>>>>>
>>>>> On Jan 19, 2016, at 11:58, William Denniss 
>>>>> wrote:
>>>>>
>>>>> Seems like we agree this should be added. How should it look?
>>>>>
>>>>> Two ideas:
>>>>>
>>>>> "code_challenge_methods_supported": ["plain", "S256"]
>>>>>
>>>>> or
>>>>>
>>>>> "pkce_methods_supported": ["plain", "S256"]
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderstedt <
>>>>> torsten@lodderstedt.net> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>>
>>>>>> Am 06.01.2016 um 18:25 schrieb William Denniss:
>>>>>>
>>>>>> +1
>>>>>>
>>>>>> On Wed, Jan 6, 2016 at 6:40 AM, John Bradley 
>>>>>> wrote:
>>>>>>
>>>>>>> Good point.  Now that PKCE is a RFC we should add it to discovery.
>>>>>>>
>>>>>>> John B.
>>>>>>> > On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <
>>>>>>> vladimir@connect2id.com> wrote:
>>>>>>> >
>>>>>>> > I just noticed PKCE support is missing from the discovery metadat=
a.
>>>>>>> >
>>>>>>> > Is it a good idea to add it?
>>>>>>> >
>>>>>>> > Cheers,
>>>>>>> >
>>>>>>> > Vladimir
>>>>>>> >
>>>>>>> > --
>>>>>>> > 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinf=
o/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
>>>
>>>
>>>
>>
>>
>

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


Thanks Mike, looking forward to the update. I reviewed the=
 other thread.

On Mon, Jan 25, 2016 at 2:49 PM, Mike Jones <Michael.Jones@mi=
crosoft.com> wrote:










I'll add i=
t to the discovery draft in the next day or so.=C2=A0 Also, please see my q=
uestions in the message "[OAUTH-WG] Discovery document updates planned=
". I was waiting for that feedback before doing
 the update.



Thanks,

-- Mike







From:
William Denniss

Sent:
=E2=80=
=8E1/=E2=80=8E25/=E2=80=8E2016 2:29 PM

To:
John Bradley
Cc:
Nat Sakimura;
oauth@ietf.org; 
Mike Jones

Subject:
Re: [O=
AUTH-WG] Advertise PKCE support in OAuth 2.0 Discovery (draft-jones-oauth-d=
iscovery-00)








OK great! It seems that we have consensus on this. So this=
 is what we plan to add to our discovery doc, based on this discussion:






"code_challenge_methods_supported": ["plain","=
;S256"]







What are the next steps? Can we we add it to=C2=A0https://t=
ools.ietf.org/html/draft-jones-oauth-discovery directly? I see that the=
=C2=A0IANA
 registry created by that=C2=A0draft is "Specification Required", but PKCE is al=
ready an RFC without this param being registered.
















On Mon, Jan 25, 2016 at 2:11 PM, John Bradley 
<ve7jtb@ve7jtb.co=
m> wrote:






Yes sorry. =C2=A0=C2=A0code_challe=
nge_method is the query=C2=A0parameter=
=C2=A0so=C2=A0code_challenge_methods_supported




















On Jan 25, 2016, at 6:12 PM, William Denniss <wdenniss@google.com> wrote:











On Thu, Jan 21, 2016 at 6:17 AM, John Bradley 
<ve7jtb@ve7jtb.co=
m> wrote:




The code_challenge and=C2=A0code_challe=
nge_method parameter names predate calling the spec PKCE. =C2=A0






Given that some of us deployed early versions of PKCE in products and =
opensource to mitigate the problem before the spec was completed we decided=
 not to rename the parameter names from code_verifier_method to pkce_verifi=
er_method. =C2=A0







For consistency we should stick with code_verifier_methods_supported i=
n discovery.











To clarify, did you mean "code_challenge_methods_supported"?=
=C2=A0 That is, building on the param name "code_challenge_method"=
; from
Section 4.3?


=C2=A0













John B.













On Jan 21, 2016, at 3:12 AM, William Denniss <wdenniss@google.com> wrote:





"code_challenge_meth=
ods_supported" definitely works for me.






Any objections to moving forward with=
 that? I would like to update our discovery doc shortly.







On Thu, Jan 21, 2016 at 1:37 PM, Nat Sakimura 
<sakimura@gmail.=
com> wrote:




Ah, OK. That's actually reasonable.=C2=A0






2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 9:31 nov mat=
ake <matake@gmail.=
com>:










I prefer =E2=80=9Ccode_challenge_method=
s_supported=E2=80=9D, since the registered parameter name is =E2=80=9Ccode_=
challenge_method=E2=80=9D, not =E2=80=9Cpkce_method".











On Jan 19, 2016, at 11:58, William Denniss <wdenniss@google.com> wrote:






Seems like we agree this should be added. How should it lo=
ok?



Two ideas:



"code_challenge_methods_supported": ["plain", "S25=
6"]






or





"pkce_methods_supported": ["plain", "S256&quo=
t;]















On Wed, Jan 6, 2016 at 9:59 AM, Torsten Lodderst=
edt 
<torsten@lo=
dderstedt.net> wrote:




+1








Am 06.01.2016 um 18:25 schrieb William Denniss:






+1





On Wed, Jan 6, 2016 at 6:40 AM, John Bradley 
<ve7jtb@ve7jtb.co=
m> wrote:



Good point.=C2=A0 Now that PKCE is a RFC we should add it to discovery.



John B.




> On Jan 6, 2016, at 9:29 AM, Vladimir Dzhuvinov <vladimir@connect2id.com&=
gt; wrote:

>

> I just noticed PKCE support is missing from the discovery metadata.
>

> Is it a good idea to add it?

>

> Cheers,

>

> Vladimir

>

> --

> 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












 


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




















_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth













_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

















_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth


























































--001a11c2e298d21ab4052a317d77--


From nobody Mon Jan 25 16:52:38 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AF11AC40C for ; Mon, 25 Jan 2016 16:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeQi9JZ1WBnl for ; Mon, 25 Jan 2016 16:52:35 -0800 (PST)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 59E541AC405 for ; Mon, 25 Jan 2016 16:52:35 -0800 (PST)
Received: by mail-pa0-x235.google.com with SMTP id yy13so88865833pab.3 for ; Mon, 25 Jan 2016 16:52:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=83SMRjS6rxKes+eb3x1UjD6rVdc1pKsyvkzp2hPeHFU=; b=dP10t7RiJ58OUAv3O75/DSGvY8q09E/TTB5vbyhMhyuNCsa3acYOp/ZCOlpoDZwV8K 4V/jjvzisbpT4pzKkFXIbH5dCzpQNmR/MkVL0F0tuc+hCkXxWJuoTjWPPNQ5P3KZcsSH 7MdqgePuMACEPPxaTrki6fsi3EqsD7UppkkBf6tJmuz4uE4sAGZDht1OWjhGMGyJqsoq 5JUhai5bwTBqxewjmSIWsYi+4e2MiXJkWTatJ2HrNqHe6by0dCLa+jnHMp5t+TMMFhTS gIL7S82W8defCAlnaz3aZdWyTLdBabpNEaF/l0RfCsFDPYpU9W4H0yWh7bdKsv2hO8JI RGLA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=83SMRjS6rxKes+eb3x1UjD6rVdc1pKsyvkzp2hPeHFU=; b=MJFXGw5WLow9HdqYk1U9gx7anVjfQXG1N0aMtM/aa4E/V/odEOATm3OlUDQ37lbzo8 nI58IMEk4qWV83Fv81wPj59sZ9597ncBaEgwDX/ajwMUOZsr8/kh/jAi0TeWwknjfzu4 K/NNSIwUSqX0JxIJ+DLg5oIps2gv1hf8EpyKIPgpXmAIoZSLh6TQ5FlWyHaoFK3ys69/ T65AzeNz3BeycZr4z4EgY3PhnvpcKlsbYFJel0qiFqnl5G6RE1lNMvDfHYkHx2U3BzW7 3qqDHpKUQ9R9gywuw0ExO03vhO1Vc14NQnqE9Ar7/jnwLJxS9/dvC81dQm67nGKmczoe QvLw==
X-Gm-Message-State: AG10YOR8FjxpjZGErUGPkfb2K1hrCSW6VGaSThWzBwd3GPOT7HskIkUVxkpHDXnFEo5Vlg==
X-Received: by 10.66.185.225 with SMTP id ff1mr29657789pac.97.1453769554724; Mon, 25 Jan 2016 16:52:34 -0800 (PST)
Received: from [192.168.1.16] (122x210x153x65.ap122.ftth.ucom.ne.jp. [122.210.153.65]) by smtp.gmail.com with ESMTPSA id u69sm31294110pfa.61.2016.01.25.16.52.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 16:52:34 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6006A2CB-84FA-4135-B3BD-51DCFBFFEE51"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: nov matake 
In-Reply-To: <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com>
Date: Tue, 26 Jan 2016 09:52:30 +0900
Message-Id: <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com>
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com>
To: Phil Hunt 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 00:52:37 -0000

--Apple-Mail=_6006A2CB-84FA-4135-B3BD-51DCFBFFEE51
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The first assumption is coming from the original security report at =
http://arxiv.org/abs/1601.01229 .
RFC 6749 requires TLS between RS and AS, and also between UA and AS, but =
not between UA and RS.

The blog post is based on my Japanese post, and it describes multi-AS =
case.
Nat's another post describes the case which can affect single-AS case =
too.
=
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc67=
49/ =


nov

> On Jan 26, 2016, at 08:22, Phil Hunt  wrote:
>=20
> Sorry, meant to reply-all.
>=20
> Phil
>=20
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>=20
>=20
>=20
>=20
>> Begin forwarded message:
>>=20
>> From: Phil Hunt >
>> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up =
Mitigation
>> Date: January 25, 2016 at 3:20:19 PM PST
>> To: Nat Sakimura >
>>=20
>> I am having trouble with the very first assumption. The user-agent =
sets up a non TLS protected connection to the RP? That=E2=80=99s a =
fundamental violation of 6749.
>>=20
>> Also, the second statement says the RP (assuming it acts as OAuth =
client) is talking to two IDPs.  That=E2=80=99s still a multi-AS case is =
it not?
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com =
phil.hunt@oracle.com =

>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura > wrote:
>>>=20
>>> Hi Phil,=20
>>>=20
>>> Since I was not in Darmstadt, I really do not know what was =
discussed there, but with the compromised developer documentation =
described in =
http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/ =
, =
all RFC6749 clients with a naive implementer will be affected. The =
client does not need to be talking to multiple IdPs.=20
>>>=20
>>> Nat
>>>=20
>>> 2016=E5=B9=B41=E6=9C=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) =
>:
>>> I recall making this point in Germany. 99% of existing use is fine. =
OIDC is probably the largest community that *might* have an issue.
>>>=20
>>> I recall proposing a new security document that covers oauth =
security for dynamic scenarios. "Dynamic" being broadly defined to mean:
>>> * clients who have configured at runtime or install time (including =
clients that do discovery)
>>> * clients that communicate with more than one endpoint
>>> * clients that are deployed in large volume and may update =
frequently (more discussion of "public" cases)
>>> * clients that are script based (loaded into browser on the fly)
>>> * others?
>>>=20
>>> Phil
>>>=20
>>> > On Jan 25, 2016, at 10:39, George Fletcher > wrote:
>>> >
>>> > would
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_6006A2CB-84FA-4135-B3BD-51DCFBFFEE51
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The first assumption is coming from the original security =
report at http://arxiv.org/abs/1601.01229.
RFC 6749 =
requires TLS between RS and AS, and also between UA and AS, but not =
between UA and RS.

The blog post is based on my Japanese post, and it describes =
multi-AS case.
Nat's another post describes the =
case which can affect single-AS case too.
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oaut=
h-2-0-rfc6749/

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

=

--Apple-Mail=_6006A2CB-84FA-4135-B3BD-51DCFBFFEE51--


From nobody Mon Jan 25 17:45:48 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4A6B1ACD53 for ; Mon, 25 Jan 2016 17:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOIX_z1jjFmB for ; Mon, 25 Jan 2016 17:45:44 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65DB1ACD50 for ; Mon, 25 Jan 2016 17:45:44 -0800 (PST)
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 u0Q1jdaq017534 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jan 2016 01:45:39 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u0Q1jdMY011889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Jan 2016 01:45:39 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.13.8) with ESMTP id u0Q1jd6k030434; Tue, 26 Jan 2016 01:45:39 GMT
Received: from [192.168.1.22] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Jan 2016 17:45:38 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_9708DC3C-428F-450B-8E6E-B23B2AF8CC2B"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt 
In-Reply-To: <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com>
Date: Mon, 25 Jan 2016 17:45:36 -0800
Message-Id: <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com>
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com>
To: nov matake 
X-Mailer: Apple Mail (2.3112)
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 01:45:47 -0000

--Apple-Mail=_9708DC3C-428F-450B-8E6E-B23B2AF8CC2B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I would find it hard to believe that is true.

=46rom 6749 Sec 3.1=20
   Since requests to the authorization endpoint result in user
   authentication and the transmission of clear-text credentials (in the
   HTTP response), the authorization server MUST require the use of TLS
   as described in Section 1.6 =
 when sending requests =
to the
   authorization endpoint.

Sec 3.1.2.1=20
   The redirection endpoint SHOULD require the use of TLS as described
   in Section 1.6  when =
the requested response type is "code" or "token",
   or when the redirection request will result in the transmission of
   sensitive credentials over an open network.  This specification does
   not mandate the use of TLS because at the time of this writing,
   requiring clients to deploy TLS is a significant hurdle for many
   client developers.  If TLS is not available, the authorization server
   SHOULD warn the resource owner about the insecure endpoint prior to
   redirection (e.g., display a message during the authorization
   request).

   Lack of transport-layer security can have a severe impact on the
   security of the client and the protected resources it is authorized
   to access.  The use of transport-layer security is particularly
   critical when the authorization process is used as a form of
   delegated end-user authentication by the client (e.g., third-party
   sign-in service).

Section 10.5 talks about transmission of authorization codes in =
connection with redirects.

Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz =
codes.


Phil

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






> On Jan 25, 2016, at 4:52 PM, nov matake  wrote:
>=20
> The first assumption is coming from the original security report at =
http://arxiv.org/abs/1601.01229 .
> RFC 6749 requires TLS between RS and AS, and also between UA and AS, =
but not between UA and RS.
>=20
> The blog post is based on my Japanese post, and it describes multi-AS =
case.
> Nat's another post describes the case which can affect single-AS case =
too.
> =
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc67=
49/ =

>=20
> nov
>=20
>> On Jan 26, 2016, at 08:22, Phil Hunt > wrote:
>>=20
>> Sorry, meant to reply-all.
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com =
phil.hunt@oracle.com =

>>=20
>>=20
>>=20
>>=20
>>=20
>>> Begin forwarded message:
>>>=20
>>> From: Phil Hunt >
>>> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up =
Mitigation
>>> Date: January 25, 2016 at 3:20:19 PM PST
>>> To: Nat Sakimura >
>>>=20
>>> I am having trouble with the very first assumption. The user-agent =
sets up a non TLS protected connection to the RP? That=E2=80=99s a =
fundamental violation of 6749.
>>>=20
>>> Also, the second statement says the RP (assuming it acts as OAuth =
client) is talking to two IDPs.  That=E2=80=99s still a multi-AS case is =
it not?
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com =
phil.hunt@oracle.com =

>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura > wrote:
>>>>=20
>>>> Hi Phil,=20
>>>>=20
>>>> Since I was not in Darmstadt, I really do not know what was =
discussed there, but with the compromised developer documentation =
described in =
http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/ =
, =
all RFC6749 clients with a naive implementer will be affected. The =
client does not need to be talking to multiple IdPs.=20
>>>>=20
>>>> Nat
>>>>=20
>>>> 2016=E5=B9=B41=E6=9C=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) =
>:
>>>> I recall making this point in Germany. 99% of existing use is fine. =
OIDC is probably the largest community that *might* have an issue.
>>>>=20
>>>> I recall proposing a new security document that covers oauth =
security for dynamic scenarios. "Dynamic" being broadly defined to mean:
>>>> * clients who have configured at runtime or install time (including =
clients that do discovery)
>>>> * clients that communicate with more than one endpoint
>>>> * clients that are deployed in large volume and may update =
frequently (more discussion of "public" cases)
>>>> * clients that are script based (loaded into browser on the fly)
>>>> * others?
>>>>=20
>>>> Phil
>>>>=20
>>>> > On Jan 25, 2016, at 10:39, George Fletcher > wrote:
>>>> >
>>>> > would
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth =

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


--Apple-Mail=_9708DC3C-428F-450B-8E6E-B23B2AF8CC2B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I would find it hard to believe that is true.

=46rom 6749 Sec =
3.1 
  =
 Since requests to the authorization endpoint result in user
   authentication and the transmission of clear-text credentials (in the
   HTTP response), the authorization server MUST require the use of TLS
   as described in Section 1.6 when sending requests to the
   authorization endpoint.


Sec =
3.1.2.1 
   The redirection endpoint SHOULD require =
the use of TLS as described
   in Section 1.6 when the requested response type is "code" or =
"token",
   or when the redirection request will result in the transmission of
   sensitive credentials over an open network.  This specification does
   not mandate the use of TLS because at the time of this writing,
   requiring clients to deploy TLS is a significant hurdle for many
   client developers.  If TLS is not available, the authorization server
   SHOULD warn the resource owner about the insecure endpoint prior to
   redirection (e.g., display a message during the authorization
   request).

   Lack of transport-layer security can have a severe impact on the
   security of the client and the protected resources it is authorized
   to access.  The use of transport-layer security is particularly
   critical when the authorization process is used as a form of
   delegated end-user authentication by the client (e.g., third-party
   sign-in service).


Section =
10.5 talks about transmission of authorization codes in connection with =
redirects.

Also =
see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz =
codes.









On Jan 25, 2016, at 4:52 PM, nov matake <matake@gmail.com> =
wrote:

The first =
assumption is coming from the original security report at http://arxiv.org/abs/1601.01229.
RFC 6749 =
requires TLS between RS and AS, and also between UA and AS, but not =
between UA and RS.

The blog post is based on my Japanese post, and it describes =
multi-AS case.
Nat's another post describes the =
case which can affect single-AS case too.
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oaut=
h-2-0-rfc6749/

nov

On Jan =
26, 2016, at 08:22, Phil Hunt <phil.hunt@oracle.com> wrote:

Sorry, meant =
to reply-all.











Begin forwarded message:

From: Phil Hunt <phil.hunt@oracle.com>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up =
Mitigation
Date: January 25, 2016 at 3:20:19 PM PST
To: Nat Sakimura <sakimura@gmail.com>

I am having trouble with the very first =
assumption. The user-agent sets up a non TLS protected connection to the =
RP? That=E2=80=99s a fundamental violation of 6749.

Also, the second statement says the RP =
(assuming it acts as OAuth client) is talking to two IDPs. =
 That=E2=80=99s still a multi-AS case is it not?










On Jan 25, 2016, at 2:58 PM, Nat Sakimura <sakimura@gmail.com> =
wrote:

Hi Phil, 

Since I was not in Darmstadt, I really =
do not know what was discussed there, but with the compromised developer =
documentation described in http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-r=
fc6749/, all RFC6749 clients with a naive implementer will be =
affected. The client does not need to be talking to multiple =
IdPs. 

Nat

2016=E5=B9=B41=E6=9C=882=
6=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) <phil.hunt@oracle.com>:
I recall making this point in Germany. 99% of =
existing use is fine. OIDC is probably the largest community that =
*might* have an issue.



I recall proposing a new security document that covers oauth security =
for dynamic scenarios. "Dynamic" being broadly defined to mean:

* clients who have configured at runtime or install time (including =
clients that do discovery)

* clients that communicate with more than one endpoint

* clients that are deployed in large volume and may update frequently =
(more discussion of "public" cases)

* clients that are script based (loaded into browser on the fly)

* others?



Phil



> On Jan 25, 2016, at 10:39, George Fletcher <gffletch@aol.com> wrote:

>

> would



_______________________________________________

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=_9708DC3C-428F-450B-8E6E-B23B2AF8CC2B--


From nobody Mon Jan 25 17:53:39 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1871ACD84 for ; Mon, 25 Jan 2016 17:53:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.452
X-Spam-Level: 
X-Spam-Status: No, score=0.452 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, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QadCKcc_W2Uu for ; Mon, 25 Jan 2016 17:53:35 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 ABFB71ACD82 for ; Mon, 25 Jan 2016 17:53:35 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id n128so91095916pfn.3 for ; Mon, 25 Jan 2016 17:53:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sbel/m18xwMhW5psECYYUyrH+0mGbdxIyrxtO2nHbt0=; b=flPA96Kh63Kz59ALMAmBJrTWUzUIDPBQACPSpzSW90/s+3hArG0tLUGQEz/QQQb/kn tf+93Ecb8MIVt7MTz1ZmLxgHYVoLHnnyzTdBI0QfrLVgRw5cKKbd5pBpbaYZg631fz0f 5ycIKz4e9vKUrEvCm6nxH9VPL3wLG/920Es871k1yZti7GPoOi9zGNFUtt7XSjGPoGY+ A3pwY7dpVPiQnDpGK6Zuz75vyhMLfU9ltGX+VYpwONuuu/HVktrIR5mq4niWiQAFJDsJ LjKFPU+g9S11J3jngKtt+faEpzxYFcGUx9+cs1UtTJ5Ff77aKUNHbNFFGUpdR5CBVTMn L5Ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Sbel/m18xwMhW5psECYYUyrH+0mGbdxIyrxtO2nHbt0=; b=dv2FQl/30b/kmQYue6n0yUw4nlgSyImJGIYMOW6Q2dFjWpmaTyB2iRJ+VqypLbE70z EPqvm2+TDvar4Hhss9x5ZR2CpCbxc1fLdqmSsvxOiPYHN7FeUm80vkzUtYuHwgL2Upkx QYXu0JiYaZaqrWh/Bbe7ohMiGHh1CXi8H5BL64zb67c2McEYbUdBHaNXYt9zdwlYmkEO SwYMgGwAhlRAY4rmbKP1TuAVPtTrzVR6bRVWQj73ImCht8A/xoOS3ZkspZGRsoQH27yL CNVfXkj4ErgAFVfsB5qJUGVYgQ6bNuKUrsirAF69XixdXigaPsVX94gRD85EUrcn2qEh X7vA==
X-Gm-Message-State: AG10YOTveq6JwdEzFTAix7B1CVb63NLE1ezHLDvi7PwHLIVedFHr9Yy1w5kJI25YM2n+Vw==
X-Received: by 10.98.31.8 with SMTP id f8mr29900501pff.71.1453773215338; Mon, 25 Jan 2016 17:53:35 -0800 (PST)
Received: from [100.67.176.241] (8.190.130.210.rev.vmobile.jp. [210.130.190.8]) by smtp.gmail.com with ESMTPSA id e82sm31462342pfb.76.2016.01.25.17.53.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 17:53:34 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-F21481C0-4F43-4DAE-AAB5-7C445FFF81E8
Mime-Version: 1.0 (1.0)
From: Nov Matake 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com>
Date: Tue, 26 Jan 2016 10:53:32 +0900
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com>
To: Phil Hunt 
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 01:53:38 -0000

--Apple-Mail-F21481C0-4F43-4DAE-AAB5-7C445FFF81E8
Content-Type: text/plain;
	charset=iso-2022-jp
Content-Transfer-Encoding: quoted-printable

It doen't say anything about the first request which initiate the login flow=
.
It is still a reasonable assumption that RP puts a "login with FB" button on=
 a non TLS-protected page.

nov

> On Jan 26, 2016, at 10:45, Phil Hunt  wrote:
>=20
> I would find it hard to believe that is true.
>=20
> =46rom 6749 Sec 3.1=20
>    Since requests to the authorization endpoint result in user
>    authentication and the transmission of clear-text credentials (in the
>    HTTP response), the authorization server MUST require the use of TLS
>    as described in Section 1.6 when sending requests to the
>    authorization endpoint.
>=20
> Sec 3.1.2.1=20
>    The redirection endpoint SHOULD require the use of TLS as described
>    in Section 1.6 when the requested response type is "code" or "token",
>    or when the redirection request will result in the transmission of
>    sensitive credentials over an open network.  This specification does
>    not mandate the use of TLS because at the time of this writing,
>    requiring clients to deploy TLS is a significant hurdle for many
>    client developers.  If TLS is not available, the authorization server
>    SHOULD warn the resource owner about the insecure endpoint prior to
>    redirection (e.g., display a message during the authorization
>    request).
>=20
>    Lack of transport-layer security can have a severe impact on the
>    security of the client and the protected resources it is authorized
>    to access.  The use of transport-layer security is particularly
>    critical when the authorization process is used as a form of
>    delegated end-user authentication by the client (e.g., third-party
>    sign-in service).
>=20
> Section 10.5 talks about transmission of authorization codes in connection=
 with redirects.
>=20
> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz cod=
es.
>=20
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>=20
>=20
>=20
>=20
>> On Jan 25, 2016, at 4:52 PM, nov matake  wrote:
>>=20
>> The first assumption is coming from the original security report at http:=
//arxiv.org/abs/1601.01229.
>> RFC 6749 requires TLS between RS and AS, and also between UA and AS, but n=
ot between UA and RS.
>>=20
>> The blog post is based on my Japanese post, and it describes multi-AS cas=
e.
>> Nat's another post describes the case which can affect single-AS case too=
.
>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6=
749/
>>=20
>> nov
>>=20
>>> On Jan 26, 2016, at 08:22, Phil Hunt  wrote:
>>>=20
>>> Sorry, meant to reply-all.
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> Begin forwarded message:
>>>>=20
>>>> From: Phil Hunt 
>>>> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
>>>> Date: January 25, 2016 at 3:20:19 PM PST
>>>> To: Nat Sakimura 
>>>>=20
>>>> I am having trouble with the very first assumption. The user-agent sets=
 up a non TLS protected connection to the RP? That=1B$B!G=1B(Bs a fundamenta=
l violation of 6749.
>>>>=20
>>>> Also, the second statement says the RP (assuming it acts as OAuth clien=
t) is talking to two IDPs.  That=1B$B!G=1B(Bs still a multi-AS case is it no=
t?
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura  wrote:
>>>>>=20
>>>>> Hi Phil,=20
>>>>>=20
>>>>> Since I was not in Darmstadt, I really do not know what was discussed t=
here, but with the compromised developer documentation described in http://n=
at.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/, all RFC6749 c=
lients with a naive implementer will be affected. The client does not need t=
o be talking to multiple IdPs.=20
>>>>>=20
>>>>> Nat
>>>>>=20
>>>>> 2016=1B$BG/=1B(B1=1B$B7n=1B(B26=1B$BF|=1B(B(=1B$B2P=1B(B) 3:58 Phil Hu=
nt (IDM) :
>>>>>> I recall making this point in Germany. 99% of existing use is fine. O=
IDC is probably the largest community that *might* have an issue.
>>>>>>=20
>>>>>> I recall proposing a new security document that covers oauth security=
 for dynamic scenarios. "Dynamic" being broadly defined to mean:
>>>>>> * clients who have configured at runtime or install time (including c=
lients that do discovery)
>>>>>> * clients that communicate with more than one endpoint
>>>>>> * clients that are deployed in large volume and may update frequently=
 (more discussion of "public" cases)
>>>>>> * clients that are script based (loaded into browser on the fly)
>>>>>> * others?
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> > On Jan 25, 2016, at 10:39, George Fletcher  wrote=
:
>>>>>> >
>>>>>> > would
>>>>>>=20
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>=20

--Apple-Mail-F21481C0-4F43-4DAE-AAB5-7C445FFF81E8
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


It doen't say anything about the first=
 request which initiate the login flow.
It is still a reasonable assump=
tion that RP puts a "login with FB" button on a non TLS-protected page.
=


nov

On Jan 26, 2016, at 10:45, Phil Hunt &=
lt;phil.hunt@oracle.com> wrot=
e:

I would find it hard to believe t=
hat is true.

=46rom 6749=
 Sec 3.1 
  =
 Since requests to the authorization endpoint result in user
   authentication and the transmission of clear-text credentials (in the
   HTTP response), the authorization server MUST require the use of TLS
   as described in Section 1.6 when sending requests to the
   authorization endpoint.


Sec 3.1.2.1 =

   The redirecti=
on endpoint SHOULD require the use of TLS as described
   in Section 1.6 when the requested response type is "code" or "token",
   or when the redirection request will result in the transmission of
   sensitive credentials over an open network.  This specification does
   not mandate the use of TLS because at the time of this writing,
   requiring clients to deploy TLS is a significant hurdle for many
   client developers.  If TLS is not available, the authorization server
   SHOULD warn the resource owner about the insecure endpoint prior to
   redirection (e.g., display a message during the authorization
   request).

   Lack of transport-layer security can have a severe impact on the
   security of the client and the protected resources it is authorized
   to access.  The use of transport-layer security is particularly
   critical when the authorization process is used as a form of
   delegated end-user authentication by the client (e.g., third-party
   sign-in service).


Section 10.=
5 talks about transmission of authorization codes in connection with redirec=
ts.

Also see 6819,=
 Sec 4.4.1.1 regarding eavesdropping or leaking of authz codes.








On J=
an 25, 2016, at 4:52 PM, nov matake <matake@gmail.com> wrote:

The f=
irst assumption is coming from the original security report at http://arxiv.org/abs/1601.01229=
.
RFC 6749 requires TLS between RS and AS, and also betwe=
en UA and AS, but not between UA and RS.

The blog post is based on my Japanese post, and it de=
scribes multi-AS case.
Nat's another post describes the=
 case which can affect single-AS case too.
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oaut=
h-2-0-rfc6749/

nov

On Jan 26, 2016, at 08:22,=
 Phil Hunt <phil.hunt@=
oracle.com> wrote:

Sorry, meant to reply=
-all.



Phil
<=
br class=3D"">
@independentid
www.independentid.com
phil.hunt@oracle.com









Begin forwarded message:

From: =
Phil Hunt <phil.hunt@oracle.com>
=

Subject: Re: [OAUTH-WG] Call for Adopti=
on: OAuth 2.0 Mix-Up Mitigation
Date: January 25, 2016 at 3:20:19 PM PST
To: Nat Sakimura <sakimura@gmail.com>

I am h=
aving trouble with the very first assumption. The user-agent sets up a non T=
LS protected connection to the RP? That=E2=80=99s a fundamental violation of=
 6749.

Also, the second s=
tatement says the RP (assuming it acts as OAuth client) is talking to two ID=
Ps.  That=E2=80=99s still a multi-AS case is it not?



Phil
<=
br class=3D"">
@independentid
www.independentid.com
phil.hunt@oracle.com








On Jan 25, 2016, at 2:58 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Hi P=
hil, 

Since I was n=
ot in Darmstadt, I really do not know what was discussed there, but with the=
 compromised developer documentation described in htt=
p://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/, all=
 RFC6749 clients with a naive implementer will be affected. The client does n=
ot need to be talking to multiple IdPs. 

Nat

2016=E5=B9=B41=E6=9C=
=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) <phil.hunt@oracle.com>:
=

I recall making this point in Germany. 99% of e=
xisting use is fine. OIDC is probably the largest community that *might* hav=
e an issue.



I recall proposing a new security document that covers oauth security for dy=
namic scenarios. "Dynamic" being broadly defined to mean:

* clients who have configured at runtime or install time (including clients t=
hat do discovery)

* clients that communicate with more than one endpoint

* clients that are deployed in large volume and may update frequently (more d=
iscussion of "public" cases)

* clients that are script based (loaded into browser on the fly)

* others?



Phil



> On Jan 25, 2016, at 10:39, George Fletcher <gffletch@aol.com> wrote:

>

> would



_______________________________________________

OAuth mailing list

OAuth@ietf.or=
g

https://www.ietf.org/mailman/listinfo/oauth<=
br class=3D"">





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


=

--Apple-Mail-F21481C0-4F43-4DAE-AAB5-7C445FFF81E8--


From nobody Mon Jan 25 19:29:50 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FEE1B2D5E for ; Mon, 25 Jan 2016 19:29:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2Jj8jKgmVh8 for ; Mon, 25 Jan 2016 19:29:46 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC7481B2D5C for ; Mon, 25 Jan 2016 19:29:45 -0800 (PST)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0Q3TgxC013580 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jan 2016 03:29:43 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u0Q3Tgvd008983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Jan 2016 03:29:42 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 u0Q3TgJZ023220; Tue, 26 Jan 2016 03:29:42 GMT
Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Jan 2016 19:29:42 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-DC5E1E7D-A198-4A21-83F3-04F9B90A360E
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: 
Date: Mon, 25 Jan 2016 19:29:40 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com>
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com> 
To: Nov Matake 
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 03:29:49 -0000

--Apple-Mail-DC5E1E7D-A198-4A21-83F3-04F9B90A360E
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

When the RP acting as the client issues a authorize redirect to the UA it ha=
s to make it with TLS

Phil

> On Jan 25, 2016, at 17:53, Nov Matake  wrote:
>=20
> It doen't say anything about the first request which initiate the login fl=
ow.
> It is still a reasonable assumption that RP puts a "login with FB" button o=
n a non TLS-protected page.
>=20
> nov
>=20
>> On Jan 26, 2016, at 10:45, Phil Hunt  wrote:
>>=20
>> I would find it hard to believe that is true.
>>=20
>> =46rom 6749 Sec 3.1=20
>>    Since requests to the authorization endpoint result in user
>>    authentication and the transmission of clear-text credentials (in the
>>    HTTP response), the authorization server MUST require the use of TLS
>>    as described in Section 1.6 when sending requests to the
>>    authorization endpoint.
>>=20
>> Sec 3.1.2.1=20
>>    The redirection endpoint SHOULD require the use of TLS as described
>>    in Section 1.6 when the requested response type is "code" or "token",
>>    or when the redirection request will result in the transmission of
>>    sensitive credentials over an open network.  This specification does
>>    not mandate the use of TLS because at the time of this writing,
>>    requiring clients to deploy TLS is a significant hurdle for many
>>    client developers.  If TLS is not available, the authorization server
>>    SHOULD warn the resource owner about the insecure endpoint prior to
>>    redirection (e.g., display a message during the authorization
>>    request).
>>=20
>>    Lack of transport-layer security can have a severe impact on the
>>    security of the client and the protected resources it is authorized
>>    to access.  The use of transport-layer security is particularly
>>    critical when the authorization process is used as a form of
>>    delegated end-user authentication by the client (e.g., third-party
>>    sign-in service).
>>=20
>> Section 10.5 talks about transmission of authorization codes in connectio=
n with redirects.
>>=20
>> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz co=
des.
>>=20
>>=20
>> Phil
>>=20
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>>=20
>>=20
>>=20
>>=20
>>=20
>>> On Jan 25, 2016, at 4:52 PM, nov matake  wrote:
>>>=20
>>> The first assumption is coming from the original security report at http=
://arxiv.org/abs/1601.01229.
>>> RFC 6749 requires TLS between RS and AS, and also between UA and AS, but=
 not between UA and RS.
>>>=20
>>> The blog post is based on my Japanese post, and it describes multi-AS ca=
se.
>>> Nat's another post describes the case which can affect single-AS case to=
o.
>>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc=
6749/
>>>=20
>>> nov
>>>=20
>>>> On Jan 26, 2016, at 08:22, Phil Hunt  wrote:
>>>>=20
>>>> Sorry, meant to reply-all.
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> Begin forwarded message:
>>>>>=20
>>>>> From: Phil Hunt 
>>>>> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation=

>>>>> Date: January 25, 2016 at 3:20:19 PM PST
>>>>> To: Nat Sakimura 
>>>>>=20
>>>>> I am having trouble with the very first assumption. The user-agent set=
s up a non TLS protected connection to the RP? That=E2=80=99s a fundamental v=
iolation of 6749.
>>>>>=20
>>>>> Also, the second statement says the RP (assuming it acts as OAuth clie=
nt) is talking to two IDPs.  That=E2=80=99s still a multi-AS case is it not?=

>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura  wrote:=

>>>>>>=20
>>>>>> Hi Phil,=20
>>>>>>=20
>>>>>> Since I was not in Darmstadt, I really do not know what was discussed=
 there, but with the compromised developer documentation described in http:/=
/nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/, all RFC674=
9 clients with a naive implementer will be affected. The client does not nee=
d to be talking to multiple IdPs.=20
>>>>>>=20
>>>>>> Nat
>>>>>>=20
>>>>>> 2016=E5=B9=B41=E6=9C=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) :
>>>>>>> I recall making this point in Germany. 99% of existing use is fine. O=
IDC is probably the largest community that *might* have an issue.
>>>>>>>=20
>>>>>>> I recall proposing a new security document that covers oauth securit=
y for dynamic scenarios. "Dynamic" being broadly defined to mean:
>>>>>>> * clients who have configured at runtime or install time (including c=
lients that do discovery)
>>>>>>> * clients that communicate with more than one endpoint
>>>>>>> * clients that are deployed in large volume and may update frequentl=
y (more discussion of "public" cases)
>>>>>>> * clients that are script based (loaded into browser on the fly)
>>>>>>> * others?
>>>>>>>=20
>>>>>>> Phil
>>>>>>>=20
>>>>>>> > On Jan 25, 2016, at 10:39, George Fletcher  wrot=
e:
>>>>>>> >
>>>>>>> > would
>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>=20
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20

--Apple-Mail-DC5E1E7D-A198-4A21-83F3-04F9B90A360E
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


When the RP acting as the client issue=
s a authorize redirect to the UA it has to make it with TLS

Phil

On Jan 25, 2016, at 17:53, Nov Matake <matake@gmail.com> wrote:

It doen't say anything about the first request which initiate th=
e login flow.
It is still a reasonable assumption that RP puts a "login=
 with FB" button on a non TLS-protected page.

nov

On Jan 26, 2016, at 10:45, Phil Hunt <phil.hunt@oracle.com> wrote:

I would find it hard to believe that is true.

=46rom 6749 Sec 3.1 
   Since requests to the auth=
orization endpoint result in user
   authentication and the transmission of clear-text credentials (in the
   HTTP response), the authorization server MUST require the use of TLS
   as described in Section 1.6 when sending requests to the
   authorization endpoint.


Sec 3.1.2.1 =

   The redirecti=
on endpoint SHOULD require the use of TLS as described
   in Section 1.6 when the requested response type is "code" or "token",
   or when the redirection request will result in the transmission of
   sensitive credentials over an open network.  This specification does
   not mandate the use of TLS because at the time of this writing,
   requiring clients to deploy TLS is a significant hurdle for many
   client developers.  If TLS is not available, the authorization server
   SHOULD warn the resource owner about the insecure endpoint prior to
   redirection (e.g., display a message during the authorization
   request).

   Lack of transport-layer security can have a severe impact on the
   security of the client and the protected resources it is authorized
   to access.  The use of transport-layer security is particularly
   critical when the authorization process is used as a form of
   delegated end-user authentication by the client (e.g., third-party
   sign-in service).


Section 10.=
5 talks about transmission of authorization codes in connection with redirec=
ts.

Also see 6819,=
 Sec 4.4.1.1 regarding eavesdropping or leaking of authz codes.








On J=
an 25, 2016, at 4:52 PM, nov matake <matake@gmail.com> wrote:

The f=
irst assumption is coming from the original security report at http://arxiv.org/abs/1601.01229=
.
RFC 6749 requires TLS between RS and AS, and also betwe=
en UA and AS, but not between UA and RS.

The blog post is based on my Japanese post, and it de=
scribes multi-AS case.
Nat's another post describes the=
 case which can affect single-AS case too.
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oaut=
h-2-0-rfc6749/

nov

On Jan 26, 2016, at 08:22,=
 Phil Hunt <phil.hunt@=
oracle.com> wrote:

Sorry, meant to reply=
-all.



Phil
<=
br class=3D"">
@independentid
www.independentid.com
phil.hunt@oracle.com









Begin forwarded message:

From: =
Phil Hunt <phil.hunt@oracle.com>
=

Subject: Re: [OAUTH-WG] Call for Adopti=
on: OAuth 2.0 Mix-Up Mitigation
Date: January 25, 2016 at 3:20:19 PM PST
To: Nat Sakimura <sakimura@gmail.com>

I am h=
aving trouble with the very first assumption. The user-agent sets up a non T=
LS protected connection to the RP? That=E2=80=99s a fundamental violation of=
 6749.

Also, the second s=
tatement says the RP (assuming it acts as OAuth client) is talking to two ID=
Ps.  That=E2=80=99s still a multi-AS case is it not?



Phil
<=
br class=3D"">
@independentid
www.independentid.com
phil.hunt@oracle.com








On Jan 25, 2016, at 2:58 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Hi P=
hil, 

Since I was n=
ot in Darmstadt, I really do not know what was discussed there, but with the=
 compromised developer documentation described in htt=
p://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/, all=
 RFC6749 clients with a naive implementer will be affected. The client does n=
ot need to be talking to multiple IdPs. 

Nat

2016=E5=B9=B41=E6=9C=
=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) <phil.hunt@oracle.com>:
=

I recall making this point in Germany. 99% of e=
xisting use is fine. OIDC is probably the largest community that *might* hav=
e an issue.



I recall proposing a new security document that covers oauth security for dy=
namic scenarios. "Dynamic" being broadly defined to mean:

* clients who have configured at runtime or install time (including clients t=
hat do discovery)

* clients that communicate with more than one endpoint

* clients that are deployed in large volume and may update frequently (more d=
iscussion of "public" cases)

* clients that are script based (loaded into browser on the fly)

* others?



Phil



> On Jan 25, 2016, at 10:39, George Fletcher <gffletch@aol.com> wrote:

>

> would



_______________________________________________

OAuth mailing list

OAuth@ietf.or=
g

https://www.ietf.org/mailman/listinfo/oauth<=
br class=3D"">





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


=

--Apple-Mail-DC5E1E7D-A198-4A21-83F3-04F9B90A360E--


From nobody Mon Jan 25 19:37:48 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A4C1B2D7D for ; Mon, 25 Jan 2016 19:37:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k29qT84YHvGZ for ; Mon, 25 Jan 2016 19:37:42 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB1E71B2D7C for ; Mon, 25 Jan 2016 19:37:38 -0800 (PST)
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 u0Q3bXEo019847 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jan 2016 03:37:34 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u0Q3bXV9030381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Jan 2016 03:37:33 GMT
Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0122.oracle.com (8.14.4/8.13.8) with ESMTP id u0Q3bX5w005139; Tue, 26 Jan 2016 03:37:33 GMT
Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Jan 2016 19:37:33 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-D77847A4-0083-4E62-9779-9CE6F1EA96F2
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com>
Date: Mon, 25 Jan 2016 19:37:30 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <73E18F37-C765-4F62-A690-102D0C794C52@oracle.com>
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com>  <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com>
To: Nov Matake 
X-Source-IP: userv0021.oracle.com [156.151.31.71]
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 03:37:45 -0000

--Apple-Mail-D77847A4-0083-4E62-9779-9CE6F1EA96F2
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Also the authz endpoint is required to force tls. So if the client doesn't d=
o it the authz should reject (eg by upgrading to tls).=20

Phil

> On Jan 25, 2016, at 19:29, Phil Hunt (IDM)  wrote:
>=20
> When the RP acting as the client issues a authorize redirect to the UA it h=
as to make it with TLS
>=20
> Phil
>=20
>> On Jan 25, 2016, at 17:53, Nov Matake  wrote:
>>=20
>> It doen't say anything about the first request which initiate the login f=
low.
>> It is still a reasonable assumption that RP puts a "login with FB" button=
 on a non TLS-protected page.
>>=20
>> nov
>>=20
>>> On Jan 26, 2016, at 10:45, Phil Hunt  wrote:
>>>=20
>>> I would find it hard to believe that is true.
>>>=20
>>> =46rom 6749 Sec 3.1=20
>>>    Since requests to the authorization endpoint result in user
>>>    authentication and the transmission of clear-text credentials (in the=

>>>    HTTP response), the authorization server MUST require the use of TLS
>>>    as described in Section 1.6 when sending requests to the
>>>    authorization endpoint.
>>>=20
>>> Sec 3.1.2.1=20
>>>    The redirection endpoint SHOULD require the use of TLS as described
>>>    in Section 1.6 when the requested response type is "code" or "token",=

>>>    or when the redirection request will result in the transmission of
>>>    sensitive credentials over an open network.  This specification does
>>>    not mandate the use of TLS because at the time of this writing,
>>>    requiring clients to deploy TLS is a significant hurdle for many
>>>    client developers.  If TLS is not available, the authorization server=

>>>    SHOULD warn the resource owner about the insecure endpoint prior to
>>>    redirection (e.g., display a message during the authorization
>>>    request).
>>>=20
>>>    Lack of transport-layer security can have a severe impact on the
>>>    security of the client and the protected resources it is authorized
>>>    to access.  The use of transport-layer security is particularly
>>>    critical when the authorization process is used as a form of
>>>    delegated end-user authentication by the client (e.g., third-party
>>>    sign-in service).
>>>=20
>>> Section 10.5 talks about transmission of authorization codes in connecti=
on with redirects.
>>>=20
>>> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz c=
odes.
>>>=20
>>>=20
>>> Phil
>>>=20
>>> @independentid
>>> www.independentid.com
>>> phil.hunt@oracle.com
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>> On Jan 25, 2016, at 4:52 PM, nov matake  wrote:
>>>>=20
>>>> The first assumption is coming from the original security report at htt=
p://arxiv.org/abs/1601.01229.
>>>> RFC 6749 requires TLS between RS and AS, and also between UA and AS, bu=
t not between UA and RS.
>>>>=20
>>>> The blog post is based on my Japanese post, and it describes multi-AS c=
ase.
>>>> Nat's another post describes the case which can affect single-AS case t=
oo.
>>>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rf=
c6749/
>>>>=20
>>>> nov
>>>>=20
>>>>> On Jan 26, 2016, at 08:22, Phil Hunt  wrote:
>>>>>=20
>>>>> Sorry, meant to reply-all.
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> Begin forwarded message:
>>>>>>=20
>>>>>> From: Phil Hunt 
>>>>>> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigatio=
n
>>>>>> Date: January 25, 2016 at 3:20:19 PM PST
>>>>>> To: Nat Sakimura 
>>>>>>=20
>>>>>> I am having trouble with the very first assumption. The user-agent se=
ts up a non TLS protected connection to the RP? That=E2=80=99s a fundamental=
 violation of 6749.
>>>>>>=20
>>>>>> Also, the second statement says the RP (assuming it acts as OAuth cli=
ent) is talking to two IDPs.  That=E2=80=99s still a multi-AS case is it not=
?
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> @independentid
>>>>>> www.independentid.com
>>>>>> phil.hunt@oracle.com
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura  wrote=
:
>>>>>>>=20
>>>>>>> Hi Phil,=20
>>>>>>>=20
>>>>>>> Since I was not in Darmstadt, I really do not know what was discusse=
d there, but with the compromised developer documentation described in http:=
//nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/, all RFC67=
49 clients with a naive implementer will be affected. The client does not ne=
ed to be talking to multiple IdPs.=20
>>>>>>>=20
>>>>>>> Nat
>>>>>>>=20
>>>>>>> 2016=E5=B9=B41=E6=9C=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) <=
phil.hunt@oracle.com>:
>>>>>>>> I recall making this point in Germany. 99% of existing use is fine.=
 OIDC is probably the largest community that *might* have an issue.
>>>>>>>>=20
>>>>>>>> I recall proposing a new security document that covers oauth securi=
ty for dynamic scenarios. "Dynamic" being broadly defined to mean:
>>>>>>>> * clients who have configured at runtime or install time (including=
 clients that do discovery)
>>>>>>>> * clients that communicate with more than one endpoint
>>>>>>>> * clients that are deployed in large volume and may update frequent=
ly (more discussion of "public" cases)
>>>>>>>> * clients that are script based (loaded into browser on the fly)
>>>>>>>> * others?
>>>>>>>>=20
>>>>>>>> Phil
>>>>>>>>=20
>>>>>>>> > On Jan 25, 2016, at 10:39, George Fletcher  wro=
te:
>>>>>>>> >
>>>>>>>> > would
>>>>>>>>=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-D77847A4-0083-4E62-9779-9CE6F1EA96F2
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Also the authz endpoint is required to=
 force tls. So if the client doesn't do it the authz should reject (eg by up=
grading to tls). 

Phil

On Jan 25, 2016, at 19:29, P=
hil Hunt (IDM) <phil.hunt@oracle.=
com> wrote:

When the RP=
 acting as the client issues a authorize redirect to the UA it has to make i=
t with TLS

Phil

On Jan 25, 2016, at 17:53, Nov Matake &=
lt;matake@gmail.com> wrote:
It doen't say anything about the fi=
rst request which initiate the login flow.
It is still a reasonable ass=
umption that RP puts a "login with FB" button on a non TLS-protected page.

nov

On Jan 26, 2016, at 10:45, Phil Hun=
t <phil.hunt@oracle.com> w=
rote:

I would find it hard to believ=
e that is true.

=46rom 6=
749 Sec 3.1 
   Since requests to the authorization endpoint result in user
   authentication and the transmission of clear-text credentials (in the
   HTTP response), the authorization server MUST require the use of TLS
   as described in Section 1.6 when sending requests to the
   authorization endpoint.


Sec 3.1.2.1 =

   The redirecti=
on endpoint SHOULD require the use of TLS as described
   in Section 1.6 when the requested response type is "code" or "token",
   or when the redirection request will result in the transmission of
   sensitive credentials over an open network.  This specification does
   not mandate the use of TLS because at the time of this writing,
   requiring clients to deploy TLS is a significant hurdle for many
   client developers.  If TLS is not available, the authorization server
   SHOULD warn the resource owner about the insecure endpoint prior to
   redirection (e.g., display a message during the authorization
   request).

   Lack of transport-layer security can have a severe impact on the
   security of the client and the protected resources it is authorized
   to access.  The use of transport-layer security is particularly
   critical when the authorization process is used as a form of
   delegated end-user authentication by the client (e.g., third-party
   sign-in service).


Section 10.=
5 talks about transmission of authorization codes in connection with redirec=
ts.

Also see 6819,=
 Sec 4.4.1.1 regarding eavesdropping or leaking of authz codes.








On J=
an 25, 2016, at 4:52 PM, nov matake <matake@gmail.com> wrote:

The f=
irst assumption is coming from the original security report at http://arxiv.org/abs/1601.01229=
.
RFC 6749 requires TLS between RS and AS, and also betwe=
en UA and AS, but not between UA and RS.

The blog post is based on my Japanese post, and it de=
scribes multi-AS case.
Nat's another post describes the=
 case which can affect single-AS case too.
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oaut=
h-2-0-rfc6749/

nov

On Jan 26, 2016, at 08:22,=
 Phil Hunt <phil.hunt@=
oracle.com> wrote:

Sorry, meant to reply=
-all.



Phil
<=
br class=3D"">
@independentid
www.independentid.com
phil.hunt@oracle.com









Begin forwarded message:

From: =
Phil Hunt <phil.hunt@oracle.com>
=

Subject: Re: [OAUTH-WG] Call for Adopti=
on: OAuth 2.0 Mix-Up Mitigation
Date: January 25, 2016 at 3:20:19 PM PST
To: Nat Sakimura <sakimura@gmail.com>

I am h=
aving trouble with the very first assumption. The user-agent sets up a non T=
LS protected connection to the RP? That=E2=80=99s a fundamental violation of=
 6749.

Also, the second s=
tatement says the RP (assuming it acts as OAuth client) is talking to two ID=
Ps.  That=E2=80=99s still a multi-AS case is it not?



Phil
<=
br class=3D"">
@independentid
www.independentid.com
phil.hunt@oracle.com








On Jan 25, 2016, at 2:58 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Hi P=
hil, 

Since I was n=
ot in Darmstadt, I really do not know what was discussed there, but with the=
 compromised developer documentation described in htt=
p://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/, all=
 RFC6749 clients with a naive implementer will be affected. The client does n=
ot need to be talking to multiple IdPs. 

Nat

2016=E5=B9=B41=E6=9C=
=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) <phil.hunt@oracle.com>:
=

I recall making this point in Germany. 99% of e=
xisting use is fine. OIDC is probably the largest community that *might* hav=
e an issue.



I recall proposing a new security document that covers oauth security for dy=
namic scenarios. "Dynamic" being broadly defined to mean:

* clients who have configured at runtime or install time (including clients t=
hat do discovery)

* clients that communicate with more than one endpoint

* clients that are deployed in large volume and may update frequently (more d=
iscussion of "public" cases)

* clients that are script based (loaded into browser on the fly)

* others?



Phil



> On Jan 25, 2016, at 10:39, George Fletcher <gffletch@aol.com> wrote:

>

> would



_______________________________________________

OAuth mailing list

OAuth@ietf.or=
g

https://www.ietf.org/mailman/listinfo/oauth<=
br class=3D"">





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


_______________________________________________
OAuth mail=
ing list
OAuth@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/oauth
<=
/body>=

--Apple-Mail-D77847A4-0083-4E62-9779-9CE6F1EA96F2--


From nobody Mon Jan 25 19:57:30 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4761B2DBB for ; Mon, 25 Jan 2016 19:57:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uVWk1yDIwRL for ; Mon, 25 Jan 2016 19:57:25 -0800 (PST)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 8C92F1B2DB9 for ; Mon, 25 Jan 2016 19:57:25 -0800 (PST)
Received: by mail-pa0-x22b.google.com with SMTP id yy13so91267725pab.3 for ; Mon, 25 Jan 2016 19:57:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1EKUHNDCDD1b1+uJ31tkfVPWW02CPrYGWMP7ZEp8LZ0=; b=k061+75j2A9pru9lVZ8mc841mY0i/C4zYBW6gQJzHVRSW30sT9B7jx+YrZqTHyk2// gHLf29MQZ5BQiyBXd2KVkkmEKMHcFBljusPUW+mG77vGUQ44vG3CVI8+4F4Fl4l6jvwO OMvgH+Emzb+bsxzw53oWfwbUme8JUA6F+ceKiTKl/jGkmwmXnKk1egRgPHxKB1lRok1W nW8GWCMcqOh7VXD86a+ncOciXHUVafkKkQIIjTIiWhP/qLwFGeukRWPLVWNi2yJ6oB+W jbDeMEb0L9vlkwnHVlgMCs8piiiclVqBuOi0UqxUEcFxC8xd9He8laZ2EEW/WBzJTAUU Fiwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=1EKUHNDCDD1b1+uJ31tkfVPWW02CPrYGWMP7ZEp8LZ0=; b=Z5FQsk6eyCxOrjV1BUErwuVtctwJiCXSyrjS1Muph6xpDdZU0r6g+8ZWiwsXYn1Fhh 1bY7xSLrg4I6X0l9/Fr0u/5Tjib/7j/NpXhO1qJmOmypSswIBPpTn9JSmtkh+YLwnxaM vZWbXawYsc3kzwQz4c8xgWLquYZPkjGkolNO9wbSt8xndYrjzoA6T6bUCb0Do5bhvu2G 1ph9UjMHGa4YWH+ne+tpx4uKI/Uj5TvHglG5fMN71DQAMzOYxyRTGDQFr2DAUy3tIOlC xhT3I2ucGF0116U1KieLKMQ/lgR7VGV4o+dpqACx1BpdUFNLYVsM0ELLaunEDd3nxeQW HtDw==
X-Gm-Message-State: AG10YOTrxuvSB/n1300gj91SotOseyWvuDNExxgzFK9+toAUED20js8ClvXLPm4CbHmSbQ==
X-Received: by 10.66.102.106 with SMTP id fn10mr31435363pab.60.1453780645173;  Mon, 25 Jan 2016 19:57:25 -0800 (PST)
Received: from tovan.intra.gree-office.net ([27.110.57.140]) by smtp.gmail.com with ESMTPSA id p20sm31830466pfi.86.2016.01.25.19.57.23 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 25 Jan 2016 19:57:24 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E094F7FE-4093-483B-81D0-C51C95CEFA08"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: nov matake 
In-Reply-To: <73E18F37-C765-4F62-A690-102D0C794C52@oracle.com>
Date: Tue, 26 Jan 2016 12:57:22 +0900
Message-Id: <845FCC92-E0A5-413F-BA4E-53E0D4C4DBD4@gmail.com>
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com>  <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com> <73E18F37-C765-4F62-A690-102D0C794C52@oracle.com>
To: "Phil Hunt (IDM)" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 03:57:29 -0000

--Apple-Mail=_E094F7FE-4093-483B-81D0-C51C95CEFA08
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

=10In this flow, AuthZ endpoint is forced to be TLS-protected.
http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png

However, RP=E2=80=99s redirect response which causes following AuthZ =
request is still not TLS-protected, and modified on the attacker=E2=80=99s=
 proxy.

Section 3.2 of this report also describes the same flow.
http://arxiv.org/pdf/1601.01229v2.pdf

> On Jan 26, 2016, at 12:37, Phil Hunt (IDM)  =
wrote:
>=20
> Also the authz endpoint is required to force tls. So if the client =
doesn't do it the authz should reject (eg by upgrading to tls).=20
>=20
> Phil
>=20
> On Jan 25, 2016, at 19:29, Phil Hunt (IDM) > wrote:
>=20
>> When the RP acting as the client issues a authorize redirect to the =
UA it has to make it with TLS
>>=20
>> Phil
>>=20
>> On Jan 25, 2016, at 17:53, Nov Matake > wrote:
>>=20
>>> It doen't say anything about the first request which initiate the =
login flow.
>>> It is still a reasonable assumption that RP puts a "login with FB" =
button on a non TLS-protected page.
>>>=20
>>> nov
>>>=20
>>> On Jan 26, 2016, at 10:45, Phil Hunt > wrote:
>>>=20
>>>> I would find it hard to believe that is true.
>>>>=20
>>>> =46rom 6749 Sec 3.1=20
>>>>    Since requests to the authorization endpoint result in user
>>>>    authentication and the transmission of clear-text credentials =
(in the
>>>>    HTTP response), the authorization server MUST require the use of =
TLS
>>>>    as described in Section 1.6 =
 when sending requests =
to the
>>>>    authorization endpoint.
>>>>=20
>>>> Sec 3.1.2.1=20
>>>>    The redirection endpoint SHOULD require the use of TLS as =
described
>>>>    in Section 1.6  =
when the requested response type is "code" or "token",
>>>>    or when the redirection request will result in the transmission =
of
>>>>    sensitive credentials over an open network.  This specification =
does
>>>>    not mandate the use of TLS because at the time of this writing,
>>>>    requiring clients to deploy TLS is a significant hurdle for many
>>>>    client developers.  If TLS is not available, the authorization =
server
>>>>    SHOULD warn the resource owner about the insecure endpoint prior =
to
>>>>    redirection (e.g., display a message during the authorization
>>>>    request).
>>>>=20
>>>>    Lack of transport-layer security can have a severe impact on the
>>>>    security of the client and the protected resources it is =
authorized
>>>>    to access.  The use of transport-layer security is particularly
>>>>    critical when the authorization process is used as a form of
>>>>    delegated end-user authentication by the client (e.g., =
third-party
>>>>    sign-in service).
>>>>=20
>>>> Section 10.5 talks about transmission of authorization codes in =
connection with redirects.
>>>>=20
>>>> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of =
authz codes.
>>>>=20
>>>>=20
>>>> Phil
>>>>=20
>>>> @independentid
>>>> www.independentid.com =
phil.hunt@oracle.com =

>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>> On Jan 25, 2016, at 4:52 PM, nov matake > wrote:
>>>>>=20
>>>>> The first assumption is coming from the original security report =
at http://arxiv.org/abs/1601.01229 .
>>>>> RFC 6749 requires TLS between RS and AS, and also between UA and =
AS, but not between UA and RS.
>>>>>=20
>>>>> The blog post is based on my Japanese post, and it describes =
multi-AS case.
>>>>> Nat's another post describes the case which can affect single-AS =
case too.
>>>>> =
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc67=
49/ =

>>>>>=20
>>>>> nov
>>>>>=20
>>>>>> On Jan 26, 2016, at 08:22, Phil Hunt > wrote:
>>>>>>=20
>>>>>> Sorry, meant to reply-all.
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> @independentid
>>>>>> www.independentid.com =
phil.hunt@oracle.com =

>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> Begin forwarded message:
>>>>>>>=20
>>>>>>> From: Phil Hunt >
>>>>>>> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up =
Mitigation
>>>>>>> Date: January 25, 2016 at 3:20:19 PM PST
>>>>>>> To: Nat Sakimura >
>>>>>>>=20
>>>>>>> I am having trouble with the very first assumption. The =
user-agent sets up a non TLS protected connection to the RP? That=E2=80=99=
s a fundamental violation of 6749.
>>>>>>>=20
>>>>>>> Also, the second statement says the RP (assuming it acts as =
OAuth client) is talking to two IDPs.  That=E2=80=99s still a multi-AS =
case is it not?
>>>>>>>=20
>>>>>>> Phil
>>>>>>>=20
>>>>>>> @independentid
>>>>>>> www.independentid.com =
phil.hunt@oracle.com =

>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura > wrote:
>>>>>>>>=20
>>>>>>>> Hi Phil,=20
>>>>>>>>=20
>>>>>>>> Since I was not in Darmstadt, I really do not know what was =
discussed there, but with the compromised developer documentation =
described in =
http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/ =
, =
all RFC6749 clients with a naive implementer will be affected. The =
client does not need to be talking to multiple IdPs.=20
>>>>>>>>=20
>>>>>>>> Nat
>>>>>>>>=20
>>>>>>>> 2016=E5=B9=B41=E6=9C=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt =
(IDM) >:
>>>>>>>> I recall making this point in Germany. 99% of existing use is =
fine. OIDC is probably the largest community that *might* have an issue.
>>>>>>>>=20
>>>>>>>> I recall proposing a new security document that covers oauth =
security for dynamic scenarios. "Dynamic" being broadly defined to mean:
>>>>>>>> * clients who have configured at runtime or install time =
(including clients that do discovery)
>>>>>>>> * clients that communicate with more than one endpoint
>>>>>>>> * clients that are deployed in large volume and may update =
frequently (more discussion of "public" cases)
>>>>>>>> * clients that are script based (loaded into browser on the =
fly)
>>>>>>>> * others?
>>>>>>>>=20
>>>>>>>> Phil
>>>>>>>>=20
>>>>>>>> > On Jan 25, 2016, at 10:39, George Fletcher > wrote:
>>>>>>>> >
>>>>>>>> > would
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> OAuth mailing list
>>>>>>>> OAuth@ietf.org 
>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth =

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

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



--Apple-Mail=_E094F7FE-4093-483B-81D0-C51C95CEFA08
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

=10In this flow, AuthZ endpoint is forced to be =
TLS-protected.
http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mi=
xup.png

However, RP=E2=80=99s redirect response which causes =
following AuthZ request is still not TLS-protected, and modified on the =
attacker=E2=80=99s proxy.

Section 3.2 of this report also describes the same =
flow.
http://arxiv.org/pdf/1601.01229v2.pdf

On Jan 26, 2016, at 12:37, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

Also the authz =
endpoint is required to force tls. So if the client doesn't do it the =
authz should reject (eg by upgrading to tls). 

Phil

On Jan 25, 2016, at =
19:29, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

When the RP acting as the =
client issues a authorize redirect to the UA it has to make it with =
TLS

Phil

On Jan 25, 2016, at 17:53, Nov Matake <matake@gmail.com> =
wrote:

It =
doen't say anything about the first request which initiate the login =
flow.
It is still a reasonable assumption that RP puts a "login =
with FB" button on a non TLS-protected page.

nov

On Jan 26, 2016, at 10:45, Phil Hunt <phil.hunt@oracle.com> wrote:

I would find it hard to believe that is =
true.

=46rom 6749 =
Sec 3.1 
   Since requests to the authorization =
endpoint result in user
   authentication and the transmission of clear-text credentials (in the
   HTTP response), the authorization server MUST require the use of TLS
   as described in Section 1.6 when sending requests to the
   authorization endpoint.


Sec =
3.1.2.1 
   The redirection endpoint SHOULD require =
the use of TLS as described
   in Section 1.6 when the requested response type is "code" or =
"token",
   or when the redirection request will result in the transmission of
   sensitive credentials over an open network.  This specification does
   not mandate the use of TLS because at the time of this writing,
   requiring clients to deploy TLS is a significant hurdle for many
   client developers.  If TLS is not available, the authorization server
   SHOULD warn the resource owner about the insecure endpoint prior to
   redirection (e.g., display a message during the authorization
   request).

   Lack of transport-layer security can have a severe impact on the
   security of the client and the protected resources it is authorized
   to access.  The use of transport-layer security is particularly
   critical when the authorization process is used as a form of
   delegated end-user authentication by the client (e.g., third-party
   sign-in service).


Section =
10.5 talks about transmission of authorization codes in connection with =
redirects.

Also =
see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz =
codes.











On Jan 25, 2016, at 4:52 PM, nov matake <matake@gmail.com> =
wrote:

The first =
assumption is coming from the original security report at http://arxiv.org/abs/1601.01229.
RFC 6749 =
requires TLS between RS and AS, and also between UA and AS, but not =
between UA and RS.

The blog post is based on my Japanese post, and it describes =
multi-AS case.
Nat's another post describes the =
case which can affect single-AS case too.
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oaut=
h-2-0-rfc6749/

nov

On Jan =
26, 2016, at 08:22, Phil Hunt <phil.hunt@oracle.com> wrote:

Sorry, meant =
to reply-all.











Begin forwarded message:

From: Phil Hunt <phil.hunt@oracle.com>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up =
Mitigation
Date: January 25, 2016 at 3:20:19 PM PST
To: Nat Sakimura <sakimura@gmail.com>

I am having trouble with the very first =
assumption. The user-agent sets up a non TLS protected connection to the =
RP? That=E2=80=99s a fundamental violation of 6749.

Also, the second statement says the RP =
(assuming it acts as OAuth client) is talking to two IDPs. =
 That=E2=80=99s still a multi-AS case is it not?










On Jan 25, 2016, at 2:58 PM, Nat Sakimura <sakimura@gmail.com> =
wrote:

Hi Phil, 

Since I was not in Darmstadt, I really =
do not know what was discussed there, but with the compromised developer =
documentation described in http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-r=
fc6749/, all RFC6749 clients with a naive implementer will be =
affected. The client does not need to be talking to multiple =
IdPs. 

Nat

2016=E5=B9=B41=E6=9C=882=
6=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) <phil.hunt@oracle.com>:
I recall making this point in Germany. 99% of =
existing use is fine. OIDC is probably the largest community that =
*might* have an issue.



I recall proposing a new security document that covers oauth security =
for dynamic scenarios. "Dynamic" being broadly defined to mean:

* clients who have configured at runtime or install time (including =
clients that do discovery)

* clients that communicate with more than one endpoint

* clients that are deployed in large volume and may update frequently =
(more discussion of "public" cases)

* clients that are script based (loaded into browser on the fly)

* others?



Phil



> On Jan 25, 2016, at 10:39, George Fletcher <gffletch@aol.com> wrote:

>

> would



_______________________________________________

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=_E094F7FE-4093-483B-81D0-C51C95CEFA08--


From nobody Mon Jan 25 20:14:55 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E27C1B2DE8 for ; Mon, 25 Jan 2016 20:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08nf98wLX7kh for ; Mon, 25 Jan 2016 20:14:49 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E19C1B2DD2 for ; Mon, 25 Jan 2016 20:14:49 -0800 (PST)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0Q4Elet016722 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Jan 2016 04:14:47 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u0Q4ElGg017177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 26 Jan 2016 04:14:47 GMT
Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u0Q4EkW7011761; Tue, 26 Jan 2016 04:14:47 GMT
Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Jan 2016 20:14:46 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-4A586BA6-6E86-4311-BD1D-211031C0F037
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: <845FCC92-E0A5-413F-BA4E-53E0D4C4DBD4@gmail.com>
Date: Mon, 25 Jan 2016 20:14:44 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com>
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com>  <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com> <73E18F37-C765-4F62-A690-102D0C794C52@oracle.com> <845FCC92-E0A5-413F-BA4E-53E0D4C4DBD4@gmail.com>
To: nov matake 
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 04:14:52 -0000

--Apple-Mail-4A586BA6-6E86-4311-BD1D-211031C0F037
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

Still don't see it. Though i think the diagram is wrong (the rp should redir=
ct to the ua and not call the authz direct), the IDP should either return an=
 error or redirect the RP to TLS.=20

I don't see this as proper oauth protocol since the RP is MITM the UA rather=
 than acting as a client.=20

Phil

> On Jan 25, 2016, at 19:57, nov matake  wrote:
>=20
> =10In this flow, AuthZ endpoint is forced to be TLS-protected.
> http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png
>=20
> However, RP=E2=80=99s redirect response which causes following AuthZ reque=
st is still not TLS-protected, and modified on the attacker=E2=80=99s proxy.=

>=20
> Section 3.2 of this report also describes the same flow.
> http://arxiv.org/pdf/1601.01229v2.pdf
>=20
>> On Jan 26, 2016, at 12:37, Phil Hunt (IDM)  wrote:
>>=20
>> Also the authz endpoint is required to force tls. So if the client doesn'=
t do it the authz should reject (eg by upgrading to tls).=20
>>=20
>> Phil
>>=20
>>> On Jan 25, 2016, at 19:29, Phil Hunt (IDM)  wrote:=

>>>=20
>>> When the RP acting as the client issues a authorize redirect to the UA i=
t has to make it with TLS
>>>=20
>>> Phil
>>>=20
>>>> On Jan 25, 2016, at 17:53, Nov Matake  wrote:
>>>>=20
>>>> It doen't say anything about the first request which initiate the login=
 flow.
>>>> It is still a reasonable assumption that RP puts a "login with FB" butt=
on on a non TLS-protected page.
>>>>=20
>>>> nov
>>>>=20
>>>>> On Jan 26, 2016, at 10:45, Phil Hunt  wrote:
>>>>>=20
>>>>> I would find it hard to believe that is true.
>>>>>=20
>>>>> =46rom 6749 Sec 3.1=20
>>>>>    Since requests to the authorization endpoint result in user
>>>>>    authentication and the transmission of clear-text credentials (in t=
he
>>>>>    HTTP response), the authorization server MUST require the use of TL=
S
>>>>>    as described in Section 1.6 when sending requests to the
>>>>>    authorization endpoint.
>>>>>=20
>>>>> Sec 3.1.2.1=20
>>>>>    The redirection endpoint SHOULD require the use of TLS as described=

>>>>>    in Section 1.6 when the requested response type is "code" or "token=
",
>>>>>    or when the redirection request will result in the transmission of
>>>>>    sensitive credentials over an open network.  This specification doe=
s
>>>>>    not mandate the use of TLS because at the time of this writing,
>>>>>    requiring clients to deploy TLS is a significant hurdle for many
>>>>>    client developers.  If TLS is not available, the authorization serv=
er
>>>>>    SHOULD warn the resource owner about the insecure endpoint prior to=

>>>>>    redirection (e.g., display a message during the authorization
>>>>>    request).
>>>>>=20
>>>>>    Lack of transport-layer security can have a severe impact on the
>>>>>    security of the client and the protected resources it is authorized=

>>>>>    to access.  The use of transport-layer security is particularly
>>>>>    critical when the authorization process is used as a form of
>>>>>    delegated end-user authentication by the client (e.g., third-party
>>>>>    sign-in service).
>>>>>=20
>>>>> Section 10.5 talks about transmission of authorization codes in connec=
tion with redirects.
>>>>>=20
>>>>> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz=
 codes.
>>>>>=20
>>>>>=20
>>>>> Phil
>>>>>=20
>>>>> @independentid
>>>>> www.independentid.com
>>>>> phil.hunt@oracle.com
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> On Jan 25, 2016, at 4:52 PM, nov matake  wrote:
>>>>>>=20
>>>>>> The first assumption is coming from the original security report at h=
ttp://arxiv.org/abs/1601.01229.
>>>>>> RFC 6749 requires TLS between RS and AS, and also between UA and AS, b=
ut not between UA and RS.
>>>>>>=20
>>>>>> The blog post is based on my Japanese post, and it describes multi-AS=
 case.
>>>>>> Nat's another post describes the case which can affect single-AS case=
 too.
>>>>>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-=
rfc6749/
>>>>>>=20
>>>>>> nov
>>>>>>=20
>>>>>>> On Jan 26, 2016, at 08:22, Phil Hunt  wrote:
>>>>>>>=20
>>>>>>> Sorry, meant to reply-all.
>>>>>>>=20
>>>>>>> Phil
>>>>>>>=20
>>>>>>> @independentid
>>>>>>> www.independentid.com
>>>>>>> phil.hunt@oracle.com
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>> Begin forwarded message:
>>>>>>>>=20
>>>>>>>> From: Phil Hunt 
>>>>>>>> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigat=
ion
>>>>>>>> Date: January 25, 2016 at 3:20:19 PM PST
>>>>>>>> To: Nat Sakimura 
>>>>>>>>=20
>>>>>>>> I am having trouble with the very first assumption. The user-agent s=
ets up a non TLS protected connection to the RP? That=E2=80=99s a fundamenta=
l violation of 6749.
>>>>>>>>=20
>>>>>>>> Also, the second statement says the RP (assuming it acts as OAuth c=
lient) is talking to two IDPs.  That=E2=80=99s still a multi-AS case is it n=
ot?
>>>>>>>>=20
>>>>>>>> Phil
>>>>>>>>=20
>>>>>>>> @independentid
>>>>>>>> www.independentid.com
>>>>>>>> phil.hunt@oracle.com
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura  wro=
te:
>>>>>>>>>=20
>>>>>>>>> Hi Phil,=20
>>>>>>>>>=20
>>>>>>>>> Since I was not in Darmstadt, I really do not know what was discus=
sed there, but with the compromised developer documentation described in htt=
p://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/, all RFC=
6749 clients with a naive implementer will be affected. The client does not n=
eed to be talking to multiple IdPs.=20
>>>>>>>>>=20
>>>>>>>>> Nat
>>>>>>>>>=20
>>>>>>>>> 2016=E5=B9=B41=E6=9C=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM)=
 :
>>>>>>>>>> I recall making this point in Germany. 99% of existing use is fin=
e. OIDC is probably the largest community that *might* have an issue.
>>>>>>>>>>=20
>>>>>>>>>> I recall proposing a new security document that covers oauth secu=
rity for dynamic scenarios. "Dynamic" being broadly defined to mean:
>>>>>>>>>> * clients who have configured at runtime or install time (includi=
ng clients that do discovery)
>>>>>>>>>> * clients that communicate with more than one endpoint
>>>>>>>>>> * clients that are deployed in large volume and may update freque=
ntly (more discussion of "public" cases)
>>>>>>>>>> * clients that are script based (loaded into browser on the fly)
>>>>>>>>>> * others?
>>>>>>>>>>=20
>>>>>>>>>> Phil
>>>>>>>>>>=20
>>>>>>>>>> > On Jan 25, 2016, at 10:39, George Fletcher  w=
rote:
>>>>>>>>>> >
>>>>>>>>>> > would
>>>>>>>>>>=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
>=20

--Apple-Mail-4A586BA6-6E86-4311-BD1D-211031C0F037
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Still don't see it. Though i think the=
 diagram is wrong (the rp should redirct to the ua and not call the authz di=
rect), the IDP should either return an error or redirect the RP to TLS. =
;

I don't see this as proper oauth protocol since the RP is MITM the UA rat=
her than acting as a client. 

Phil

On Jan 25, 2016=
, at 19:57, nov matake <matake@gmail.=
com> wrote:

=10In this flow, A=
uthZ endpoint is forced to be TLS-protected.
http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png=


However, RP=E2=80=
=99s redirect response which causes following AuthZ request is still not TLS=
-protected, and modified on the attacker=E2=80=99s proxy.

Section 3.2 of this report also desc=
ribes the same flow.
http://arxiv.org/pdf/1601.01229v2.pdf

On Jan 26, 2016, at 12:37, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Also the authz endpoint is required to force t=
ls. So if the client doesn't do it the authz should reject (eg by upgrading t=
o tls). 

Phil

On Jan 25, 2016, at 19:29, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

When the RP acting as the client issues a authorize=
 redirect to the UA it has to make it with TLS

=
Phil

On Jan 25, 2016, at 17:53, Nov Mata=
ke <matake@gmail.com&g=
t; wrote:

It doen't say anything about t=
he first request which initiate the login flow.
It is still a reasonabl=
e assumption that RP puts a "login with FB" button on a non TLS-protected pa=
ge.

nov
<=
/div>

On Jan 26, 2016, at 10:45, Phil Hunt <=
;phil.hunt@oracle.com=
> wrote:

I would find it hard to believe that is true.=


=46rom 6749 Sec 3.1&nbs=
p;
   Since reque=
sts to the authorization endpoint result in user
   authentication and the transmission of clear-text credentials (in the
   HTTP response), the authorization server MUST require the use of TLS
   as described in Section 1.6 when sending requests to the
   authorization endpoint.


Sec 3.1.2.1 =

   The redirecti=
on endpoint SHOULD require the use of TLS as described
   in Section 1.6 when the requested response type is "code" or "token",
   or when the redirection request will result in the transmission of
   sensitive credentials over an open network.  This specification does
   not mandate the use of TLS because at the time of this writing,
   requiring clients to deploy TLS is a significant hurdle for many
   client developers.  If TLS is not available, the authorization server
   SHOULD warn the resource owner about the insecure endpoint prior to
   redirection (e.g., display a message during the authorization
   request).

   Lack of transport-layer security can have a severe impact on the
   security of the client and the protected resources it is authorized
   to access.  The use of transport-layer security is particularly
   critical when the authorization process is used as a form of
   delegated end-user authentication by the client (e.g., third-party
   sign-in service).


Section 10.=
5 talks about transmission of authorization codes in connection with redirec=
ts.

Also see 6819,=
 Sec 4.4.1.1 regarding eavesdropping or leaking of authz codes.




Phil
<=
br class=3D"">
@independentid
www.independentid.com
phil.hunt@oracle.com








On Jan 25, 2016, at 4:52 PM, nov matake <matake@gmail.com> wrote:

The first assumption is coming from the original security report at=
 http://arxiv.or=
g/abs/1601.01229.
RFC 6749 requires TLS between RS and AS=
, and also between UA and AS, but not between UA and RS.

The blog post is based on my Japanese=
 post, and it describes multi-AS case.
Nat's another po=
st describes the case which can affect single-AS case too.
http://nat.sakimura.org/2016/01/22/code-phishing=
-attack-on-oauth-2-0-rfc6749/

=

nov

On Jan 26, 2=
016, at 08:22, Phil Hunt <phil.hunt@oracle.com> wrote:

Sorry, m=
eant to reply-all.



Phil
<=
br class=3D"">
@independentid
www.independentid.com
phil.hunt@oracle.com









Begin forwarded message:

From: =
Phil Hunt <phil.hunt@oracle.com>
=

Subject: Re: [OAUTH-WG] Call for Adopti=
on: OAuth 2.0 Mix-Up Mitigation
Date: January 25, 2016 at 3:20:19 PM PST
To: Nat Sakimura <sakimura@gmail.com>

I am h=
aving trouble with the very first assumption. The user-agent sets up a non T=
LS protected connection to the RP? That=E2=80=99s a fundamental violation of=
 6749.

Also, the second s=
tatement says the RP (assuming it acts as OAuth client) is talking to two ID=
Ps.  That=E2=80=99s still a multi-AS case is it not?



Phil
<=
br class=3D"">
@independentid
www.independentid.com
phil.hunt@oracle.com








On Jan 25, 2016, at 2:58 PM, Nat Sakimura <sakimura@gmail.com> wrote:

Hi P=
hil, 

Since I was n=
ot in Darmstadt, I really do not know what was discussed there, but with the=
 compromised developer documentation described in htt=
p://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/, all=
 RFC6749 clients with a naive implementer will be affected. The client does n=
ot need to be talking to multiple IdPs. 

Nat

2016=E5=B9=B41=E6=9C=
=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) <phil.hunt@oracle.com>:
=

I recall making this point in Germany. 99% of e=
xisting use is fine. OIDC is probably the largest community that *might* hav=
e an issue.



I recall proposing a new security document that covers oauth security for dy=
namic scenarios. "Dynamic" being broadly defined to mean:

* clients who have configured at runtime or install time (including clients t=
hat do discovery)

* clients that communicate with more than one endpoint

* clients that are deployed in large volume and may update frequently (more d=
iscussion of "public" cases)

* clients that are script based (loaded into browser on the fly)

* others?



Phil



> On Jan 25, 2016, at 10:39, George Fletcher <gffletch@aol.com> wrote:

>

> would



_______________________________________________

OAuth mailing list

OAuth@ietf.or=
g

https://www.ietf.org/mailman/listinfo/oauth<=
br class=3D"">





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


_________________________________________=
______
OAuth mailing list
OAuth=
@ietf.org
https://www.ietf.org/mailman/list=
info/oauth

=

--Apple-Mail-4A586BA6-6E86-4311-BD1D-211031C0F037--


From nobody Tue Jan 26 04:37:57 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FF01B2FF1 for ; Tue, 26 Jan 2016 04:37:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttTZN3gjVaqY for ; Tue, 26 Jan 2016 04:37:52 -0800 (PST)
Received: from omr-m018e.mx.aol.com (omr-m018e.mx.aol.com [204.29.186.17]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75DD41B2FF0 for ; Tue, 26 Jan 2016 04:37:51 -0800 (PST)
Received: from mtaout-aam01.mx.aol.com (mtaout-aam01.mx.aol.com [172.27.19.145]) by omr-m018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 0F99E3800086; Tue, 26 Jan 2016 07:37:50 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-aam01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 7320138000081; Tue, 26 Jan 2016 07:37:49 -0500 (EST)
To: "Phil Hunt (IDM)" , nov matake 
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com>  <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com> <73E18F37-C765-4F62-A690-102D0C794C52@oracle.com> <845FCC92-E0A5-413F-BA4E-53E0D4C4DBD4@gmail.com> <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com>
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56A7689B.6070205@aol.com>
Date: Tue, 26 Jan 2016 07:37:47 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com>
Content-Type: multipart/alternative; boundary="------------020003050501070709050601"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453811869; bh=kI92hyWNMaD+Rj+RpnPeko4osAonlvmTFCithO4NKaM=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=1y2ySXDUG/thW7oJ8+pf5ot+6fNZ8mQ436+Tx8bP2Z1rcUXZvBcpmF8Uhp2KCB70l dMU908pb3/VOvKJZB7BJHhfzIjvnSyOx2sQ1+YD96k80L8jOCFyzC0wdHYboxHGv37 jO3ANuypf1r9xErldqsAeU2+oGsGyFqQv8EolOMY=
x-aol-sid: 3039ac1b139156a7689d1a10
X-AOL-IP: 10.172.102.124
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 12:37:56 -0000

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

While I agree it may not be "proper" OAuth the fact is that the attack 
is still possible and that means that some acknowledgement (security or 
spec considerations) is required. Being able to MITM the UA or get the 
user to click a link that takes them to a malicious "client" that is 
really a MITM agent is easily doable.

While it's possible to confuse a client that just uses a single AS, that 
attack is more of a "endpoint phishing" style attack than a protocol 
attack. So far, baring no additional use cases, I'm still OK with 
declaring the existing spec viable for clients that pre-configure a 
single AS. Though I do think a "security consideration" should be 
written discussing this "endpoint phishing" attack that Nat describes.

That said, to really protect these flows, I've come to the conclusion 
that discovery and cryptographic binding are required for clients.

Thanks,
George

On 1/25/16 11:14 PM, Phil Hunt (IDM) wrote:
> Still don't see it. Though i think the diagram is wrong (the rp should 
> redirct to the ua and not call the authz direct), the IDP should 
> either return an error or redirect the RP to TLS.
>
> I don't see this as proper oauth protocol since the RP is MITM the UA 
> rather than acting as a client.
>
> Phil
>
> On Jan 25, 2016, at 19:57, nov matake  > wrote:
>
>> In this flow, AuthZ endpoint is forced to be TLS-protected.
>> http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png
>>
>> However, RP’s redirect response which causes following AuthZ request 
>> is still not TLS-protected, and modified on the attacker’s proxy.
>>
>> Section 3.2 of this report also describes the same flow.
>> http://arxiv.org/pdf/1601.01229v2.pdf
>>
>>> On Jan 26, 2016, at 12:37, Phil Hunt (IDM) >> > wrote:
>>>
>>> Also the authz endpoint is required to force tls. So if the client 
>>> doesn't do it the authz should reject (eg by upgrading to tls).
>>>
>>> Phil
>>>
>>> On Jan 25, 2016, at 19:29, Phil Hunt (IDM) >> > wrote:
>>>
>>>> When the RP acting as the client issues a authorize redirect to the 
>>>> UA it has to make it with TLS
>>>>
>>>> Phil
>>>>
>>>> On Jan 25, 2016, at 17:53, Nov Matake >>> > wrote:
>>>>
>>>>> It doen't say anything about the first request which initiate the 
>>>>> login flow.
>>>>> It is still a reasonable assumption that RP puts a "login with FB" 
>>>>> button on a non TLS-protected page.
>>>>>
>>>>> nov
>>>>>
>>>>> On Jan 26, 2016, at 10:45, Phil Hunt >>>> > wrote:
>>>>>
>>>>>> I would find it hard to believe that is true.
>>>>>>
>>>>>> From 6749 Sec 3.1
>>>>>>     Since requests to the authorization endpoint result in user
>>>>>>     authentication and the transmission of clear-text credentials (in the
>>>>>>     HTTP response), the authorization server MUST require the use of TLS
>>>>>>     as described inSection 1.6   when sending requests to the
>>>>>>     authorization endpoint.
>>>>>>
>>>>>> Sec 3.1.2.1
>>>>>>     The redirection endpoint SHOULD require the use of TLS as described
>>>>>>     inSection 1.6   when the requested response type is "code" or "token",
>>>>>>     or when the redirection request will result in the transmission of
>>>>>>     sensitive credentials over an open network.  This specification does
>>>>>>     not mandate the use of TLS because at the time of this writing,
>>>>>>     requiring clients to deploy TLS is a significant hurdle for many
>>>>>>     client developers.  If TLS is not available, the authorization server
>>>>>>     SHOULD warn the resource owner about the insecure endpoint prior to
>>>>>>     redirection (e.g., display a message during the authorization
>>>>>>     request).
>>>>>>
>>>>>>     Lack of transport-layer security can have a severe impact on the
>>>>>>     security of the client and the protected resources it is authorized
>>>>>>     to access.  The use of transport-layer security is particularly
>>>>>>     critical when the authorization process is used as a form of
>>>>>>     delegated end-user authentication by the client (e.g., third-party
>>>>>>     sign-in service).
>>>>>>
>>>>>> Section 10.5 talks about transmission of authorization codes in 
>>>>>> connection with redirects.
>>>>>>
>>>>>> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of 
>>>>>> authz codes.
>>>>>>
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>> @independentid
>>>>>> www.independentid.com 
>>>>>> phil.hunt@oracle.com 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Jan 25, 2016, at 4:52 PM, nov matake >>>>>> > wrote:
>>>>>>>
>>>>>>> The first assumption is coming from the original security report 
>>>>>>> at http://arxiv.org/abs/1601.01229.
>>>>>>> RFC 6749 requires TLS between RS and AS, and also between UA and 
>>>>>>> AS, but not between UA and RS.
>>>>>>>
>>>>>>> The blog post is based on my Japanese post, and it describes 
>>>>>>> multi-AS case.
>>>>>>> Nat's another post describes the case which can affect single-AS 
>>>>>>> case too.
>>>>>>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
>>>>>>>
>>>>>>> nov
>>>>>>>
>>>>>>>> On Jan 26, 2016, at 08:22, Phil Hunt >>>>>>> > wrote:
>>>>>>>>
>>>>>>>> Sorry, meant to reply-all.
>>>>>>>>
>>>>>>>> Phil
>>>>>>>>
>>>>>>>> @independentid
>>>>>>>> www.independentid.com 
>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Begin forwarded message:
>>>>>>>>>
>>>>>>>>> *From: *Phil Hunt >>>>>>>> >
>>>>>>>>> *Subject: **Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up 
>>>>>>>>> Mitigation*
>>>>>>>>> *Date: *January 25, 2016 at 3:20:19 PM PST
>>>>>>>>> *To: *Nat Sakimura >>>>>>>> >
>>>>>>>>>
>>>>>>>>> I am having trouble with the very first assumption. The 
>>>>>>>>> user-agent sets up a non TLS protected connection to the RP? 
>>>>>>>>> That’s a fundamental violation of 6749.
>>>>>>>>>
>>>>>>>>> Also, the second statement says the RP (assuming it acts as 
>>>>>>>>> OAuth client) is talking to two IDPs.  That’s still a multi-AS 
>>>>>>>>> case is it not?
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> @independentid
>>>>>>>>> www.independentid.com 
>>>>>>>>> phil.hunt@oracle.com 
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura >>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Phil,
>>>>>>>>>>
>>>>>>>>>> Since I was not in Darmstadt, I really do not know what was 
>>>>>>>>>> discussed there, but with the compromised developer 
>>>>>>>>>> documentation described in 
>>>>>>>>>> http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/, 
>>>>>>>>>> all RFC6749 clients with a naive implementer will be 
>>>>>>>>>> affected. The client does not need to be talking to multiple 
>>>>>>>>>> IdPs.
>>>>>>>>>>
>>>>>>>>>> Nat
>>>>>>>>>>
>>>>>>>>>> 2016å¹´ 1月26æ—¥(ç«) 3:58 Phil Hunt (IDM) >>>>>>>>> >:
>>>>>>>>>>
>>>>>>>>>>     I recall making this point in Germany. 99% of existing
>>>>>>>>>>     use is fine. OIDC is probably the largest community that
>>>>>>>>>>     *might* have an issue.
>>>>>>>>>>
>>>>>>>>>>     I recall proposing a new security document that covers
>>>>>>>>>>     oauth security for dynamic scenarios. "Dynamic" being
>>>>>>>>>>     broadly defined to mean:
>>>>>>>>>>     * clients who have configured at runtime or install time
>>>>>>>>>>     (including clients that do discovery)
>>>>>>>>>>     * clients that communicate with more than one endpoint
>>>>>>>>>>     * clients that are deployed in large volume and may
>>>>>>>>>>     update frequently (more discussion of "public" cases)
>>>>>>>>>>     * clients that are script based (loaded into browser on
>>>>>>>>>>     the fly)
>>>>>>>>>>     * others?
>>>>>>>>>>
>>>>>>>>>>     Phil
>>>>>>>>>>
>>>>>>>>>>     > On Jan 25, 2016, at 10:39, George Fletcher
>>>>>>>>>>     > wrote:
>>>>>>>>>>     >
>>>>>>>>>>     > would
>>>>>>>>>>
>>>>>>>>>>     _______________________________________________
>>>>>>>>>>     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

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


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


  
    
  
  
    While I agree it may not
      be "proper" OAuth the fact is that the attack is still possible
      and that means that some acknowledgement (security or spec
      considerations) is required. Being able to MITM the UA or get the
      user to click a link that takes them to a malicious "client" that
      is really a MITM agent is easily doable.

      

      While it's possible to confuse a client that just uses a single
      AS, that attack is more of a "endpoint phishing" style attack than
      a protocol attack. So far, baring no additional use cases, I'm
      still OK with declaring the existing spec viable for clients that
      pre-configure a single AS. Though I do think a "security
      consideration" should be written discussing this "endpoint
      phishing" attack that Nat describes.

      

      That said, to really protect these flows, I've come to the
      conclusion that discovery and cryptographic binding are required
      for clients.

      

      Thanks,

      George

      

    
    
On 1/25/16 11:14 PM, Phil Hunt (IDM)
      wrote:

    

    

      
      
Still don't see it. Though i think the diagram is wrong (the
        rp should redirct to the ua and not call the authz direct), the
        IDP should either return an error or redirect the RP to TLS. 

      


      

      
I don't see this as proper oauth
        protocol since the RP is MITM the UA rather than acting as a
        client. 

        

        Phil

      


        On Jan 25, 2016, at 19:57, nov matake <matake@gmail.com>
        wrote:

        

      

      

        

          
          In this flow, AuthZ endpoint is forced to be TLS-protected.
          
          


          

          
However, RP’s redirect response which causes
            following AuthZ request is still not TLS-protected, and
            modified on the attacker’s proxy.

          


          

          
Section 3.2 of this report also describes the
            same flow.

          
          


            

              

                
On Jan 26, 2016, at 12:37, Phil Hunt (IDM)
                  <phil.hunt@oracle.com>
                  wrote:

                

                

                  
                  

                    
Also the authz endpoint is required to
                      force tls. So if the client doesn't do it the
                      authz should reject (eg by upgrading to tls). 

                      

                      Phil

                    


                      On Jan 25, 2016, at 19:29, Phil Hunt (IDM) <phil.hunt@oracle.com>
                      wrote:

                      

                    

                    

                      

                        
                        
When the RP acting as the client
                          issues a authorize redirect to the UA it has
                          to make it with TLS

                          

                          Phil

                        


                          On Jan 25, 2016, at 17:53, Nov Matake <matake@gmail.com>
                          wrote:

                          

                        

                        

                          

                            
                            
It doen't say anything about
                              the first request which initiate the login
                              flow.

                            It is still a reasonable assumption that RP
                            puts a "login with FB" button on a non
                            TLS-protected page.
                            

                              


                                
nov

                              

                              


                                On Jan 26, 2016, at 10:45, Phil Hunt
                                <phil.hunt@oracle.com>
                                wrote:

                                

                              

                              

                                

                                  
                                  I would find it hard to believe that
                                  is true.
                                  


                                  

                                  
From 6749 Sec 3.1 

                                  

                                    
   Since requests to the authorization endpoint result in user
   authentication and the transmission of clear-text credentials (in the
   HTTP response), the authorization server MUST require the use of TLS
   as described in Section 1.6 when sending requests to the
   authorization endpoint.


                                    


                                    

                                    
Sec 3.1.2.1 

                                    

                                      
   The redirection endpoint SHOULD require the use of TLS as described
   in Section 1.6 when the requested response type is "code" or "token",
   or when the redirection request will result in the transmission of
   sensitive credentials over an open network.  This specification does
   not mandate the use of TLS because at the time of this writing,
   requiring clients to deploy TLS is a significant hurdle for many
   client developers.  If TLS is not available, the authorization server
   SHOULD warn the resource owner about the insecure endpoint prior to
   redirection (e.g., display a message during the authorization
   request).

   Lack of transport-layer security can have a severe impact on the
   security of the client and the protected resources it is authorized
   to access.  The use of transport-layer security is particularly
   critical when the authorization process is used as a form of
   delegated end-user authentication by the client (e.g., third-party
   sign-in service).


                                    

                                    


                                    

                                    
Section 10.5 talks
                                      about transmission of
                                      authorization codes in connection
                                      with redirects.

                                    


                                    

                                    
Also see 6819, Sec
                                      4.4.1.1 regarding eavesdropping or
                                      leaking of authz codes.

                                    


                                    

                                    


                                    

                                    
                                    

                                    

                                      

                                        
On Jan 25, 2016,
                                          at 4:52 PM, nov matake <matake@gmail.com>
                                          wrote:

                                        

                                        

                                          
                                          
The
                                            first assumption is coming
                                            from the original security
                                            report at http://arxiv.org/abs/1601.01229.
                                            
RFC 6749
                                              requires TLS between RS
                                              and AS, and also between
                                              UA and AS, but not between
                                              UA and RS.

                                            


                                            

                                            
The blog post
                                              is based on my Japanese
                                              post, and it describes
                                              multi-AS case.

                                            
Nat's another
                                              post describes the case
                                              which can affect single-AS
                                              case too.

                                            
                                            


                                            

                                            
nov

                                            

                                              


                                                

                                                  

                                                    
On Jan
                                                      26, 2016, at
                                                      08:22, Phil Hunt
                                                      <phil.hunt@oracle.com>
                                                      wrote:

                                                    

                                                    

                                                      
                                                      
Sorry, meant to reply-all.
                                                        


                                                          
                                                          


                                                          

                                                          
Begin
                                                          forwarded
                                                          message:

                                                          

                                                          
From:
                                                          Phil
                                                          Hunt <phil.hunt@oracle.com>

                                                          

                                                          
Subject:
                                                          Re:
                                                          [OAUTH-WG]
                                                          Call for
                                                          Adoption:
                                                          OAuth 2.0
                                                          Mix-Up
                                                          Mitigation

                                                          

                                                          
Date:
                                                          January
                                                          25, 2016 at
                                                          3:20:19 PM PST

                                                          

                                                          
To: Nat
                                                          Sakimura <sakimura@gmail.com>

                                                          

                                                          

                                                          

                                                          
                                                          
I am having trouble with the very first
                                                          assumption.
                                                          The user-agent
                                                          sets up a non
                                                          TLS protected
                                                          connection to
                                                          the RP? That’s
                                                          a fundamental
                                                          violation of
                                                          6749.
                                                          


                                                          

                                                          
Also,
                                                          the second
                                                          statement says
                                                          the RP
                                                          (assuming it
                                                          acts as OAuth
                                                          client) is
                                                          talking to two
                                                          IDPs.  That’s
                                                          still a
                                                          multi-AS case
                                                          is it not?

                                                          


                                                          
                                                          

                                                          

                                                          

                                                          
On
                                                          Jan 25, 2016,
                                                          at 2:58 PM,
                                                          Nat Sakimura
                                                          <sakimura@gmail.com>
                                                          wrote:

                                                          

                                                          

                                                          
Hi
                                                          Phil, 
                                                          


                                                          

                                                          
Since
                                                          I was not in
                                                          Darmstadt, I
                                                          really do not
                                                          know what was
                                                          discussed
                                                          there, but
                                                          with the
                                                          compromised
                                                          developer
                                                          documentation
                                                          described in http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/,
                                                          all RFC6749
                                                          clients with a
                                                          naive
                                                          implementer
                                                          will be
                                                          affected. The
                                                          client does
                                                          not need to be
                                                          talking to
                                                          multiple
                                                          IdPs. 

                                                          


                                                          

                                                          

                                                          
Nat

                                                          

                                                          

                                                          

                                                          

                                                          
2016å¹´
                                                          1月26æ—¥(ç«) 3:58
                                                          Phil Hunt
                                                          (IDM) <phil.hunt@oracle.com>:

                                                          

                                                          
I
                                                          recall making
                                                          this point in
                                                          Germany. 99%
                                                          of existing
                                                          use is fine.
                                                          OIDC is
                                                          probably the
                                                          largest
                                                          community that
                                                          *might* have
                                                          an issue.

                                                          

                                                          I recall
                                                          proposing a
                                                          new security
                                                          document that
                                                          covers oauth
                                                          security for
                                                          dynamic
                                                          scenarios.
                                                          "Dynamic"
                                                          being broadly
                                                          defined to
                                                          mean:

                                                          * clients who
                                                          have
                                                          configured at
                                                          runtime or
                                                          install time
                                                          (including
                                                          clients that
                                                          do discovery)

                                                          * clients that
                                                          communicate
                                                          with more than
                                                          one endpoint

                                                          * clients that
                                                          are deployed
                                                          in large
                                                          volume and may
                                                          update
                                                          frequently
                                                          (more
                                                          discussion of
                                                          "public"
                                                          cases)

                                                          * clients that
                                                          are script
                                                          based (loaded
                                                          into browser
                                                          on the fly)

                                                          * others?

                                                          

                                                          Phil

                                                          

                                                          > On Jan
                                                          25, 2016, at
                                                          10:39, George
                                                          Fletcher <gffletch@aol.com>
                                                          wrote:

                                                          >

                                                          > would

                                                          

_______________________________________________

                                                          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


    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------020003050501070709050601--


From nobody Tue Jan 26 05:38:34 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F391A8A6D for ; Tue, 26 Jan 2016 05:38:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TimeUm958q85 for ; Tue, 26 Jan 2016 05:38:26 -0800 (PST)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001: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 71E141A8A6C for ; Tue, 26 Jan 2016 05:38:26 -0800 (PST)
Received: by mail-ig0-x230.google.com with SMTP id ik10so56709186igb.1 for ; Tue, 26 Jan 2016 05:38:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=owuy/hBB84NvNm6r66pKFDKJ0txj2bgEykb/mn3aK/s=; b=b/guh9rWMxqNE5jeUfWCAKPgL+AfjQzW9+2/fiiYAr9hg8zy9zJ3J++9qNMcpnK79E ZuVb+iYzbYxH5YqwyWE/p/bfOt7LiZFPrzy2HwwRhbJ0o7N1tGInw+AvJFw1gVD8G+A8 gy8gmzpmae+4Ave4vVnnwvMv1cDoZZyhjFUy8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=owuy/hBB84NvNm6r66pKFDKJ0txj2bgEykb/mn3aK/s=; b=bSexKZh63HyrBRu0ScVi6laKjVsI4GNIB8nbTuOMkWRvhz3MrKetSWy2WaqTlzIC7l Sgewtt147xTNDgx30LsvThs7N+pg5sIP8D4TTPLQqNk/8oso35Nod6qG7OjlSwcqTNM6 O9NPNY4rBYfxlMJlEqhv9cUR6oTygoSeKAw+qlnJAaeRyPsjeXTTWd+UmSm0X4WlKDAn fXf1UVqIfcz0XYk2zLIrPYmU3z0fGPiAyV9zjYRLsvEOexhdGWCfVY62Id/1/rfV9U3l 3ZX5mrbcl8hFa3SxUyr9atbh08eM4W77f5Nr0EST+EJgMCiA1D67J2bMhvw6j2vJTpB9 45Yg==
X-Gm-Message-State: AG10YOQwIISdiNDmRuA7UZnjNln6Yt67fHvHBMDGaCkxExVjZxzlhUQb9ZHLw5NZ+VzY4fL6rM0/bJL2wkJpNCCg
X-Received: by 10.50.18.112 with SMTP id v16mr22478323igd.57.1453815505454; Tue, 26 Jan 2016 05:38:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.212.69 with HTTP; Tue, 26 Jan 2016 05:37:55 -0800 (PST)
In-Reply-To: 
References: <569E2076.2090405@gmx.net>   <569F915D.8020806@mit.edu>           
From: Brian Campbell 
Date: Tue, 26 Jan 2016 06:37:55 -0700
Message-ID: 
To: Nat Sakimura 
Content-Type: multipart/alternative; boundary=089e0149bd92c5a7ca052a3ccc1e
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 13:38:33 -0000

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

I'm not sure what's described in the blog post is actually a variant of an
attack that anyone is really concerned about? A client developer would have
to change a production system to use an unfamiliar value for the token
endpoint based solely on a an email without even looking at service
documentation or metadata.


On Fri, Jan 22, 2016 at 6:29 PM, Nat Sakimura  wrote:

> I wrote a blog on why the current mix-up draft approach does not solve th=
e
> issue.
>
>
> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6=
749/
>
> Hopefully, the point I am making is clearer by this.
>
> Best,
>
> Nat
>
> 2016=E5=B9=B41=E6=9C=8823=E6=97=A5(=E5=9C=9F) 8:32 Mike Jones :
>
>> I like the =E2=80=9Cfrom which the authorization server's configuration
>> information location can be derived=E2=80=9D language.  Thanks.  I=E2=80=
=99ll plan to
>> incorporate that the next time the draft is revised.
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> *From:* Brian Campbell [mailto:bcampbell@pingidentity.com]
>> *Sent:* Friday, January 22, 2016 3:26 PM
>> *To:* Nat Sakimura 
>> *Cc:* Mike Jones ; Justin Richer <
>> jricher@mit.edu>;  
>>
>>
>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>
>>
>> I agree that the language describing OAuth issuer could and should be
>> improved. The text now reads like it is the exact and full URL where the
>> metadata/discovery document is located. Perhaps something more like "the
>> URL from which the authorization server's configuration information
>> location can be derived" and explain that adding the .well-known bits to
>> the issuer is where the configuration information can actually be found.
>>
>>
>>
>> On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura  wrote=
:
>>
>> Re: iss. I discussed this a bit with Nov in more details. It probably is
>> a sloppy language of the specs that is making it difficult to read what =
you
>> wanted to achieve.
>>
>>
>>
>> In mix-up-mitigation draft, OAuth issuer is "the URL of the authorizatio=
n
>> server's configuration information location". In OAuth discovery draft,
>> there is something called "OAuth 2.0 Configuration Information Location
>> URL", which is equal to "OpenID Connect Issuer".
>>
>> When I wrote the statement, I thought you were pointing to the URL that
>> you can actually pull the configuration information by "the URL of the
>> authorizaiton server's configuration information location" since otherwi=
se
>> you would have used the term "OAuth 2.0 Configuration Information Locati=
on
>> URL". But after all, you probably meant these two are the same. Then I
>> would strongly recommend to fix the language.
>>
>> Now, even If that is the case, the relationship like
>>
>> =C2=B7         iss + .well-know/openid-configuration =3D Connect OP conf=
ig
>> endoint
>>
>> =C2=B7         OAuth config endpoint - .well-known/openid-configuration =
=3D
>> OAuth iss
>>
>> is very confusing.
>>
>>
>>
>> You also claim that your approach is simpler, but to me, your approach
>> seem to be overly complex. It requires discovery and the check for the
>> value of the discovered config information to work as the mitigation.
>> (Right. Draft -01 does not have it, so it does not solve the mix-up issu=
e.)
>> With oauth-meta, you do not need it.
>>
>>
>>
>> Finally, your point that HATEOAS reminds you of WSDL, it is not. If you
>> want to have something similar to WSDL in REST API area, it is Swagger.
>> (Actually, it is gaining a lot of momentum recently, but that's beside t=
he
>> fact ;-). And the point here is not the format but the fact that we need=
 to
>> have a way to associate metadata to the data. The root cause of this mix=
-up
>> attack is that the metadata and data is not associated properly. We have=
 a
>> standard way of associating the data and metadata with link-rel such as
>> RFC5988 so why not use it? Link-rel-href pattern is used a lot now. Most
>> modern web pages actually have it. Using a proper way to associate metad=
ata
>> with data will save you from a lot of other attacks in the future. Inste=
ad
>> of doing patch works, we should solve it architecturally.
>>
>>
>>
>> Nat
>>
>>
>>
>>
>>
>>
>>
>> 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 10:34 Mike Jones :
>>
>> Nat, I=E2=80=99m confused by this statement in the message you reference=
 =E2=80=9CUnfortunately,
>> this does not match the value of OAuth issuer defined in Section 2
>> of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as
>> specified in 3.1. As such, validation as specified in bullet 1 of Sectio=
n 4
>> fails in Google's case -- OR it means that the document is internally
>> inconsistent.=E2=80=9D.  The issuer definition in draft-jones-oauth-disc=
overy is
>> 100% compatible with the one in OpenID Connect Discovery, by design.  In
>> the Google example, both the OpenID issuer and the OAuth issuer values
>> would be the string =E2=80=9Chttps://accounts.google.com=E2=80=9D.  What=
 is the
>> inconsistency that you perceive?
>>
>>
>>
>> The discussion of the duplication problem happened in the private
>> meetings in Yokohama.
>>
>>
>>
>> I will admit, in Yokohama, I didn=E2=80=99t speak up in the public meeti=
ngs to
>> point out that a simpler alternative to oauth-meta was already being
>> discussed there in private, because then I would have had to talk about =
the
>> security issues, which we=E2=80=99d decided not to publicly do at that p=
oint.  So I
>> stayed silent during the poll, out of politeness.  Perhaps I should have
>> found a way to say something then anyway, but that=E2=80=99s water under=
 the bridge
>> now.
>>
>>
>>
>> Finally, for what it=E2=80=99s worth, the HATEOAS stuff reminds me far t=
oo much
>> of Web Services Description Language (WSDL) =E2=80=93 part of the comple=
xity
>> baggage that helped sink Web Services.  The use of =E2=80=9Clink rel=E2=
=80=9D to define an
>> interaction vocabulary and publish endpoints for that vocabulary seems
>> pretty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=
=93 another cute =E2=80=9CWebby=E2=80=9D
>> innovation that never caught on.  The industry has pretty much voted wit=
h
>> its feet and is using JSON for publishing discovery data structures =E2=
=80=93 not
>> =E2=80=9Clink rel=E2=80=9D.  I am against us reverting to the =E2=80=9Cl=
ink rel=E2=80=9D proposal from 2008
>> that never caught on when JSON is simpler and does a better job.
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> *From:* Nat Sakimura [mailto:sakimura@gmail.com]
>> *Sent:* Thursday, January 21, 2016 6:24 AM
>> *To:* Justin Richer ; Mike Jones <
>> Michael.Jones@microsoft.com>
>> *Cc:* William Denniss ;  <
>> oauth@ietf.org>
>>
>>
>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>
>>
>> Mike,
>>
>>
>>
>> You just criticize my draft. That's ok, but I would really like to get
>> some response to my questions stated in
>> https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To
>> me, it just does not seem to work, and the combination of the oauth-meta
>> and PKCE seems to be much more elegan, nicer, and much simpler to
>> implement. If you just give up the dynamic response at the authorization
>> endpoint, then you even do not have to touch the code but just change a
>> config file.
>>
>>
>>
>> Please convince me by answering to my questions.
>>
>>
>>
>> For the record of Yokohama, I do not recall much about duplication in
>> OAuth session. The poll in the room was 19 for / zero against / 4
>> persons need more information. Indeed, it is not duplicating much. And i=
f
>> you move to a new model without pre-configured discovery, it is not
>> duplicating any but the resource endpoint URI, which is optional and is =
for
>> the cases where the client did not know the concrete resource endpoint t=
o
>> start with.
>>
>>
>>
>> I understand your usecases always start from a concrete endpoint
>> location. Mine do not. In a four party model, it is likely not. The user
>> just want to have the service to fetch his data from some resource
>> endpoint. He just hits the service. He does not hit the resource endpoin=
t
>> directly. For example, in the case of a consumer using a personal financ=
e
>> platform (PFP)to manage his pension fund, he hits the PFP and not the
>> Pension fund. Assuming that the pension fund has delegated the
>> authorization control to the authorization server, then, the authorizati=
on
>> server should return both the access token and the endpoint of the pensi=
on
>> fund so that the PFP can pull the data using them. A similar model holds
>> for personal health service and health care providers.
>>
>>
>>
>> Best,
>>
>>
>>
>> Nat
>>
>>
>>
>>
>>
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 21:18 Justin Richer :
>>
>> Convergence is exactly what I=E2=80=99m arguing for, though. These thing=
s ought
>> to work together.
>>
>>
>>
>>  =E2=80=94 Justin
>>
>>
>>
>> On Jan 21, 2016, at 2:55 AM, Mike Jones 
>> wrote:
>>
>>
>>
>> My memory of the discussions of the oauth-meta draft in Yokohama were
>> that many people felt that it was unnecessarily dynamically duplicating =
a
>> lot of information that the client already had.  Most of us that were aw=
are
>> of the attacks then were in favor of a more targeted, minimal approach.
>> You were listened to in Yokohama, but that didn=E2=80=99t necessarily me=
an that
>> people agreed with the approach.  Participants were already aware of the
>> oauth-meta proposal in Darmstadt but no one spoke up in favor of it that=
 I
>> can recall.  Rather, I think people were thinking that =E2=80=9Cless is =
more=E2=80=9D.
>>
>>
>>
>> There have also been discussions in the last day about how dynamically
>> returning a resource URL, which oauth-meta does, is both unnecessary (si=
nce
>> the client initiated the resource authorization already knowing what
>> resource it wants to access) and often problematic, since many
>> authorization servers can authorize access to multiple resources.  If
>> anything, the client should be telling the authorization server what
>> resource it wants to access =E2=80=93 not the other way around.
>>
>>
>>
>> I=E2=80=99m not saying that there aren=E2=80=99t some good ideas in the =
oauth-meta draft
>> =E2=80=93 I=E2=80=99m sure there are, just as there are in the approach =
designed by the
>> participants in Darmstadt.  While I volunteered to write the first draft=
 of
>> the mix-up-mitigation approach, it really reflects something a lot of
>> people have already bought into =E2=80=93 as evidenced in the passion in=
 the
>> high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D thread,=
 and not just my
>> personal project.
>>
>>
>>
>> If you think there are things missing or wrong in the mix-up-mitigation
>> draft, please say what they are.  That will help us quickly converge on =
a
>> solution that will work for everyone.
>>
>>
>>
>>                                                           Sincerely,
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* Nat Sakimura [mailto:sakimura@gmail.com ]
>> *Sent:* Wednesday, January 20, 2016 11:17 PM
>> *To:* Mike Jones ; William Denniss <
>> wdenniss@google.com>; Justin Richer 
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>
>>
>> Hi Mike.
>>
>>
>>
>> Conversely, I would like to ask why this approach does not work for
>> Mix-up attack. As Nov stated, we in fact have discussed the approach in
>> quite a length back in Yokohama. I really would like to know why it does
>> not work.
>>
>>
>>
>> Besides, for oauth-meta approach, mix-up attack is only one of the thing
>> it solves.
>>
>>
>>
>> Nat Sakimura
>>
>>
>>
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones :
>>
>> Not to be negative, but I disagree with adopting
>> draft-sakimura-oauth-meta.  We should define and promote one mitigation
>> approach to the mix-up attacks.  Having two would confuse implementers a=
nd
>> cause compatibility problems =E2=80=93 reducing overall security.
>>
>>
>>
>> The approach defined in draft-jones-oauth-mix-up-mitigation was created
>> in collaboration with the security researchers who identified the proble=
ms
>> in the first place, was vigorously discussed in the security meeting Han=
nes
>> and Torsten held in Darmstadt, and has been since refined based on
>> substantial input from the working group.  And at least three implemente=
rs
>> have already stated that they=E2=80=99ve implemented it.  I=E2=80=99m no=
t saying that it=E2=80=99s,
>> but if there are things missing or things that need to be improved in ou=
r
>> approach, we should do it there, rather introducing a competing approach=
.
>>
>>
>>
>> Also, standard OAuth deployments register the client and then use the
>> information gathered at registration time for subsequent protocol
>> interactions.  They do not need all the configuration information for th=
e
>> authorization server to be retransmitted at runtime.  The oauth-meta dra=
ft
>> goes too far in that direction, at least as I see it.  Returning things =
two
>> ways creates its own problems, as discussed in the Duplicate Information
>> Attacks security considerations section (7.2) of the mix-up-mitigation
>> draft.
>>
>>
>>
>> I=E2=80=99ll note that the mix-up-mitigation approach is compatible with=
 existing
>> practice in both static and dynamic metadata discovery.  Replying to
>> Justin=E2=80=99s comment that =E2=80=9CIt's the pre-configured discovery=
 document that's
>> at the root of the mix-up attack in the first place=E2=80=9D =E2=80=93 t=
his is not the
>> case.  The attacks can be performed without either discovery or dynamic
>> registration.
>>
>>
>>
>> I would be interested in hearing a technical discussion on whether there
>> are aspects of the oauth-meta approach that mitigate aspects of the atta=
cks
>> that the mix-up-mitigation approach does not.  That could help inform
>> whether there are additional things we should add to or change in the
>> mix-up draft.
>>
>>
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William
>> Denniss
>> *Sent:* Wednesday, January 20, 2016 10:37 PM
>> *To:* Justin Richer 
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>
>>
>> +1 to adopt this, and I agree with Justin's comments.
>>
>>
>>
>> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer  wrote:
>>
>> +1
>>
>> Inline discovery and pre-configured discovery (ie, .well-known) should a=
t
>> the very least be compatible and developed together. It's the
>> pre-configured discovery document that's at the root of the mix-up attac=
k
>> in the first place.
>>
>>  -- Justin
>>
>>
>>
>> On 1/19/2016 10:30 PM, Nat Sakimura wrote:
>>
>> Just to give more context, at IETF 94, I have done a presentation on
>> discovery.
>>
>>
>>
>> According to the minutes,
>>
>>
>>
>>     (f) Discovery (Nat)
>>
>>
>>
>>              Nat explains his document as an example of the work that ha=
s to be done
>>
>>              in the area of discovery, which is a topic that has been id=
entified
>>
>>              as necessary for interoperability since many years but so f=
ar there
>>
>>              was not time to work on it. Mike, John and Nat are working =
on a new
>>
>>              document that describes additional discovery-relevant compo=
nents.
>>
>>
>>
>>              Poll: 19 for / zero against / 4 persons need more informati=
on.
>>
>>
>>
>> The document discussed there was
>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
>> simple (only 1-page!) but a very powerful document that nudges towards
>> HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-=
up
>> attack without introducing the concept of issuer which is not in RFC6749=
.
>> It is also good for selecting different endpoints depending on the user
>> authentication and authorization results and more privacy sensitive than
>> pre-announced Discovery document. It also allows you to find to which
>> protected resource endpoint you can use the access token against.
>>
>>
>>
>> In the last sentence of the minutes, it talks about "a new document that
>> describes additional discovery-relevant components". This is
>> https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went for
>> the call for adoption. However, it is only a half of the story. I believ=
e
>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was
>> discussed at IETF 94 and had support there should be adopted as well.
>>
>>
>>
>> Nat Sakimura
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura :
>>
>> Thanks Hannes.
>>
>>
>>
>> I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05,=
 which
>> was discussed in Yokohama, and was largely in agreement if my recollecti=
on
>> is correct. Why is it not in the call for adoption?
>>
>>
>>
>>
>>
>>
>>
>> 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig :
>>
>> Hi all,
>>
>> we have submitted our new charter to the IESG (see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
>> since some IESG members like to see an updated list of milestones as
>> well. For this reason, based on a suggestion from Barry, we are also
>> starting a call for adoption concurrently with the review of the charter
>> text by the IESG.
>>
>> We will post separate mails on the individual documents. Your feedback
>> is important! Please take the time to look at the documents and provide
>> your feedback.
>>
>> Ciao
>> Hannes & Derek
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>>
>> OAuth mailing list
>>
>> OAuth@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>

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


I'm not sure what's described in the blog post is =
actually a variant of an attack that anyone is really concerned about? A cl=
ient developer would have to change a production system to use an unfamilia=
r value for the token endpoint based solely on a an email without even look=
ing at service documentation or metadata. 


On Fri, Jan 22, 2016 at 6=
:29 PM, Nat Sakimura <sakimura@gmail.com> wrote:
I wrote a blog on why the current =
mix-up draft approach does not solve the issue.=C2=A0

http://nat.sakimura.org/2016/01/22/code-phis=
hing-attack-on-oauth-2-0-rfc6749/

Hopefull=
y, the point I am making is clearer by this.=C2=A0

Best,=C2=A0

Nat

2016=E5=B9=B41=E6=9C=8823=E6=97=A5(=E5=9C=9F) 8:3=
2 Mike Jones <Michael.Jones@microsoft.com>:











I like the =E2=80=9Cfrom which=
 the authorization server's configuration information location can be d=
erived=E2=80=9D
 language.=C2=A0 Thanks.=C2=A0 I=E2=80=99ll plan to incorporate that the ne=
xt time the draft is revised.


=C2=A0


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


=C2=A0


From: Brian Campbell [mailto:bcampbell@pingiden=
tity.com]


Sent: Friday, January 22, 2016 3:26 PM

To: Nat Sakimura <sakimura@gmail.com>

Cc: Mike Jones <Michael.Jones@microsoft.com>; Justin Richer <jricher@mit.edu>; &=
lt;oauth@ietf.org&g=
t; <oauth@ietf.org>


=C2=A0




I agree that the lang=
uage describing OAuth issuer could and should be improved. The text now rea=
ds like it is the exact and full URL where the metadata/discovery document =
is located. Perhaps something more like
 "the URL from which the authorization server's configuration info=
rmation location can be derived" and explain that adding the .well-kno=
wn bits to the issuer is where the configuration information can actually b=
e found.










=C2=A0




On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura <sakimura@gmail.com> wrote:






Re: iss. I discussed this a bit with Nov in more det=
ails. It probably is a sloppy language of the specs that is making it diffi=
cult to read what you wanted to achieve.=C2=A0




=C2=A0







In mix-up-mitigation draft, OAuth issuer is "the URL of t=
he authorization server's configuration information location". In =
OAuth discovery draft, there is something called "OAuth 2.0
 Configuration Information Location URL", which is equal to "Open=
ID Connect Issuer".=C2=A0



When I wrote the statement, I thought you were pointing to the=
 URL that you can actually pull the configuration information by "the =
URL of the authorizaiton server's configuration information
 location" since otherwise you would have used the term "OAuth 2.=
0 Configuration Information Location URL". But after all, you probably=
 meant these two are the same. Then I would strongly recommend to fix the l=
anguage.=C2=A0



Now, even If that is the case, the relationship like=C2=A0<=
/u>



=C2=B7=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
iss + .well-know/openid-configurat=
ion =3D Connect OP config endoint



=C2=B7=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
OAuth config endpoint - .well-know=
n/openid-configuration =3D OAuth iss




is very confusing.=C2=A0<=
u>








=C2=A0






You also claim that your approach is si=
mpler, but to me, your approach seem to be overly complex. It requires disc=
overy and the check for the value of the discovered
 config information to work as the mitigation. (Right. Draft -01 does not h=
ave it, so it does not solve the mix-up issue.) With oauth-meta, you do not=
 need it.=C2=A0






=C2=A0






Finally, your point that HATEOAS remind=
s you of WSDL, it is not. If you want to have something similar to WSDL in =
REST API area, it is Swagger. (Actually, it is
 gaining a lot of momentum recently, but that's beside the fact ;-). An=
d the point here is not the format but the fact that we need to have a way =
to associate metadata to the data. The root cause of this mix-up attack is =
that the metadata and data is not associated
 properly. We have a standard way of associating the data and metadata with=
 link-rel such as RFC5988 so why not use it? Link-rel-href pattern is used =
a lot now. Most modern web pages actually have it. Using a proper way to as=
sociate metadata with data will
 save you from a lot of other attacks in the future. Instead of doing patch=
 works, we should solve it=C2=A0architecturally.=C2=A0=







=C2=A0






Nat






=C2=A0






=C2=A0






=C2=A0















Nat, I=E2=80=99m confused by this sta=
tement in the message you reference =E2=80=9CUnfortunately,
 this does not match the value of OAuth issuer defined in Section 2 of=C2=
=A0draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as=
 specified in 3.1.=C2=A0As such, validation as specified in bullet 1 of Sec=
tion 4 fails in Google's case -- OR it means that the
 document is internally inconsistent.=E2=80=9D.=C2=A0=
 The issuer definition in draft-jones-oauth-discovery is 100% compatible wi=
th the one in OpenID Connect Discovery, by design.=C2=A0 In the
 Google example, both the OpenID issuer and the OAuth issuer values would b=
e the string =E2=80=9Chttps://accounts.google.com=E2=80=9D.=C2=A0 What is the inconsiste=
ncy that you perceive?


=C2=A0


The discussion of the duplication pro=
blem happened in the private meetings in Yokohama.


=C2=A0


I will admit, in Yokohama, I didn=E2=
=80=99t speak up in the public meetings to point out that a simpler alterna=
tive
 to oauth-meta was already being discussed there in private, because then I=
 would have had to talk about the security issues, which we=E2=80=99d decid=
ed not to publicly do at that point.=C2=A0 So I stayed silent during the po=
ll, out of politeness.=C2=A0 Perhaps I should have
 found a way to say something then anyway, but that=E2=80=99s water under t=
he bridge now.


=C2=A0


Finally, for what it=E2=80=99s worth,=
 the HATEOAS stuff reminds me far too much of Web Services Description
 Language (WSDL) =E2=80=93 part of the complexity baggage that helped sink =
Web Services.=C2=A0 The use of =E2=80=9Clink rel=E2=80=9D to define an inte=
raction vocabulary and publish endpoints for that vocabulary seems pretty b=
aroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=93 another =
cute =E2=80=9CWebby=E2=80=9D
 innovation that never caught on.=C2=A0 The industry has pretty much voted =
with its feet and is using JSON for publishing discovery data structures =
=E2=80=93 not =E2=80=9Clink rel=E2=80=9D.=C2=A0 I am against us reverting t=
o the =E2=80=9Clink rel=E2=80=9D proposal from 2008 that never caught on wh=
en JSON is
 simpler and does a better job.


=C2=A0


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


=C2=A0


From: Nat Sakimura [mailto:sakimura@gmail.com]


Sent: Thursday, January 21, 2016 6:24 AM

To: Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>
Cc: William Denniss <wdenniss@google.com>; <oauth@ietf.org> <oauth@ietf.org>












Subject: Re: [OAUTH-WG] Call for Adoption










=C2=A0




Mike,=C2=A0




=C2=A0






You just criticize my draft. That's ok, but I wo=
uld really like to get some response to my questions stated in=C2=A0https://www.ietf.org/mail-archive/web/oauth/current/msg15483.=
html=C2=A0.
 To me, it just does not seem to work, and the combination of the oauth-met=
a and PKCE seems to be much more elegan, nicer, and much simpler to impleme=
nt. If you just give up the dynamic response at the authorization endpoint,=
 then you even do not have to touch
 the code but just change a config file.=C2=A0






=C2=A0






Please convince me by answering to my questions.=C2=
=A0






=C2=A0






For the record of Yokohama, I do not recall much abo=
ut duplication in OAuth session. The poll in the room was=C2=A019 for / zero against / 4
 persons need more information. Indeed, it is not duplicating much. And if =
you move to a new model without pre-configured discovery, it is not duplica=
ting any but the resource endpoint URI, which is optional and is for the ca=
ses where the client did not know
 the concrete resource endpoint to start with.=C2=A0





=C2=A0






I unders=
tand your usecases always start from a concrete endpoint location. Mine do =
not. In a four party model, it is likely not. The user
 just want to have the service to fetch his data from some resource endpoin=
t. He just hits the service. He does not hit the resource endpoint directly=
. For example, in the case of a consumer using a personal finance platform =
(PFP)to manage his pension fund,
 he hits the PFP and not the Pension fund. Assuming that the pension fund h=
as delegated the authorization control to the authorization server, then, t=
he authorization server should return both the access token and the endpoin=
t of the pension fund so that the
 PFP can pull the data using them. A similar model holds for personal healt=
h service and health care providers.=C2=A0






=C2=A0






Best,=C2=
=A0






=C2=A0






Nat






=C2=A0






=C2=A0






2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
 21:18 Justin Richer <jricher@mit.edu>:








Convergence is exactly what I=E2=80=99m arguing for,=
 though. These things ought to work together.








=C2=A0






=C2=A0=E2=80=94 Justin










=C2=A0








On Jan 21, 2016, at 2:55 AM, Mike Jones <Michael.Jones@mic=
rosoft.com> wrote:




=C2=A0








My memory of the discussions of the o=
auth-meta draft in Yokohama were that many people felt that it
 was unnecessarily dynamically duplicating a lot of information that the cl=
ient already had.=C2=A0 Most of us that were aware of the attacks then were=
 in favor of a more targeted, minimal approach.=C2=A0 You were listened to =
in Yokohama, but that didn=E2=80=99t necessarily mean
 that people agreed with the approach.=C2=A0 Participants were already awar=
e of the oauth-meta proposal in Darmstadt but no one spoke up in favor of i=
t that I can recall.=C2=A0 Rather, I think people were thinking that =E2=80=
=9Cless is more=E2=80=9D.


=C2=A0


There have also been discussions in t=
he last day about how dynamically returning a resource URL, which
 oauth-meta does, is both unnecessary (since the client initiated the resou=
rce authorization already knowing what resource it wants to access) and oft=
en problematic, since many authorization servers can authorize access to mu=
ltiple resources.=C2=A0 If anything,
 the client should be telling the authorization server what resource it wan=
ts to access =E2=80=93 not the other way around.


=C2=A0


I=E2=80=99m not saying that there are=
n=E2=80=99t some good ideas in the oauth-meta draft =E2=80=93 I=E2=80=99m s=
ure there are, just
 as there are in the approach designed by the participants in Darmstadt.=C2=
=A0 While I volunteered to write the first draft of the mix-up-mitigation a=
pproach, it really reflects something a lot of people have already bought i=
nto =E2=80=93 as evidenced in the passion in
 the high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D threa=
d, and not just my personal project.


=C2=A0


If you think there are things missing=
 or wrong in the mix-up-mitigation draft, please say what they
 are.=C2=A0 That will help us quickly converge on a solution that will work=
 for everyone.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Sincerely,


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


=C2=A0


From: Nat Sakimura [mailto:sakimura@gmail.com]


Sent: Wednesday, January 20, 2016 11:17 PM

To: Mike Jones <Michael.Jones@microsoft.com>; William Denniss <wdenniss@google.com<=
/a>>; Justin Richer <jricher@mit.edu>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Call for Adoption


=C2=A0




Hi Mike.=C2=A0




=C2=A0






Conversely, I would like to ask why this approach do=
es not work for Mix-up attack.=C2=A0As Nov stated, we in fact have discusse=
d the approach in quite a length back in Yokohama. I really
 would like to know why it does not work.=C2=A0






=C2=A0






Besides, for oauth-meta approach, mix-up attack is o=
nly one of the thing it solves.=C2=A0






=C2=A0






Nat Sakimura






=C2=A0






2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
 16:02 Mike Jones <Michael.Jones@microsoft.com>:










Not to be negative, but I disagree wi=
th adopting draft-sakimura-oauth-meta.=C2=A0 We should define and promote
 one mitigation approach to the mix-up attacks.=C2=A0 Having two would conf=
use implementers and cause compatibility problems =E2=80=93 reducing overal=
l security.


=C2=A0


The approach defined in draft-jones-o=
auth-mix-up-mitigation was created in collaboration with the security
 researchers who identified the problems in the first place, was vigorously=
 discussed in the security meeting Hannes and Torsten held in Darmstadt, an=
d has been since refined based on substantial input from the working group.=
=C2=A0 And at least three implementers
 have already stated that they=E2=80=99ve implemented it.=C2=A0 I=E2=80=99m=
 not saying that it=E2=80=99s, but if there are things missing or things th=
at need to be improved in our approach, we should do it there, rather intro=
ducing a competing approach.


=C2=A0


Also, standard OAuth deployments regi=
ster the client and then use the information gathered at registration
 time for subsequent protocol interactions.=C2=A0 They do not need all the =
configuration information for the authorization server to be retransmitted =
at runtime.=C2=A0 The oauth-meta draft goes too far in that direction, at l=
east as I see it.=C2=A0 Returning things two ways
 creates its own problems, as discussed in the Duplicate Information Attack=
s security considerations section (7.2) of the mix-up-mitigation draft.


=C2=A0


I=E2=80=99ll note that the mix-up-mit=
igation approach is compatible with existing practice in both static and
 dynamic metadata discovery.=C2=A0 Replying to Justin=E2=80=99s comment tha=
t =E2=80=9CIt's the pre-configured discovery document that's=
 at the root of the mix-up attack in the first place=E2=80=
=9D =E2=80=93 this
 is not the case.=C2=A0 The attacks can be performed without either discove=
ry or dynamic registration.


=C2=A0


I would be interested in hearing a te=
chnical discussion on whether there are aspects of the oauth-meta
 approach that mitigate aspects of the attacks that the mix-up-mitigation a=
pproach does not.=C2=A0 That could help inform whether there are additional=
 things we should add to or change in the mix-up draft.


=C2=A0


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


=C2=A0


From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of William Denniss

Sent: Wednesday, January 20, 2016 10:37 PM

To: Justin Richer <jricher@mit.edu>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Call for Adoption










=C2=A0




+1 to adopt this, and I agree with Justin's comm=
ents.




=C2=A0




On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer <<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>=
 wrote:






+1



Inline discovery and pre-configured discovery (ie, .well-known) should at t=
he very least be compatible and developed together. It's the pre-config=
ured discovery document that's at the root of the mix-up attack in the =
first place.



=C2=A0-- Justin






=C2=A0<=
/p>



On 1/19/2016 10:30 PM, Nat Sakimura wrote:=









Just to give more context, at IETF 94, I have done a=
 presentation on discovery.=C2=A0





=C2=A0






According to the minutes,=C2=A0






=C2=A0






=C2=A0=C2=A0=C2=A0 (f) Discovery (Nat)=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Nat explains his document as an e=
xample of the work that has to be done


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the area of discovery, which is a t=
opic that has been identified


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as necessary for interoperability sinc=
e many years but so far there


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was not time to work on it. Mike, John=
 and Nat are working on a new


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document that describes additional dis=
covery-relevant components.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Poll: 19 for / zero against / 4 p=
ersons need more information.


=C2=A0


The document discussed there was

https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a sim=
ple (only 1-page!) but a very powerful document that nudges towards HATEOAS=
 which is at the core of RESTful-ness. It also mitigates the Mix-up attack =
without introducing the concept
 of issuer which is not in RFC6749. It is also good for selecting different=
 endpoints depending on the user authentication and authorization results a=
nd more privacy sensitive than pre-announced Discovery document. It also al=
lows you to find to which protected
 resource endpoint you can use the access token against.=C2=A0






=C2=A0




In the last sentence of the minutes, it talks about =
"a new document that describes additional discovery-relevant component=
s". This is=C2=A0https://tools.ietf.org/html/draft-jones=
-oauth-discovery-00.=C2=A0
 It went for the call for adoption. However, it is only a half of the story=
. I believe=C2=A0https://tools.ietf.org/html/draft-sakimura-oau=
th-meta-05=C2=A0that was discussed at IETF
 94 and had support there=C2=A0should be adopted as well.=C2=A0 <=
/u>




=C2=A0






Nat Sakimura




=C2=A0






=C2=A0






=C2=A0








=C2=A0






2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4)
 12:05 Nat Sakimura <sakimura@gmail.com>:








Thanks Hannes.=C2=A0





=C2=A0






I did not find=C2=A0https://tools.ietf.o=
rg/html/draft-sakimura-oauth-meta-05,=C2=A0which was discussed
 in Yokohama, and was largely in agreement if my recollection is correct. W=
hy is it not in the call for adoption?=C2=A0






=C2=A0






=C2=A0






=C2=A0






2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB)
 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:










Hi all,



we have submitted our new charter to the IESG (see

http://www.ietf.org/mail-archive/web/oauth/current/msg1=
5379.html) and

since some IESG members like to see an updated list of milestones as

well. For this reason, based on a suggestion from Barry, we are also

starting a call for adoption concurrently with the review of the charter
text by the IESG.



We will post separate mails on the individual documents. Your feedback

is important! Please take the time to look at the documents and provide

your feedback.



Ciao

Hannes & Derek



_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth










=C2=A0<=
/p>

_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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




=C2=A0










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth






=C2=A0










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth
















=C2=A0
























_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth






=C2=A0









--089e0149bd92c5a7ca052a3ccc1e--


From nobody Tue Jan 26 07:21:32 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6301B2B0E for ; Tue, 26 Jan 2016 07:21:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5hTFOvAMDp0 for ; Tue, 26 Jan 2016 07:21:19 -0800 (PST)
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 0B6A11B2B04 for ; Tue, 26 Jan 2016 07:21:18 -0800 (PST)
Received: from mtaout-mcd02.mx.aol.com (mtaout-mcd02.mx.aol.com [172.26.223.206]) by omr-a018e.mx.aol.com (Outbound Mail Relay) with ESMTP id 2508538003E4; Tue, 26 Jan 2016 10:21:17 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mcd02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 92F6C38000089; Tue, 26 Jan 2016 10:21:16 -0500 (EST)
To: Brian Campbell , Nat Sakimura 
References: <569E2076.2090405@gmx.net>  <569F915D.8020806@mit.edu>            
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56A78EEF.4090706@aol.com>
Date: Tue, 26 Jan 2016 10:21:19 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020804070802010500000102"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453821677; bh=sYux7uQYWyxSgtr53SjrOiOjjRAXlpDY7KlRUKDk1kI=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=Iyyela6zjqUfpUORpYU67vU0HnmfRMVp67iqcCbQBUZ3bq4KwV5LT6YIErzehaYUL zFAdyFTK7k2k+VI+ph8faXUy1Ph8mrmwOHARQq4/pmz3uWvfYMDM8FR7XnybfgDTPm +GyT0nTh5K44N78SWp+y5C46T7/lU2gG1E4xqcg0=
x-aol-sid: 3039ac1adfce56a78eec2349
X-AOL-IP: 10.172.102.124
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 15:21:29 -0000

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

While it's a different way of getting the endpoints mixed up, I don't 
think that makes it invalid. If we are going to address the attack 
vector I believe we should solve it for "all" cases not just the ones 
that seem most likely.

Thanks,
George

On 1/26/16 8:37 AM, Brian Campbell wrote:
> I'm not sure what's described in the blog post is actually a variant 
> of an attack that anyone is really concerned about? A client developer 
> would have to change a production system to use an unfamiliar value 
> for the token endpoint based solely on a an email without even looking 
> at service documentation or metadata.
>
>
> On Fri, Jan 22, 2016 at 6:29 PM, Nat Sakimura  > wrote:
>
>     I wrote a blog on why the current mix-up draft approach does not
>     solve the issue.
>
>     http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
>
>     Hopefully, the point I am making is clearer by this.
>
>     Best,
>
>     Nat
>
>     2016年1月23日(土) 8:32 Mike Jones      >:
>
>         I like the “from which the authorization server's
>         configuration information location can be derived†language. 
>         Thanks.  I’ll plan to incorporate that the next time the draft
>         is revised.
>
>         -- Mike
>
>         *From:*Brian Campbell [mailto:bcampbell@pingidentity.com
>         ]
>         *Sent:* Friday, January 22, 2016 3:26 PM
>         *To:* Nat Sakimura          >
>         *Cc:* Mike Jones          >; Justin Richer
>         >;          > >
>
>
>         *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>         I agree that the language describing OAuth issuer could and
>         should be improved. The text now reads like it is the exact
>         and full URL where the metadata/discovery document is located.
>         Perhaps something more like "the URL from which the
>         authorization server's configuration information location can
>         be derived" and explain that adding the .well-known bits to
>         the issuer is where the configuration information can actually
>         be found.
>
>         On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura
>         > wrote:
>
>             Re: iss. I discussed this a bit with Nov in more details.
>             It probably is a sloppy language of the specs that is
>             making it difficult to read what you wanted to achieve.
>
>             In mix-up-mitigation draft, OAuth issuer is "the URL of
>             the authorization server's configuration information
>             location". In OAuth discovery draft, there is something
>             called "OAuth 2.0 Configuration Information Location URL",
>             which is equal to "OpenID Connect Issuer".
>
>             When I wrote the statement, I thought you were pointing to
>             the URL that you can actually pull the configuration
>             information by "the URL of the authorizaiton server's
>             configuration information location" since otherwise you
>             would have used the term "OAuth 2.0 Configuration
>             Information Location URL". But after all, you probably
>             meant these two are the same. Then I would strongly
>             recommend to fix the language.
>
>             Now, even If that is the case, the relationship like
>
>             ·iss + .well-know/openid-configuration = Connect OP config
>             endoint
>
>             ·OAuth config endpoint - .well-known/openid-configuration
>             = OAuth iss
>
>             is very confusing.
>
>             You also claim that your approach is simpler, but to me,
>             your approach seem to be overly complex. It requires
>             discovery and the check for the value of the discovered
>             config information to work as the mitigation. (Right.
>             Draft -01 does not have it, so it does not solve the
>             mix-up issue.) With oauth-meta, you do not need it.
>
>             Finally, your point that HATEOAS reminds you of WSDL, it
>             is not. If you want to have something similar to WSDL in
>             REST API area, it is Swagger. (Actually, it is gaining a
>             lot of momentum recently, but that's beside the fact ;-).
>             And the point here is not the format but the fact that we
>             need to have a way to associate metadata to the data. The
>             root cause of this mix-up attack is that the metadata and
>             data is not associated properly. We have a standard way of
>             associating the data and metadata with link-rel such as
>             RFC5988 so why not use it? Link-rel-href pattern is used a
>             lot now. Most modern web pages actually have it. Using a
>             proper way to associate metadata with data will save you
>             from a lot of other attacks in the future. Instead of
>             doing patch works, we should solve it architecturally.
>
>             Nat
>
>             2016年1月22日(金) 10:34 Mike Jones
>                          >:
>
>                 Nat, I’m confused by this statement in the message you
>                 reference “Unfortunately, this does not match the
>                 value of OAuth issuer defined in Section 2
>                 of draft-jones-oauth-mix-up-mitigation-01 nor the
>                 'iss' returned as specified in 3.1. As such,
>                 validation as specified in bullet 1 of Section 4 fails
>                 in Google's case -- OR it means that the document is
>                 internally inconsistent.â€. The issuer definition in
>                 draft-jones-oauth-discovery is 100% compatible with
>                 the one in OpenID Connect Discovery, by design.  In
>                 the Google example, both the OpenID issuer and the
>                 OAuth issuer values would be the string
>                 “https://accounts.google.comâ€. What is the
>                 inconsistency that you perceive?
>
>                 The discussion of the duplication problem happened in
>                 the private meetings in Yokohama.
>
>                 I will admit, in Yokohama, I didn’t speak up in the
>                 public meetings to point out that a simpler
>                 alternative to oauth-meta was already being discussed
>                 there in private, because then I would have had to
>                 talk about the security issues, which we’d decided not
>                 to publicly do at that point.  So I stayed silent
>                 during the poll, out of politeness.  Perhaps I should
>                 have found a way to say something then anyway, but
>                 that’s water under the bridge now.
>
>                 Finally, for what it’s worth, the HATEOAS stuff
>                 reminds me far too much of Web Services Description
>                 Language (WSDL) – part of the complexity baggage that
>                 helped sink Web Services.  The use of “link rel†to
>                 define an interaction vocabulary and publish endpoints
>                 for that vocabulary seems pretty baroque and
>                 reminiscent of “microformats†– another cute “Webbyâ€
>                 innovation that never caught on.  The industry has
>                 pretty much voted with its feet and is using JSON for
>                 publishing discovery data structures – not “link
>                 relâ€.  I am against us reverting to the “link relâ€
>                 proposal from 2008 that never caught on when JSON is
>                 simpler and does a better job.
>
>                 -- Mike
>
>                 *From:*Nat Sakimura [mailto:sakimura@gmail.com
>                 ]
>                 *Sent:* Thursday, January 21, 2016 6:24 AM
>                 *To:* Justin Richer                  >; Mike Jones
>                                  >
>                 *Cc:* William Denniss                  >;                  >                  >
>
>
>                 *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>                 Mike,
>
>                 You just criticize my draft. That's ok, but I would
>                 really like to get some response to my questions
>                 stated in
>                 https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html .
>                 To me, it just does not seem to work, and the
>                 combination of the oauth-meta and PKCE seems to be
>                 much more elegan, nicer, and much simpler to
>                 implement. If you just give up the dynamic response at
>                 the authorization endpoint, then you even do not have
>                 to touch the code but just change a config file.
>
>                 Please convince me by answering to my questions.
>
>                 For the record of Yokohama, I do not recall much about
>                 duplication in OAuth session. The poll in the room was
>                 19 for / zero against / 4 persons need more
>                 information. Indeed, it is not duplicating much. And
>                 if you move to a new model without pre-configured
>                 discovery, it is not duplicating any but the resource
>                 endpoint URI, which is optional and is for the cases
>                 where the client did not know the concrete resource
>                 endpoint to start with.
>
>                 I understand your usecases always start from a
>                 concrete endpoint location. Mine do not. In a four
>                 party model, it is likely not. The user just want to
>                 have the service to fetch his data from some resource
>                 endpoint. He just hits the service. He does not hit
>                 the resource endpoint directly. For example, in the
>                 case of a consumer using a personal finance platform
>                 (PFP)to manage his pension fund, he hits the PFP and
>                 not the Pension fund. Assuming that the pension fund
>                 has delegated the authorization control to the
>                 authorization server, then, the authorization server
>                 should return both the access token and the endpoint
>                 of the pension fund so that the PFP can pull the data
>                 using them. A similar model holds for personal health
>                 service and health care providers.
>
>                 Best,
>
>                 Nat
>
>                 2016年1月21日(木) 21:18 Justin Richer                  >:
>
>                     Convergence is exactly what I’m arguing for,
>                     though. These things ought to work together.
>
>                      — Justin
>
>                         On Jan 21, 2016, at 2:55 AM, Mike Jones
>                                                  > wrote:
>
>                         My memory of the discussions of the oauth-meta
>                         draft in Yokohama were that many people felt
>                         that it was unnecessarily dynamically
>                         duplicating a lot of information that the
>                         client already had.  Most of us that were
>                         aware of the attacks then were in favor of a
>                         more targeted, minimal approach.  You were
>                         listened to in Yokohama, but that didn’t
>                         necessarily mean that people agreed with the
>                         approach. Participants were already aware of
>                         the oauth-meta proposal in Darmstadt but no
>                         one spoke up in favor of it that I can recall.
>                         Rather, I think people were thinking that
>                         “less is moreâ€.
>
>                         There have also been discussions in the last
>                         day about how dynamically returning a resource
>                         URL, which oauth-meta does, is both
>                         unnecessary (since the client initiated the
>                         resource authorization already knowing what
>                         resource it wants to access) and often
>                         problematic, since many authorization servers
>                         can authorize access to multiple resources. 
>                         If anything, the client should be telling the
>                         authorization server what resource it wants to
>                         access – not the other way around.
>
>                         I’m not saying that there aren’t some good
>                         ideas in the oauth-meta draft – I’m sure there
>                         are, just as there are in the approach
>                         designed by the participants in Darmstadt.
>                         While I volunteered to write the first draft
>                         of the mix-up-mitigation approach, it really
>                         reflects something a lot of people have
>                         already bought into – as evidenced in the
>                         passion in the high-volume “Mix-Up About The
>                         Mix-Up Mitigation†thread, and not just my
>                         personal project.
>
>                         If you think there are things missing or wrong
>                         in the mix-up-mitigation draft, please say
>                         what they are.  That will help us quickly
>                         converge on a solution that will work for
>                         everyone.
>
>                         Sincerely,
>
>                         -- Mike
>
>                         *From:*Nat Sakimura [mailto:sakimura@gmail.com]
>                         *Sent:* Wednesday, January 20, 2016 11:17 PM
>                         *To:* Mike Jones                          >; William
>                         Denniss                          >; Justin Richer
>                         >
>                         *Cc:* oauth@ietf.org 
>                         *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>                         Hi Mike.
>
>                         Conversely, I would like to ask why this
>                         approach does not work for Mix-up attack. As
>                         Nov stated, we in fact have discussed the
>                         approach in quite a length back in Yokohama. I
>                         really would like to know why it does not work.
>
>                         Besides, for oauth-meta approach, mix-up
>                         attack is only one of the thing it solves.
>
>                         Nat Sakimura
>
>                         2016年1月21日(木) 16:02 Mike Jones
>                                                  >:
>
>                             Not to be negative, but I disagree with
>                             adopting draft-sakimura-oauth-meta. We
>                             should define and promote one mitigation
>                             approach to the mix-up attacks. Having two
>                             would confuse implementers and cause
>                             compatibility problems – reducing overall
>                             security.
>
>                             The approach defined in
>                             draft-jones-oauth-mix-up-mitigation was
>                             created in collaboration with the security
>                             researchers who identified the problems in
>                             the first place, was vigorously discussed
>                             in the security meeting Hannes and Torsten
>                             held in Darmstadt, and has been since
>                             refined based on substantial input from
>                             the working group.  And at least three
>                             implementers have already stated that
>                             they’ve implemented it.  I’m not saying
>                             that it’s, but if there are things missing
>                             or things that need to be improved in our
>                             approach, we should do it there, rather
>                             introducing a competing approach.
>
>                             Also, standard OAuth deployments register
>                             the client and then use the information
>                             gathered at registration time for
>                             subsequent protocol interactions. They do
>                             not need all the configuration information
>                             for the authorization server to be
>                             retransmitted at runtime. The oauth-meta
>                             draft goes too far in that direction, at
>                             least as I see it.  Returning things two
>                             ways creates its own problems, as
>                             discussed in the Duplicate Information
>                             Attacks security considerations section
>                             (7.2) of the mix-up-mitigation draft.
>
>                             I’ll note that the mix-up-mitigation
>                             approach is compatible with existing
>                             practice in both static and dynamic
>                             metadata discovery. Replying to Justin’s
>                             comment that “It's the pre-configured
>                             discovery document that's at the root of
>                             the mix-up attack in the first place†–
>                             this is not the case.  The attacks can be
>                             performed without either discovery or
>                             dynamic registration.
>
>                             I would be interested in hearing a
>                             technical discussion on whether there are
>                             aspects of the oauth-meta approach that
>                             mitigate aspects of the attacks that the
>                             mix-up-mitigation approach does not.  That
>                             could help inform whether there are
>                             additional things we should add to or
>                             change in the mix-up draft.
>
>                             -- Mike
>
>                             *From:*OAuth
>                             [mailto:oauth-bounces@ietf.org
>                             ] *On
>                             Behalf Of *William Denniss
>                             *Sent:* Wednesday, January 20, 2016 10:37 PM
>                             *To:* Justin Richer                              >
>                             *Cc:* oauth@ietf.org 
>                             *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>                             +1 to adopt this, and I agree with
>                             Justin's comments.
>
>                             On Wed, Jan 20, 2016 at 9:53 PM, Justin
>                             Richer                              > wrote:
>
>                                 +1
>
>                                 Inline discovery and pre-configured
>                                 discovery (ie, .well-known) should at
>                                 the very least be compatible and
>                                 developed together. It's the
>                                 pre-configured discovery document
>                                 that's at the root of the mix-up
>                                 attack in the first place.
>
>                                  -- Justin
>
>                                 On 1/19/2016 10:30 PM, Nat Sakimura wrote:
>
>                                     Just to give more context, at IETF
>                                     94, I have done a presentation on
>                                     discovery.
>
>                                     According to the minutes,
>
>                                         (f) Discovery (Nat)
>
>                                                  Nat explains his
>                                     document as an example of the work
>                                     that has to be done
>
>                                                  in the area of
>                                     discovery, which is a topic that
>                                     has been identified
>
>                                                  as necessary for
>                                     interoperability since many years
>                                     but so far there
>
>                                                  was not time to work
>                                     on it. Mike, John and Nat are
>                                     working on a new
>
>                                                  document that
>                                     describes additional
>                                     discovery-relevant components.
>
>                                                  Poll: 19 for / zero
>                                     against / 4 persons need more
>                                     information.
>
>                                     The document discussed there was
>                                     https://tools.ietf.org/html/draft-sakimura-oauth-meta-05.
>                                     This is a simple (only 1-page!)
>                                     but a very powerful document that
>                                     nudges towards HATEOAS which is at
>                                     the core of RESTful-ness. It also
>                                     mitigates the Mix-up attack
>                                     without introducing the concept of
>                                     issuer which is not in RFC6749. It
>                                     is also good for selecting
>                                     different endpoints depending on
>                                     the user authentication and
>                                     authorization results and more
>                                     privacy sensitive than
>                                     pre-announced Discovery document.
>                                     It also allows you to find to
>                                     which protected resource endpoint
>                                     you can use the access token against.
>
>                                     In the last sentence of the
>                                     minutes, it talks about "a new
>                                     document that describes additional
>                                     discovery-relevant components".
>                                     This is
>                                     https://tools.ietf.org/html/draft-jones-oauth-discovery-00.
>                                     It went for the call for adoption.
>                                     However, it is only a half of the
>                                     story. I believe
>                                     https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that
>                                     was discussed at IETF 94 and had
>                                     support there should be adopted as
>                                     well.
>
>                                     Nat Sakimura
>
>                                     2016年1月20日(水) 12:05 Nat
>                                     Sakimura                                      >:
>
>                                         Thanks Hannes.
>
>                                         I did not find
>                                         https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which
>                                         was discussed in Yokohama, and
>                                         was largely in agreement if my
>                                         recollection is correct. Why
>                                         is it not in the call for
>                                         adoption?
>
>                                         2016å¹´1月19æ—¥(ç«) 20:39 Hannes
>                                         Tschofenig
>                                                                                  >:
>
>                                             Hi all,
>
>                                             we have submitted our new
>                                             charter to the IESG (see
>                                             http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html)
>                                             and
>                                             since some IESG members
>                                             like to see an updated
>                                             list of milestones as
>                                             well. For this reason,
>                                             based on a suggestion from
>                                             Barry, we are also
>                                             starting a call for
>                                             adoption concurrently with
>                                             the review of the charter
>                                             text by the IESG.
>
>                                             We will post separate
>                                             mails on the individual
>                                             documents. Your feedback
>                                             is important! Please take
>                                             the time to look at the
>                                             documents and provide
>                                             your feedback.
>
>                                             Ciao
>                                             Hannes & Derek
>
>                                             _______________________________________________
>                                             OAuth mailing list
>                                             OAuth@ietf.org
>                                             
>                                             https://www.ietf.org/mailman/listinfo/oauth
>
>                                     _______________________________________________
>
>                                     OAuth mailing list
>
>                                     OAuth@ietf.org 
>
>                                     https://www.ietf.org/mailman/listinfo/oauth
>
>
>                                 _______________________________________________
>                                 OAuth mailing list
>                                 OAuth@ietf.org 
>                                 https://www.ietf.org/mailman/listinfo/oauth
>
>                             _______________________________________________
>                             OAuth mailing list
>                             OAuth@ietf.org 
>                             https://www.ietf.org/mailman/listinfo/oauth
>
>
>             _______________________________________________
>             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


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


  
    
  
  
    While it's a different way
      of getting the endpoints mixed up, I don't think that makes it
      invalid. If we are going to address the attack vector I believe we
      should solve it for "all" cases not just the ones that seem most
      likely.

      

      Thanks,

      George

    

    
On 1/26/16 8:37 AM, Brian Campbell
      wrote:

    

    

      
I'm not sure what's described in the blog post is
        actually a variant of an attack that anyone is really concerned
        about? A client developer would have to change a production
        system to use an unfamiliar value for the token endpoint based
        solely on a an email without even looking at service
        documentation or metadata. 

        


        

      

      


        
On Fri, Jan 22, 2016 at 6:29 PM, Nat
          Sakimura <sakimura@gmail.com>
          wrote:

          

            
I wrote a blog on why the current mix-up
              draft approach does not solve the issue. 
              


              

              
              


              

              
Hopefully, the point I am making is clearer by this. 

              


              

              
Best, 

              


              

              
Nat

            

            

            

              
2016年1月23日(土) 8:32 Mike Jones <Michael.Jones@microsoft.com>:

              

              

                

                  

                    

                      

                        
I
                            like the “from which the
                          authorization server's configuration
                          information location can be derivedâ€
                            language.  Thanks.  I’ll plan to incorporate
                            that the next time the draft is revised.

                        
 

                        
                                                               
                            -- Mike

                        
 

                        
From:
                            Brian Campbell [mailto:bcampbell@pingidentity.com]
                            

                            Sent: Friday, January 22, 2016 3:26
                            PM

                            To: Nat Sakimura <sakimura@gmail.com>

                            Cc: Mike Jones <Michael.Jones@microsoft.com>;
                            Justin Richer <jricher@mit.edu>;
                            <oauth@ietf.org>
                            <oauth@ietf.org>

                      

                    

                    

                      

                        


                            Subject: Re: [OAUTH-WG] Call for
                            Adoption

                      

                    

                    

                      

                        
 

                        

                          
I agree that
                            the language describing OAuth issuer could
                            and should be improved. The text now reads
                            like it is the exact and full URL where the
                            metadata/discovery document is located.
                            Perhaps something more like "the URL from
                            which the authorization server's
                            configuration information location can be
                            derived" and explain that adding the
                            .well-known bits to the issuer is where the
                            configuration information can actually be
                            found.

                            

                          

                        

                        

                          
 

                          

                            
On Thu, Jan 21, 2016 at
                              7:07 PM, Nat Sakimura <sakimura@gmail.com>
                              wrote:

                            

                              

                                
Re: iss. I
                                  discussed this a bit with Nov in more
                                  details. It probably is a sloppy
                                  language of the specs that is making
                                  it difficult to read what you wanted
                                  to achieve. 

                                

                                  
 

                                

                                

                                  
In
                                      mix-up-mitigation draft, OAuth
                                      issuer is "the URL of the
                                      authorization server's
                                      configuration information
                                      location". In OAuth discovery
                                      draft, there is something called
                                      "OAuth 2.0 Configuration
                                      Information Location URL", which
                                      is equal to "OpenID Connect
                                      Issuer". 

                                  
When
                                      I wrote the statement, I thought
                                      you were pointing to the URL that
                                      you can actually pull the
                                      configuration information by "the
                                      URL of the authorizaiton server's
                                      configuration information
                                      location" since otherwise you
                                      would have used the term "OAuth
                                      2.0 Configuration Information
                                      Location URL". But after all, you
                                      probably meant these two are the
                                      same. Then I would strongly
                                      recommend to fix the language. 

                                  
Now,
                                      even If that is the case, the
                                      relationship like 

                                  

                                    ·        
                                        iss
                                      + .well-know/openid-configuration
                                      = Connect OP config endoint

                                  

                                    ·        
                                        OAuth
                                      config endpoint -
                                      .well-known/openid-configuration =
                                      OAuth iss

                                  

                                    
is
                                        very confusing. 

                                  

                                

                                

                                  
 

                                

                                

                                  
You
                                      also claim that your approach is
                                      simpler, but to me, your approach
                                      seem to be overly complex. It
                                      requires discovery and the check
                                      for the value of the discovered
                                      config information to work as the
                                      mitigation. (Right. Draft -01 does
                                      not have it, so it does not solve
                                      the mix-up issue.) With
                                      oauth-meta, you do not need it. 

                                

                                

                                  
 

                                

                                

                                  
Finally,
                                      your point that HATEOAS reminds
                                      you of WSDL, it is not. If you
                                      want to have something similar to
                                      WSDL in REST API area, it is
                                      Swagger. (Actually, it is gaining
                                      a lot of momentum recently, but
                                      that's beside the fact ;-). And
                                      the point here is not the format
                                      but the fact that we need to have
                                      a way to associate metadata to the
                                      data. The root cause of this
                                      mix-up attack is that the metadata
                                      and data is not associated
                                      properly. We have a standard way
                                      of associating the data and
                                      metadata with link-rel such as
                                      RFC5988 so why not use it?
                                      Link-rel-href pattern is used a
                                      lot now. Most modern web pages
                                      actually have it. Using a proper
                                      way to associate metadata with
                                      data will save you from a lot of
                                      other attacks in the future.
                                      Instead of doing patch works, we
                                      should solve it architecturally. 

                                

                                

                                  
 

                                

                                

                                  
Nat

                                

                                

                                  
 

                                

                                

                                  
 

                                

                              

                              
 

                              

                                

                                  
2016年1月22日(金)
                                    10:34 Mike Jones <Michael.Jones@microsoft.com>:

                                

                                

                                  

                                    

                                      

                                        

                                          
Nat,
                                              I’m confused by this
                                              statement in the message
                                              you reference “Unfortunately, this does not match
                                              the value of OAuth issuer
                                              defined in Section 2
                                              of draft-jones-oauth-mix-up-mitigation-01
                                              nor the 'iss' returned as
                                              specified in 3.1. As such,
                                              validation as specified in
                                              bullet 1 of Section 4
                                              fails in Google's case --
                                              OR it means that the
                                              document is internally
                                              inconsistent.â€. 
                                              The issuer definition in
                                              draft-jones-oauth-discovery
                                              is 100% compatible with
                                              the one in OpenID Connect
                                              Discovery, by design.  In
                                              the Google example, both
                                              the OpenID issuer and the
                                              OAuth issuer values would
                                              be the string “https://accounts.google.comâ€. 
                                              What is the inconsistency
                                              that you perceive?

                                          
 

                                          
The
                                              discussion of the
                                              duplication problem
                                              happened in the private
                                              meetings in Yokohama.

                                          
 

                                          
I
                                              will admit, in Yokohama, I
                                              didn’t speak up in the
                                              public meetings to point
                                              out that a simpler
                                              alternative to oauth-meta
                                              was already being
                                              discussed there in
                                              private, because then I
                                              would have had to talk
                                              about the security issues,
                                              which we’d decided not to
                                              publicly do at that
                                              point.  So I stayed silent
                                              during the poll, out of
                                              politeness.  Perhaps I
                                              should have found a way to
                                              say something then anyway,
                                              but that’s water under the
                                              bridge now.

                                          
 

                                          
Finally,
                                              for what it’s worth, the
                                              HATEOAS stuff reminds me
                                              far too much of Web
                                              Services Description
                                              Language (WSDL) – part of
                                              the complexity baggage
                                              that helped sink Web
                                              Services.  The use of
                                              “link rel†to define an
                                              interaction vocabulary and
                                              publish endpoints for that
                                              vocabulary seems pretty
                                              baroque and reminiscent of
                                              “microformats†– another
                                              cute “Webby†innovation
                                              that never caught on.  The
                                              industry has pretty much
                                              voted with its feet and is
                                              using JSON for publishing
                                              discovery data structures
                                              – not “link relâ€.  I am
                                              against us reverting to
                                              the “link rel†proposal
                                              from 2008 that never
                                              caught on when JSON is
                                              simpler and does a better
                                              job.

                                          
 

                                          
                                                               
                                              -- Mike

                                          
 

                                          
From: Nat
                                              Sakimura [mailto:sakimura@gmail.com]
                                              

                                              Sent: Thursday,
                                              January 21, 2016 6:24 AM

                                              To: Justin Richer
                                              <jricher@mit.edu>;
                                              Mike Jones <Michael.Jones@microsoft.com>

                                              Cc: William Denniss
                                              <wdenniss@google.com>;
                                              <oauth@ietf.org>
                                              <oauth@ietf.org>

                                        

                                      

                                      

                                        

                                          


                                              Subject: Re:
                                              [OAUTH-WG] Call for
                                              Adoption

                                        

                                      

                                      

                                        

                                          
 

                                          

                                            
Mike, 

                                            

                                              
 

                                            

                                            

                                              
You
                                                just criticize my draft.
                                                That's ok, but I would
                                                really like to get some
                                                response to my questions
                                                stated in https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html .

                                                To me, it just does not
                                                seem to work, and the
                                                combination of the
                                                oauth-meta and PKCE
                                                seems to be much more
                                                elegan, nicer, and much
                                                simpler to implement. If
                                                you just give up the
                                                dynamic response at the
                                                authorization endpoint,
                                                then you even do not
                                                have to touch the code
                                                but just change a config
                                                file. 

                                            

                                            

                                              
 

                                            

                                            

                                              
Please
                                                convince me by answering
                                                to my questions. 

                                            

                                            

                                              
 

                                            

                                            

                                              
For
                                                the record of Yokohama,
                                                I do not recall much
                                                about duplication in
                                                OAuth session. The poll
                                                in the room was 19
                                                  for / zero against / 4
                                                  persons need more
                                                  information. Indeed,
                                                  it is not duplicating
                                                  much. And if you move
                                                  to a new model without
                                                  pre-configured
                                                  discovery, it is not
                                                  duplicating any but
                                                  the resource endpoint
                                                  URI, which is optional
                                                  and is for the cases
                                                  where the client did
                                                  not know the concrete
                                                  resource endpoint to
                                                  start with. 

                                            

                                            

                                              
 

                                            

                                            

                                              
I understand your usecases always
                                                  start from a concrete
                                                  endpoint location.
                                                  Mine do not. In a four
                                                  party model, it is
                                                  likely not. The user
                                                  just want to have the
                                                  service to fetch his
                                                  data from some
                                                  resource endpoint. He
                                                  just hits the service.
                                                  He does not hit the
                                                  resource endpoint
                                                  directly. For example,
                                                  in the case of a
                                                  consumer using a
                                                  personal finance
                                                  platform (PFP)to
                                                  manage his pension
                                                  fund, he hits the PFP
                                                  and not the Pension
                                                  fund. Assuming that
                                                  the pension fund has
                                                  delegated the
                                                  authorization control
                                                  to the authorization
                                                  server, then, the
                                                  authorization server
                                                  should return both the
                                                  access token and the
                                                  endpoint of the
                                                  pension fund so that
                                                  the PFP can pull the
                                                  data using them. A
                                                  similar model holds
                                                  for personal health
                                                  service and health
                                                  care providers. 

                                            

                                            

                                              
 

                                            

                                            

                                              
Best, 

                                            

                                            

                                              
 

                                            

                                            

                                              
Nat

                                            

                                            

                                              
 

                                            

                                          

                                          
 

                                          

                                            

                                              
2016年1月21日(木) 21:18 Justin Richer <jricher@mit.edu>:

                                            

                                            

                                              

                                                
Convergence
                                                  is exactly what I’m
                                                  arguing for, though.
                                                  These things ought to
                                                  work together.

                                              

                                              

                                                

                                                  
 

                                                

                                                

                                                  
 —
                                                    Justin

                                                

                                              

                                              

                                                

                                                  
 

                                                  

                                                    

                                                      

                                                        
On
                                                          Jan 21, 2016,
                                                          at 2:55 AM,
                                                          Mike Jones
                                                          <Michael.Jones@microsoft.com>
                                                          wrote:

                                                      

                                                      
 

                                                      

                                                        

                                                          

                                                          
My
                                                          memory of the
                                                          discussions of
                                                          the oauth-meta
                                                          draft in
                                                          Yokohama were
                                                          that many
                                                          people felt
                                                          that it was
                                                          unnecessarily
                                                          dynamically
                                                          duplicating a
                                                          lot of
                                                          information
                                                          that the
                                                          client already
                                                          had.  Most of
                                                          us that were
                                                          aware of the
                                                          attacks then
                                                          were in favor
                                                          of a more
                                                          targeted,
                                                          minimal
                                                          approach.  You
                                                          were listened
                                                          to in
                                                          Yokohama, but
                                                          that didn’t
                                                          necessarily
                                                          mean that
                                                          people agreed
                                                          with the
                                                          approach. 
                                                          Participants
                                                          were already
                                                          aware of the
                                                          oauth-meta
                                                          proposal in
                                                          Darmstadt but
                                                          no one spoke
                                                          up in favor of
                                                          it that I can
                                                          recall. 
                                                          Rather, I
                                                          think people
                                                          were thinking
                                                          that “less is
                                                          moreâ€.

                                                          
 

                                                          
There
                                                          have also been
                                                          discussions in
                                                          the last day
                                                          about how
                                                          dynamically
                                                          returning a
                                                          resource URL,
                                                          which
                                                          oauth-meta
                                                          does, is both
                                                          unnecessary
                                                          (since the
                                                          client
                                                          initiated the
                                                          resource
                                                          authorization
                                                          already
                                                          knowing what
                                                          resource it
                                                          wants to
                                                          access) and
                                                          often
                                                          problematic,
                                                          since many
                                                          authorization
                                                          servers can
                                                          authorize
                                                          access to
                                                          multiple
                                                          resources.  If
                                                          anything, the
                                                          client should
                                                          be telling the
                                                          authorization
                                                          server what
                                                          resource it
                                                          wants to
                                                          access – not
                                                          the other way
                                                          around.

                                                          
 

                                                          
I’m
                                                          not saying
                                                          that there
                                                          aren’t some
                                                          good ideas in
                                                          the oauth-meta
                                                          draft – I’m
                                                          sure there
                                                          are, just as
                                                          there are in
                                                          the approach
                                                          designed by
                                                          the
                                                          participants
                                                          in Darmstadt. 
                                                          While I
                                                          volunteered to
                                                          write the
                                                          first draft of
                                                          the
                                                          mix-up-mitigation
                                                          approach, it
                                                          really
                                                          reflects
                                                          something a
                                                          lot of people
                                                          have already
                                                          bought into –
                                                          as evidenced
                                                          in the passion
                                                          in the
                                                          high-volume
                                                          “Mix-Up About
                                                          The Mix-Up
                                                          Mitigationâ€
                                                          thread, and
                                                          not just my
                                                          personal
                                                          project.

                                                          
 

                                                          
If
                                                          you think
                                                          there are
                                                          things missing
                                                          or wrong in
                                                          the
                                                          mix-up-mitigation
                                                          draft, please
                                                          say what they
                                                          are.  That
                                                          will help us
                                                          quickly
                                                          converge on a
                                                          solution that
                                                          will work for
                                                          everyone.

                                                          
 

                                                          
                                                         
                                                          Sincerely,

                                                          
                                                         
                                                          -- Mike

                                                          
 

                                                          
From: Nat
                                                          Sakimura [mailto:sakimura@gmail.com]
                                                          

                                                          Sent:
                                                          Wednesday,
                                                          January 20,
                                                          2016 11:17 PM

                                                          To:
                                                          Mike Jones
                                                          <Michael.Jones@microsoft.com>;
                                                          William
                                                          Denniss <wdenniss@google.com>;
                                                          Justin Richer
                                                          <jricher@mit.edu>

                                                          Cc: oauth@ietf.org

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          Call for
                                                          Adoption

                                                          
 

                                                          

                                                          
Hi
                                                          Mike. 

                                                          

                                                          
 

                                                          

                                                          

                                                          
Conversely,
                                                          I would like
                                                          to ask why
                                                          this approach
                                                          does not work
                                                          for Mix-up
                                                          attack. As Nov
                                                          stated, we in
                                                          fact have
                                                          discussed the
                                                          approach in
                                                          quite a length
                                                          back in
                                                          Yokohama. I
                                                          really would
                                                          like to know
                                                          why it does
                                                          not work. 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
Besides,
                                                          for oauth-meta
                                                          approach,
                                                          mix-up attack
                                                          is only one of
                                                          the thing it
                                                          solves. 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
Nat
                                                          Sakimura

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
2016年1月21日(木) 16:02 Mike Jones <Michael.Jones@microsoft.com>:

                                                          

                                                          

                                                          

                                                          

                                                          
Not
                                                          to be
                                                          negative, but
                                                          I disagree
                                                          with adopting
                                                          draft-sakimura-oauth-meta. 
                                                          We should
                                                          define and
                                                          promote one
                                                          mitigation
                                                          approach to
                                                          the mix-up
                                                          attacks. 
                                                          Having two
                                                          would confuse
                                                          implementers
                                                          and cause
                                                          compatibility
                                                          problems –
                                                          reducing
                                                          overall
                                                          security.

                                                          
 

                                                          
The
                                                          approach
                                                          defined in
                                                          draft-jones-oauth-mix-up-mitigation
                                                          was created in
                                                          collaboration
                                                          with the
                                                          security
                                                          researchers
                                                          who identified
                                                          the problems
                                                          in the first
                                                          place, was
                                                          vigorously
                                                          discussed in
                                                          the security
                                                          meeting Hannes
                                                          and Torsten
                                                          held in
                                                          Darmstadt, and
                                                          has been since
                                                          refined based
                                                          on substantial
                                                          input from the
                                                          working
                                                          group.  And at
                                                          least three
                                                          implementers
                                                          have already
                                                          stated that
                                                          they’ve
                                                          implemented
                                                          it.  I’m not
                                                          saying that
                                                          it’s, but if
                                                          there are
                                                          things missing
                                                          or things that
                                                          need to be
                                                          improved in
                                                          our approach,
                                                          we should do
                                                          it there,
                                                          rather
                                                          introducing a
                                                          competing
                                                          approach.

                                                          
 

                                                          
Also,
                                                          standard OAuth
                                                          deployments
                                                          register the
                                                          client and
                                                          then use the
                                                          information
                                                          gathered at
                                                          registration
                                                          time for
                                                          subsequent
                                                          protocol
                                                          interactions. 
                                                          They do not
                                                          need all the
                                                          configuration
                                                          information
                                                          for the
                                                          authorization
                                                          server to be
                                                          retransmitted
                                                          at runtime. 
                                                          The oauth-meta
                                                          draft goes too
                                                          far in that
                                                          direction, at
                                                          least as I see
                                                          it.  Returning
                                                          things two
                                                          ways creates
                                                          its own
                                                          problems, as
                                                          discussed in
                                                          the Duplicate
                                                          Information
                                                          Attacks
                                                          security
                                                          considerations
                                                          section (7.2)
                                                          of the
                                                          mix-up-mitigation
                                                          draft.

                                                          
 

                                                          
I’ll
                                                          note that the
                                                          mix-up-mitigation
                                                          approach is
                                                          compatible
                                                          with existing
                                                          practice in
                                                          both static
                                                          and dynamic
                                                          metadata
                                                          discovery. 
                                                          Replying to
                                                          Justin’s
                                                          comment that “It's
                                                          the
                                                          pre-configured
                                                          discovery
                                                          document
                                                          that's at the
                                                          root of the
                                                          mix-up attack
                                                          in the first
                                                          placeâ€
                                                          – this is not
                                                          the case.  The
                                                          attacks can be
                                                          performed
                                                          without either
                                                          discovery or
                                                          dynamic
                                                          registration.

                                                          
 

                                                          
I
                                                          would be
                                                          interested in
                                                          hearing a
                                                          technical
                                                          discussion on
                                                          whether there
                                                          are aspects of
                                                          the oauth-meta
                                                          approach that
                                                          mitigate
                                                          aspects of the
                                                          attacks that
                                                          the
                                                          mix-up-mitigation
                                                          approach does
                                                          not.  That
                                                          could help
                                                          inform whether
                                                          there are
                                                          additional
                                                          things we
                                                          should add to
                                                          or change in
                                                          the mix-up
                                                          draft.

                                                          
 

                                                          
                                                         
                                                          -- Mike

                                                          
 

                                                          
From:
                                                          OAuth [mailto:oauth-bounces@ietf.org]
                                                          On Behalf
                                                          Of William
                                                          Denniss

                                                          Sent:
                                                          Wednesday,
                                                          January 20,
                                                          2016 10:37 PM

                                                          To:
                                                          Justin Richer
                                                          <jricher@mit.edu>

                                                          Cc: oauth@ietf.org

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          Call for
                                                          Adoption

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          
+1
                                                          to adopt this,
                                                          and I agree
                                                          with Justin's
                                                          comments.

                                                          

                                                          
 

                                                          

                                                          
On
                                                          Wed, Jan 20,
                                                          2016 at 9:53
                                                          PM, Justin
                                                          Richer <jricher@mit.edu>
                                                          wrote:

                                                          

                                                          

                                                          
+1

                                                          

                                                          Inline
                                                          discovery and
                                                          pre-configured
                                                          discovery (ie,
                                                          .well-known)
                                                          should at the
                                                          very least be
                                                          compatible and
                                                          developed
                                                          together. It's
                                                          the
                                                          pre-configured
                                                          discovery
                                                          document
                                                          that's at the
                                                          root of the
                                                          mix-up attack
                                                          in the first
                                                          place.

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          
 

                                                          

                                                          
On
                                                          1/19/2016
                                                          10:30 PM, Nat
                                                          Sakimura
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Just
                                                          to give more
                                                          context, at
                                                          IETF 94, I
                                                          have done a
                                                          presentation
                                                          on discovery. 
                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
According
                                                          to the
                                                          minutes, 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
    (f) Discovery (Nat)

                                                          
          

                                                          
             Nat explains his document as an example of the work that has to be done

                                                          
             in the area of discovery, which is a topic that has been identified

                                                          
             as necessary for interoperability since many years but so far there

                                                          
             was not time to work on it. Mike, John and Nat are working on a new

                                                          
             document that describes additional discovery-relevant components.

                                                          
          

                                                          
             Poll: 19 for / zero against / 4 persons need more information.

                                                          
 

                                                          
The
                                                          document
                                                          discussed
                                                          there was
                                                          
https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
                                                          simple (only
                                                          1-page!) but a
                                                          very powerful
                                                          document that
                                                          nudges towards
                                                          HATEOAS which
                                                          is at the core
                                                          of
                                                          RESTful-ness.
                                                          It also
                                                          mitigates the
                                                          Mix-up attack
                                                          without
                                                          introducing
                                                          the concept of
                                                          issuer which
                                                          is not in
                                                          RFC6749. It is
                                                          also good for
                                                          selecting
                                                          different
                                                          endpoints
                                                          depending on
                                                          the user
                                                          authentication
                                                          and
                                                          authorization
                                                          results and
                                                          more privacy
                                                          sensitive than
                                                          pre-announced
                                                          Discovery
                                                          document. It
                                                          also allows
                                                          you to find to
                                                          which
                                                          protected
                                                          resource
                                                          endpoint you
                                                          can use the
                                                          access token
                                                          against. 

                                                          

                                                          

                                                          
 

                                                          

                                                          
In
                                                          the last
                                                          sentence of
                                                          the minutes,
                                                          it talks about
                                                          "a new
                                                          document that
                                                          describes
                                                          additional
                                                          discovery-relevant
                                                          components".
                                                          This is https://tools.ietf.org/html/draft-jones-oauth-discovery-00. 

                                                          It went for
                                                          the call for
                                                          adoption.
                                                          However, it is
                                                          only a half of
                                                          the story. I
                                                          believe https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that
                                                          was discussed
                                                          at IETF 94 and
                                                          had support
                                                          there should
                                                          be adopted as
                                                          well.  

                                                          

                                                          
 

                                                          

                                                          

                                                          
Nat
                                                          Sakimura

                                                          

                                                          
 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
2016年1月20日(水) 12:05 Nat Sakimura <sakimura@gmail.com>:

                                                          

                                                          

                                                          

                                                          
Thanks
                                                          Hannes. 
                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
I
                                                          did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which
                                                          was discussed
                                                          in Yokohama,
                                                          and was
                                                          largely in
                                                          agreement if
                                                          my
                                                          recollection
                                                          is correct.
                                                          Why is it not
                                                          in the call
                                                          for adoption? 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
2016å¹´1月19æ—¥(ç«) 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:

                                                          

                                                          

                                                          

                                                          

                                                          
Hi
                                                          all,

                                                          

                                                          we have
                                                          submitted our
                                                          new charter to
                                                          the IESG (see

                                                          http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html)
                                                          and

                                                          since some
                                                          IESG members
                                                          like to see an
                                                          updated list
                                                          of milestones
                                                          as

                                                          well. For this
                                                          reason, based
                                                          on a
                                                          suggestion
                                                          from Barry, we
                                                          are also

                                                          starting a
                                                          call for
                                                          adoption
                                                          concurrently
                                                          with the
                                                          review of the
                                                          charter

                                                          text by the
                                                          IESG.

                                                          

                                                          We will post
                                                          separate mails
                                                          on the
                                                          individual
                                                          documents.
                                                          Your feedback

                                                          is important!
                                                          Please take
                                                          the time to
                                                          look at the
                                                          documents and
                                                          provide

                                                          your feedback.

                                                          

                                                          Ciao

                                                          Hannes &
                                                          Derek

                                                          

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          
_______________________________________________

                                                          
OAuth mailing list

                                                          
OAuth@ietf.org

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

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          


_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          
_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          

                                                          

                                                          

                                                        

                                                      

                                                    

                                                  

                                                  
 

                                                

                                              

                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                              


_______________________________________________

                                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


    

    

  


--------------020804070802010500000102--


From nobody Tue Jan 26 09:18:26 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C261A906F for ; Tue, 26 Jan 2016 09:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuSqOFM1zVRc for ; Tue, 26 Jan 2016 09:18:19 -0800 (PST)
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 679371A9073 for ; Tue, 26 Jan 2016 09:18:18 -0800 (PST)
Received: by mail-qk0-x22e.google.com with SMTP id x1so65517532qkc.1 for ; Tue, 26 Jan 2016 09:18:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=6Bch92s6W9RoVpebOphox6LqQunuGcvvAUMzRAwFi+c=; b=e/nLcj3GLn+8WwbBwQe0HMpaGo1Wm21yBntoMf0xy3S2a//a3rj8nttHZc+Ewe/EiX SfphQxgOm4CHzDDUK08K1VLxIz3xco7f7WSot4N2tjLKrge1vVYkQtD2G4AOQPqhd1pg +1+2f3WkBvdx5t7T+5H6sCONSMlz5StQb4WAeOYMhaKQDIEvzH13/PYJYCHFGl5TZij5 CYNJT7pXx9ZgvS0Haj5L2EPSt3XrmsMxfFvK7qWVSrXUaet1ibGt2jlZcAf9AxAvlnpB iVys3ypywSQ4aqe3p6y0KbJmK9FAfNPlthQAO82A8RNnadN82rEQWzS59S0Qew7/ZVOX uGIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=6Bch92s6W9RoVpebOphox6LqQunuGcvvAUMzRAwFi+c=; b=HDzUeJVjMq8s0D064g+el0B7ct8pRgYPq35M6seU3ZcO4X9WAuFVJ3XrDgwcvS19Ay j4vFMcc/ldbsYKFdZwoccI5IpVklT2ca8QoZik+ldxB2KjBIjIO534QMWRZUT7AUffh7 D3jOuTAcXe51Rb8/Vq7Kb4/9Lpx4oB18D/VWThH/SaXoWWiH/dtmWDwsGbhBLvVCbXwi hoIEdV/61md3sbJwin6RXKDbTxN6+RRV+cG/jiQuQmoxmK/sPcGW8pdi6r/TzVumGKhT BWy/MMs7A3AukkMKI6gPXjTgPoq4nikPjoD+VwTIt0bVta5yT1n3RqQm9gOysVrG2QLC v4cQ==
X-Gm-Message-State: AG10YOQzwPXG5TZZ/Th1avJ1UljYuKw2b1wcHZA+TAWmhEJwsMCxgP1E/ZXq9A9j/AavTQ==
X-Received: by 10.55.19.129 with SMTP id 1mr4718707qkt.51.1453828697959; Tue, 26 Jan 2016 09:18:17 -0800 (PST)
Received: from [192.168.8.100] ([181.202.129.132]) by smtp.gmail.com with ESMTPSA id s130sm881108qhb.6.2016.01.26.09.18.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jan 2016 09:18:17 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_7A580B9D-6A2A-4EB5-8A0C-F9342FF13A67"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com>
Date: Tue, 26 Jan 2016 14:18:13 -0300
Message-Id: <63914724-175F-47EA-BC48-5FB9E6C5FE87@ve7jtb.com>
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com>  <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com> <73E18F37-C765-4F62-A690-102D0C794C52@oracle.com> <845FCC92-E0A5-413F-BA4E-53E0D4C4DBD4@gmail.com> <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com>
To: "Phil Hunt (IDM)" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 17:18:23 -0000

--Apple-Mail=_7A580B9D-6A2A-4EB5-8A0C-F9342FF13A67
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_21E5F9A8-7802-4B73-A6B3-D1F6ADD002E6"


--Apple-Mail=_21E5F9A8-7802-4B73-A6B3-D1F6ADD002E6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Nov,

Are you referring to Sec 3.1.2.1 of RFC 6749.

Stating that the the redirection endpoint SHOULD require TLS, and that =
the AS should warn the user if the redirect URI is not over TLS =
(Something I have never seen done in the real world)

Not using TLS is reasonable when the redirect URI is using a custom =
scheme for native apps.

It might almost be reasonable for the token flow where the JS page =
itself is not loaded over TLS so the callback to extract the fragment =
would not be as well.=20
Note that the token itself is never passed over a non https connection =
in tis case.
I would argue now that it is irresponsible to have a non TLS protected =
site, but not everyone is going to go along with that. =20

Using a http scheme URI for the redirect is allowed but is really =
stupid.   We did have a large debate about this when profiling OAuth for =
Connect.
We did tighten connect to say that if you are using the code flow then a =
http scheme redirect URI is only allowed if the client is confidential.=20=


John B.
> On Jan 26, 2016, at 1:14 AM, Phil Hunt (IDM)  =
wrote:
>=20
> Still don't see it. Though i think the diagram is wrong (the rp should =
redirct to the ua and not call the authz direct), the IDP should either =
return an error or redirect the RP to TLS.=20
>=20
> I don't see this as proper oauth protocol since the RP is MITM the UA =
rather than acting as a client.=20
>=20
> Phil
>=20
> On Jan 25, 2016, at 19:57, nov matake > wrote:
>=20
>> =10In this flow, AuthZ endpoint is forced to be TLS-protected.
>> =
http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png =

>>=20
>> However, RP=E2=80=99s redirect response which causes following AuthZ =
request is still not TLS-protected, and modified on the attacker=E2=80=99s=
 proxy.
>>=20
>> Section 3.2 of this report also describes the same flow.
>> http://arxiv.org/pdf/1601.01229v2.pdf =

>>=20
>>> On Jan 26, 2016, at 12:37, Phil Hunt (IDM) > wrote:
>>>=20
>>> Also the authz endpoint is required to force tls. So if the client =
doesn't do it the authz should reject (eg by upgrading to tls).=20
>>>=20
>>> Phil
>>>=20
>>> On Jan 25, 2016, at 19:29, Phil Hunt (IDM) > wrote:
>>>=20
>>>> When the RP acting as the client issues a authorize redirect to the =
UA it has to make it with TLS
>>>>=20
>>>> Phil
>>>>=20
>>>> On Jan 25, 2016, at 17:53, Nov Matake > wrote:
>>>>=20
>>>>> It doen't say anything about the first request which initiate the =
login flow.
>>>>> It is still a reasonable assumption that RP puts a "login with FB" =
button on a non TLS-protected page.
>>>>>=20
>>>>> nov
>>>>>=20
>>>>> On Jan 26, 2016, at 10:45, Phil Hunt > wrote:
>>>>>=20
>>>>>> I would find it hard to believe that is true.
>>>>>>=20
>>>>>> =46rom 6749 Sec 3.1=20
>>>>>>    Since requests to the authorization endpoint result in user
>>>>>>    authentication and the transmission of clear-text credentials =
(in the
>>>>>>    HTTP response), the authorization server MUST require the use =
of TLS
>>>>>>    as described in Section 1.6 =
 when sending requests =
to the
>>>>>>    authorization endpoint.
>>>>>>=20
>>>>>> Sec 3.1.2.1=20
>>>>>>    The redirection endpoint SHOULD require the use of TLS as =
described
>>>>>>    in Section 1.6 =
 when the requested =
response type is "code" or "token",
>>>>>>    or when the redirection request will result in the =
transmission of
>>>>>>    sensitive credentials over an open network.  This =
specification does
>>>>>>    not mandate the use of TLS because at the time of this =
writing,
>>>>>>    requiring clients to deploy TLS is a significant hurdle for =
many
>>>>>>    client developers.  If TLS is not available, the authorization =
server
>>>>>>    SHOULD warn the resource owner about the insecure endpoint =
prior to
>>>>>>    redirection (e.g., display a message during the authorization
>>>>>>    request).
>>>>>>=20
>>>>>>    Lack of transport-layer security can have a severe impact on =
the
>>>>>>    security of the client and the protected resources it is =
authorized
>>>>>>    to access.  The use of transport-layer security is =
particularly
>>>>>>    critical when the authorization process is used as a form of
>>>>>>    delegated end-user authentication by the client (e.g., =
third-party
>>>>>>    sign-in service).
>>>>>>=20
>>>>>> Section 10.5 talks about transmission of authorization codes in =
connection with redirects.
>>>>>>=20
>>>>>> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of =
authz codes.
>>>>>>=20
>>>>>>=20
>>>>>> Phil
>>>>>>=20
>>>>>> @independentid
>>>>>> www.independentid.com =
phil.hunt@oracle.com =

>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> On Jan 25, 2016, at 4:52 PM, nov matake > wrote:
>>>>>>>=20
>>>>>>> The first assumption is coming from the original security report =
at http://arxiv.org/abs/1601.01229 .
>>>>>>> RFC 6749 requires TLS between RS and AS, and also between UA and =
AS, but not between UA and RS.
>>>>>>>=20
>>>>>>> The blog post is based on my Japanese post, and it describes =
multi-AS case.
>>>>>>> Nat's another post describes the case which can affect single-AS =
case too.
>>>>>>> =
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc67=
49/ =

>>>>>>>=20
>>>>>>> nov
>>>>>>>=20
>>>>>>>> On Jan 26, 2016, at 08:22, Phil Hunt > wrote:
>>>>>>>>=20
>>>>>>>> Sorry, meant to reply-all.
>>>>>>>>=20
>>>>>>>> Phil
>>>>>>>>=20
>>>>>>>> @independentid
>>>>>>>> www.independentid.com =
phil.hunt@oracle.com =

>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>> Begin forwarded message:
>>>>>>>>>=20
>>>>>>>>> From: Phil Hunt >
>>>>>>>>> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up =
Mitigation
>>>>>>>>> Date: January 25, 2016 at 3:20:19 PM PST
>>>>>>>>> To: Nat Sakimura >
>>>>>>>>>=20
>>>>>>>>> I am having trouble with the very first assumption. The =
user-agent sets up a non TLS protected connection to the RP? That=E2=80=99=
s a fundamental violation of 6749.
>>>>>>>>>=20
>>>>>>>>> Also, the second statement says the RP (assuming it acts as =
OAuth client) is talking to two IDPs.  That=E2=80=99s still a multi-AS =
case is it not?
>>>>>>>>>=20
>>>>>>>>> Phil
>>>>>>>>>=20
>>>>>>>>> @independentid
>>>>>>>>> www.independentid.com =
phil.hunt@oracle.com =

>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>>> On Jan 25, 2016, at 2:58 PM, Nat Sakimura > wrote:
>>>>>>>>>>=20
>>>>>>>>>> Hi Phil,=20
>>>>>>>>>>=20
>>>>>>>>>> Since I was not in Darmstadt, I really do not know what was =
discussed there, but with the compromised developer documentation =
described in =
http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/ =
, =
all RFC6749 clients with a naive implementer will be affected. The =
client does not need to be talking to multiple IdPs.=20
>>>>>>>>>>=20
>>>>>>>>>> Nat
>>>>>>>>>>=20
>>>>>>>>>> 2016=E5=B9=B41=E6=9C=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt =
(IDM) >:
>>>>>>>>>> I recall making this point in Germany. 99% of existing use is =
fine. OIDC is probably the largest community that *might* have an issue.
>>>>>>>>>>=20
>>>>>>>>>> I recall proposing a new security document that covers oauth =
security for dynamic scenarios. "Dynamic" being broadly defined to mean:
>>>>>>>>>> * clients who have configured at runtime or install time =
(including clients that do discovery)
>>>>>>>>>> * clients that communicate with more than one endpoint
>>>>>>>>>> * clients that are deployed in large volume and may update =
frequently (more discussion of "public" cases)
>>>>>>>>>> * clients that are script based (loaded into browser on the =
fly)
>>>>>>>>>> * others?
>>>>>>>>>>=20
>>>>>>>>>> Phil
>>>>>>>>>>=20
>>>>>>>>>> > On Jan 25, 2016, at 10:39, George Fletcher =
> wrote:
>>>>>>>>>> >
>>>>>>>>>> > would
>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> OAuth mailing list
>>>>>>>>>> OAuth@ietf.org 
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth =

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

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

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


--Apple-Mail=_21E5F9A8-7802-4B73-A6B3-D1F6ADD002E6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Nov,

Are =
you referring to Sec 3.1.2.1 of RFC 6749.

Stating that the the redirection =
endpoint SHOULD require TLS, and that the AS should warn the user if the =
redirect URI is not over TLS (Something I have never seen done in the =
real world)

Not =
using TLS is reasonable when the redirect URI is using a custom scheme =
for native apps.

It might almost be reasonable for the token flow where the JS =
page itself is not loaded over TLS so the callback to extract the =
fragment would not be as well. 
Note that the =
token itself is never passed over a non https connection in tis =
case.
I would argue now that it is irresponsible to =
have a non TLS protected site, but not everyone is going to go along =
with that.  

Using a http scheme URI for the redirect is allowed but is =
really stupid.   We did have a large debate about this when =
profiling OAuth for Connect.
We did tighten connect =
to say that if you are using the code flow then a http scheme redirect =
URI is only allowed if the client is confidential. 

John B.

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

=

--Apple-Mail=_21E5F9A8-7802-4B73-A6B3-D1F6ADD002E6--

--Apple-Mail=_7A580B9D-6A2A-4EB5-8A0C-F9342FF13A67
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjYxNzE4MTRaMCMGCSqGSIb3DQEJBDEWBBT8Sa0b6xj1J4q8B8g91CFj
u3IwBDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCu7UbPlhmWo54pAeRj8l6+lmiYLCWI9Hc0sOsdrRMCQ+FM38X99eHI
luTTsgx1bGhvlTbxLajoDLpaqRA6jKrDPMK6nlKvo5B6dS49CtBvPjQvj8QDUMGHDhCmnmC8CZ1F
bxGniLlNGU6/0WJQo00AiDmT0qMhGcM05HwOHRDZYI5YIGta0OYUnubHXoZu2PexxmcdC8fm+A6c
2RimJo92aLReayBPArrxIf6oHjUmwy1PfqsVGk7P06OOOOn2Ii3aQooE5KXv+Cv3KTPDYuE+vNgp
OxAvmv2JJBC/XZ/OPjBt0K3FXWdvW0sy+7m1Fh74coHMdT7x0sCNfuBPB+0JAAAAAAAA
--Apple-Mail=_7A580B9D-6A2A-4EB5-8A0C-F9342FF13A67--


From nobody Tue Jan 26 10:04:35 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341771AC3AC for ; Tue, 26 Jan 2016 10:04:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uc6ixZ1v5h67 for ; Tue, 26 Jan 2016 10:04:32 -0800 (PST)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8DD1AC3AB for ; Tue, 26 Jan 2016 10:04:31 -0800 (PST)
Received: by mail-wm0-x22e.google.com with SMTP id l65so115106711wmf.1 for ; Tue, 26 Jan 2016 10:04:31 -0800 (PST)
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-type:content-transfer-encoding; bh=YPq09lwfxt66yh71R7lpdX+atCxOjrMZ+yEMrRMCePY=; b=Ov41bZKSWTeWR+Koj/lnaGm9/RKzDI/P8zc+2atWsM4q3i5uqVGeuzE2BotVLm3njb 0WKPFo2obdaCAEZsf74D0+KyxQ2awB2beq7SWvO+7P/aGkOY2ATOWedJsd3hjXDbwI5n gHdGQpbtRjH/lw2Mg7MEHrq5tHT9YbSDx/3hHxc8lX8uOjhs0UgwXb+zWpn5nN5UQe7J j+R4cj3pc8oOdOLioD5yaeBJFf/5kZrI5LdfRnmCjH23vqUaiFlV8F2Tdx2fn8pJmiZj JWsZblSTWkl4gkcscfpFNDV/IfFIc+sJLnxNmML2Fy+Qc9VW2HDuvrUsJr5ll2hYbHWg wsAQ==
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-type :content-transfer-encoding; bh=YPq09lwfxt66yh71R7lpdX+atCxOjrMZ+yEMrRMCePY=; b=e5DOtFtH1EW+tv87LGmha1CFCtRWzMEAVz1AO3UeFeWZWw4DGmNtRr9A9rtp/hrgEJ wAGX4DKna4Jcz8LhCeU13DmALtWOtjGUmybsXopRor7VxMW1dxuQzMGMiR94DehU9HXr DO1UNtN1fPTxEP/v6FE1P92UOSMMllX5hK6GQ9Jz5oCav8BK+UtAJkBXHBYLuoVNJ3fP wZrjWXHE51yssztpQ/tXHQW8weGay9km6x4pJ2qi5uz6PLukA76VCe7ipedjkYbi2P2l 6TgU4EQFYybOYycZfuXuRv6RnMKte55q35pkdStQyngfVZjPGUPqpqKUF6F8DtkMoeIr oymw==
X-Gm-Message-State: AG10YORe9OcBW7NuV/BJd8ZPjEsFfz1UA3LXgevaK0TS6teCTlE6bXY7t4QjcpOFlEVP0g==
X-Received: by 10.194.172.97 with SMTP id bb1mr27911340wjc.173.1453831470337;  Tue, 26 Jan 2016 10:04:30 -0800 (PST)
Received: from [192.168.2.7] ([5.179.70.21]) by smtp.googlemail.com with ESMTPSA id v191sm3949303wme.1.2016.01.26.10.04.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 10:04:29 -0800 (PST)
To: William Denniss 
References: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> <569CDE25.90908@gmail.com>  <569E08F6.4040600@gmail.com>
From: Sergey Beryozkin 
Message-ID: <56A7B52C.2040302@gmail.com>
Date: Tue, 26 Jan 2016 18:04:28 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <569E08F6.4040600@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 18:04:34 -0000

Hi

I'm not sure if the next question is off topic or too low level, 
hopefully not,

When the repeated authorization is skipped or only new scopes are 
requested to be authorized as per the incremented auth approach, is it 
reasonable to assume that the record that is used to track it all is 
actually the existing access token or is totally OIDC implementation 
specific ?
I think using the existing token as a record is reasonable because it is 
time scoped and if we do not use the access token for keeping the track 
of the multiple approvals, etc, then one need to introduce one more 
record mirroring to some extent the access token...

For example, the user session may have expired but the access token that 
was issued to a client web app on behalf of this user is still active, 
so when the user returns and signs in again, and for example, approves 
few more scopes, then the existing access token (the record) gets 
updated, instead of a new token being created.

If it is reasonable then does it mean the sticky or incremental 
authorization works as long as the access token is available 
(refreshable) ?

Sergey




On 19/01/16 09:59, Sergey Beryozkin wrote:
> Hi William
>
> Thanks for the advice. FYI we are also on the way to supporting the
> incremental authorization of scopes - thanks for highlighting the
> importance of this process on this list...
>
> Cheers, Sergey
> On 19/01/16 03:10, William Denniss wrote:
>> Agree with Justin, this is pretty common. We support it for re-auth as
>> well as incremental auth (where the user has already approved scope "a"
>> and is presented with a request for scopes "a b", they will only need to
>> approve scope "b").  In fact if you don't do this, then incremental auth
>> isn't really viable.
>>
>> Regarding security: don't do this for non-confidential clients where you
>> can't verify the identity of the app by the redirect (e.g. a localhost
>> redirect to an installed app).
>>
>> On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin > > wrote:
>>
>>     Hi Justin, thanks for the advice,
>>
>>     Cheers, Sergey
>>
>>     On 18/01/16 11:47, Justin Richer wrote:
>>
>>         Yes, this is common practice. Give the user the option to
>>         remember the
>>         decision. This is known as "trust on first use", or tofu. Our
>>         server,
>>         MITREid Connect, implements this as do many others.
>>
>>
>>
>>         -- Justin
>>
>>         / Sent from my phone /
>>
>>
>>         -------- Original message --------
>>         From: Sergey Beryozkin >         >
>>         Date: 1/18/2016 5:59 AM (GMT-05:00)
>>         To: oauth@ietf.org 
>>         Subject: [OAUTH-WG] Can the repeated authorization of scopes be
>>         avoided ?
>>
>>         Hi All
>>
>>         The question relates to the process of showing the authorization
>>         code/implicit flow consent screen to a user.
>>
>>
>>         I'm discussing with my colleagues the possibility of avoiding
>>         asking the
>>         same user whose session has expired and who is re-authenticating
>>         with AS
>>         which scopes should be approved.
>>
>>         For example, suppose the OAuth2 client redirects a user with the
>>         requested scope 'a'. The user signs in to AS and is shown a
>> consent
>>         screen asking to approve the 'a' scope. The user approves 'a'
>>         and the
>>         flow continues.
>>
>>         Some time later, when the user's session has expired, the user is
>>         redirected to AS with the same 'a' scope.
>>
>>         Would it be a good idea, at this point, not to show the user the
>>         consent
>>         screen asking to approve the 'a' scope again ? For example, AS
>> can
>>         persist the fact that a given user has already approved 'a' for
>>         a given
>>         client earlier, so when the user re-authenticates, AS will use
>>         this info
>>         and will avoid showing the consent screen.
>>
>>         That seems to make sense, but I'm wondering, can there be some
>>         security
>>         implications associated with it, any recommendations/advices
>>         will be welcome
>>
>>         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 Jan 26 10:32:59 2016
Return-Path: <777ilililililililil@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0222C1B2B4A for ; Tue, 26 Jan 2016 10:32:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.26
X-Spam-Level: 
X-Spam-Status: No, score=-1.26 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, FROM_STARTS_WITH_NUMS=0.738, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUbXrzUfl8bD for ; Tue, 26 Jan 2016 10:32:57 -0800 (PST)
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 0DEDC1B2B48 for ; Tue, 26 Jan 2016 10:32:57 -0800 (PST)
Received: by mail-wm0-x22f.google.com with SMTP id n5so145529733wmn.0 for ; Tue, 26 Jan 2016 10:32:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:from:date:message-id:subject:to:content-type; bh=cYUQSb+qQg3xZRnVD3o6eiL2F9hlqf3Y2+/VPdTcvi4=; b=qJptZJEzvH8JBw3DnBQnAZgmtJpt4k23S9oXcElzKaWPLBUh0NHWQtUcbHYxrQSsW1 o/WHCyAHVm4b3s8KR5sRiZOJrOD3NXegQzfZH9+gyRP/IaE8KEzkN4TPcyYO4wehS052 BLmPvAkZxMG+b42FBf61lbcpH5Ty9JqPz+rtJRrZ5OfEBAOW0akRqaqweHCy138JneNq MAxADMCMsxTnWSyV7AT+fASRYqLGrH6QsvY1uWdc4JTkUeO+HNH9SqHXXTNZ7yGXCNAG eL/vKWhAjQ7TNJki9/d9/vq7B1VFafPI1YqJWv2GG07og83vStf2vvWO9x8ZKBR5JIc3 Vlcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=cYUQSb+qQg3xZRnVD3o6eiL2F9hlqf3Y2+/VPdTcvi4=; b=PsWxLgsXOZjkklp1r41syNEUk6fSZFyW9dbCXsDTAx27/+AB+l68K/udUhgh+xDUSo uMn25IjpR61ct9zWRnOQIGMnX4VznxaA4V7nju+GgjJa83CQqU5Ufyp5uei+lqmJyfOi zWSh3vWE4ju8stMYe7Ff7hbKAdmZfweoGgL7xxS05q+mFGAX8+MWyi2fA7rVutoh1CNq VOIz8g4Bcs2LsmIQPETjwk0yB8jwvqqUjPf+Z8lqZ/BHjd6QN/H2Ex2XhFGGX1EPxmVz KexIDr4NUWrCgCQT56n/tjNiBln39quPSBBGtLCCCLTxdCDwBzkhR8t7dfz1iP7DlqPF BBag==
X-Gm-Message-State: AG10YOTtfRMbEmndYIXlas4wcglAo228f4gykTPpH/trqxYaOBVkhz2e2dc3t4uInK/R+i0IM+zc6DHLYWZXhQ==
X-Received: by 10.194.5.193 with SMTP id u1mr24216102wju.166.1453833175563; Tue, 26 Jan 2016 10:32:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.104.212 with HTTP; Tue, 26 Jan 2016 10:32:26 -0800 (PST)
From: Dred J <777ilililililililil@gmail.com>
Date: Wed, 27 Jan 2016 03:32:26 +0900
Message-ID: 
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary=047d7b5d3d84fe048d052a40e9fd
Archived-At: 
Subject: [OAUTH-WG] (no subject)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 18:32:58 -0000

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

 ----------   J Dred from  --------------

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



=C2=A0----------=C2=A0=C2=A0 J Dred from=C2=A0 --------------<=
/div>




--047d7b5d3d84fe048d052a40e9fd--


From nobody Tue Jan 26 10:33:16 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6313D1B2B4E for ; Tue, 26 Jan 2016 10:33:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMwXwH6KX_Ws for ; Tue, 26 Jan 2016 10:33:13 -0800 (PST)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::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 E248E1B2B48 for ; Tue, 26 Jan 2016 10:33:12 -0800 (PST)
Received: by mail-qg0-x230.google.com with SMTP id o11so146016392qge.2 for ; Tue, 26 Jan 2016 10:33:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=2XoQuxz1NBoDaXKbm1HLiVAEtbsofx6ModwPd13mbd4=; b=ngIczr0f+eXikaXDBF1qyR9dmdHv/AkzUxOXo7+F5tfvnojjpapgWLahn9pYx6xc6y FBkcrGJCJHtFrYFu+jjH+xhP5Ka0osPjbOW9znBD+XqMJw+Uc78BV/eY/9+wfC4cQWR8 X+iHZ9xQVrxNJ7ykbe/k3Tob9gi3C/TcgbCkD5BkonGNO4tnB2hklGGg7gnAuor7cFiq q0F+76zBj6Z3pvtZovQDMw2XrF2hBa3wWHCAa3/Nr5LBWUuFQc88lu8Rkh3A1IT7HeBT /hfWwYCp6M/Sw0mUtWiMLoMunuPgQ7CYrrbjBFuPxtxJjHijKWjHzJ7vXJGITu1IrseE pGjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=2XoQuxz1NBoDaXKbm1HLiVAEtbsofx6ModwPd13mbd4=; b=gn3zRBhu7ovHwKnxCS/047GrVihrW6TFSXZSAUZd1s3XOeasEjcHNeNjIF7CCcD1MV a11PSCrEy84HKBJu0mvFBoN/bW8JhcIBWNEcP3FEWnjk9zGy+3VrwVpNgRWXkNy0iF1m XDoDiomqGtIkMgUgNkh/Lg9gR9TV993Ms5S+MZxXOY+LpzZQjuosDD8yRED+abxmGHBH p3rEKGrCJGXYZqEqP+llEx8t+ceWs4BC6be9z+QcbaP6QaR3RNyVmTNn7W78WVYzBLcf HGg8XV5aadFmatpCZYX6FtULwQu+O366rkU0X9JijeYntbQ3UaQ5uFF3Wado7dqC4Uy0 GhWw==
X-Gm-Message-State: AG10YOTZyJ0kkzod+Cki+7nxjBAkzHQOaDiIw6EtabApEnWwa1eUB50xuzGdY/Jlue34uw==
X-Received: by 10.140.91.73 with SMTP id y67mr29802904qgd.42.1453833192004; Tue, 26 Jan 2016 10:33:12 -0800 (PST)
Received: from [192.168.8.100] ([181.202.129.132]) by smtp.gmail.com with ESMTPSA id l107sm1002847qge.22.2016.01.26.10.33.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jan 2016 10:33:10 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_1934DC06-00C7-4E98-9A9F-93DECBBA0CF1"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56A7B52C.2040302@gmail.com>
Date: Tue, 26 Jan 2016 15:33:08 -0300
Message-Id: <2DB022F1-390B-41B1-9416-97D9F10DA129@ve7jtb.com>
References: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> <569CDE25.90908@gmail.com>  <569E08F6.4040600@gmail.com> <56A7B52C.2040302@gmail.com>
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 18:33:15 -0000

--Apple-Mail=_1934DC06-00C7-4E98-9A9F-93DECBBA0CF1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

The grants should be tied to the refresh token, or a grant record tied =
to the confidential client. =20

For native iOS I have seen  people bind it to the client_id if the =
client is not confidential.  That way if the user installs the same app =
on another device it gets the same grants.
I am however not a big fan of that and prefer to keep the grants =
segmented per device.  =20

John B.



> On Jan 26, 2016, at 3:04 PM, Sergey Beryozkin  =
wrote:
>=20
> Hi
>=20
> I'm not sure if the next question is off topic or too low level, =
hopefully not,
>=20
> When the repeated authorization is skipped or only new scopes are =
requested to be authorized as per the incremented auth approach, is it =
reasonable to assume that the record that is used to track it all is =
actually the existing access token or is totally OIDC implementation =
specific ?
> I think using the existing token as a record is reasonable because it =
is time scoped and if we do not use the access token for keeping the =
track of the multiple approvals, etc, then one need to introduce one =
more record mirroring to some extent the access token...
>=20
> For example, the user session may have expired but the access token =
that was issued to a client web app on behalf of this user is still =
active, so when the user returns and signs in again, and for example, =
approves few more scopes, then the existing access token (the record) =
gets updated, instead of a new token being created.
>=20
> If it is reasonable then does it mean the sticky or incremental =
authorization works as long as the access token is available =
(refreshable) ?
>=20
> Sergey
>=20
>=20
>=20
>=20
> On 19/01/16 09:59, Sergey Beryozkin wrote:
>> Hi William
>>=20
>> Thanks for the advice. FYI we are also on the way to supporting the
>> incremental authorization of scopes - thanks for highlighting the
>> importance of this process on this list...
>>=20
>> Cheers, Sergey
>> On 19/01/16 03:10, William Denniss wrote:
>>> Agree with Justin, this is pretty common. We support it for re-auth =
as
>>> well as incremental auth (where the user has already approved scope =
"a"
>>> and is presented with a request for scopes "a b", they will only =
need to
>>> approve scope "b").  In fact if you don't do this, then incremental =
auth
>>> isn't really viable.
>>>=20
>>> Regarding security: don't do this for non-confidential clients where =
you
>>> can't verify the identity of the app by the redirect (e.g. a =
localhost
>>> redirect to an installed app).
>>>=20
>>> On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin =
>> > wrote:
>>>=20
>>>    Hi Justin, thanks for the advice,
>>>=20
>>>    Cheers, Sergey
>>>=20
>>>    On 18/01/16 11:47, Justin Richer wrote:
>>>=20
>>>        Yes, this is common practice. Give the user the option to
>>>        remember the
>>>        decision. This is known as "trust on first use", or tofu. Our
>>>        server,
>>>        MITREid Connect, implements this as do many others.
>>>=20
>>>=20
>>>=20
>>>        -- Justin
>>>=20
>>>        / Sent from my phone /
>>>=20
>>>=20
>>>        -------- Original message --------
>>>        From: Sergey Beryozkin >>        >
>>>        Date: 1/18/2016 5:59 AM (GMT-05:00)
>>>        To: oauth@ietf.org 
>>>        Subject: [OAUTH-WG] Can the repeated authorization of scopes =
be
>>>        avoided ?
>>>=20
>>>        Hi All
>>>=20
>>>        The question relates to the process of showing the =
authorization
>>>        code/implicit flow consent screen to a user.
>>>=20
>>>=20
>>>        I'm discussing with my colleagues the possibility of avoiding
>>>        asking the
>>>        same user whose session has expired and who is =
re-authenticating
>>>        with AS
>>>        which scopes should be approved.
>>>=20
>>>        For example, suppose the OAuth2 client redirects a user with =
the
>>>        requested scope 'a'. The user signs in to AS and is shown a
>>> consent
>>>        screen asking to approve the 'a' scope. The user approves 'a'
>>>        and the
>>>        flow continues.
>>>=20
>>>        Some time later, when the user's session has expired, the =
user is
>>>        redirected to AS with the same 'a' scope.
>>>=20
>>>        Would it be a good idea, at this point, not to show the user =
the
>>>        consent
>>>        screen asking to approve the 'a' scope again ? For example, =
AS
>>> can
>>>        persist the fact that a given user has already approved 'a' =
for
>>>        a given
>>>        client earlier, so when the user re-authenticates, AS will =
use
>>>        this info
>>>        and will avoid showing the consent screen.
>>>=20
>>>        That seems to make sense, but I'm wondering, can there be =
some
>>>        security
>>>        implications associated with it, any recommendations/advices
>>>        will be welcome
>>>=20
>>>        Sergey
>>>=20
>>>        _______________________________________________
>>>        OAuth mailing list
>>>        OAuth@ietf.org 
>>>        https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>>    _______________________________________________
>>>    OAuth mailing list
>>>    OAuth@ietf.org 
>>>    https://www.ietf.org/mailman/listinfo/oauth
>>>=20
>>>=20
>>=20
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_1934DC06-00C7-4E98-9A9F-93DECBBA0CF1
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjYxODMzMDhaMCMGCSqGSIb3DQEJBDEWBBRDkEMvJClfPo+fdykQoZVu
b/flyTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAQ2nGXE58zwbqyBd+iwtLclOV1CW41dppoRIyWg1ecAYoYMmBz5Rtx
0dyEjWHfF7WXxy279lyvHFIK3aCmxC9mmbS+8Z2UnaAlEh1mmCUw/B09KiFWUeX6TKJ/B1dPJlkv
0iizJ+b4F8ewlrWcm5sEt53Egs824NGsYNOsQoBud0tN7NO0dDzfKx5u5lcnOgnqOfQbMv23sUMC
X9XlYm53Kd30EDoftBBauga9nvM25l/efzFrTX1GFRUiexX9CYhJhzxBdMUHvQcGoMrimDR984s5
jYykCwh8YFVuSKzb964ByCv6H9LgOmytJNWcC5CkS3VyEOcOjMi3G3WuwH58AAAAAAAA
--Apple-Mail=_1934DC06-00C7-4E98-9A9F-93DECBBA0CF1--


From nobody Tue Jan 26 10:57:43 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3C31B2B9D for ; Tue, 26 Jan 2016 10:57:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QhrOhIWXkQx for ; Tue, 26 Jan 2016 10:57:38 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 291C61B2B9B for ; Tue, 26 Jan 2016 10:57:38 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id s81so5184043lfd.0 for ; Tue, 26 Jan 2016 10:57:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=1+H5Qs5ZAIfkfL3OplkIwJFcYfCWkXqoCykmc19e/g0=; b=ersICioxBPrZWKbNRtURT/9PP/meWrp5JNUNXbTQGfAdCztz92CaddjR5px2uJHeIK Lo+WIyUvLK6gwNltuSCimaA+CzXrmLTgn9PQrNi/2jiDNIWeNzUwMuYKbpftDHj7yA85 o9nytCud8SYkeYj1K5aU9C4+bGEA+2+to+LNgtX+vlsULb+kWZCanvOfumVlLZpbi/QG AKrCrJ4bvXX9GD2DFAGXgn6Qa5A+8NuoyzdddyIriUwrpq5iB4584KXCczbQG/b1Lw3R cwjCTvaIB6K8WfCeJQJycsMZvEcSX385jJ5PD/g++AsKkIWCn2SJx2hHvVdjIrkvYC7o lpMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=1+H5Qs5ZAIfkfL3OplkIwJFcYfCWkXqoCykmc19e/g0=; b=fGpJLzcPuKkZevjplpfJu0d16rjvK3aOtuG6iGeDFmubuZotFdw8v3pZ4Ro6a7Q67r UBDLI7K4e3yMGSKggQaGw50uzee4jP5tM4H+mBXQcqiWRnNRgHkZq1LTacwjTYP3UJfl PP4a4PcJ13CV6y5BgIA4KnX5kcRNlWhBy/Z++FfHnR5CItyxAopRZEj2VTePqoQL4qTx J7eadRFapDRf9AoWze/K8y2hQ+JBGavggB+RqG4pqq7VM4O8QdtMcOG2xXJ+aNYPRvpS LHuQmVxxXvKwSwD4W6TfRRf4Lo5h6+86XdLrUJUo3VvmdSa4OM/Db4d8FkN+FpjLw6e9 JGiQ==
X-Gm-Message-State: AG10YORCGgN+6IIcVZONTOGrau3LyzYk1u/g0WOCI+SU8edwsLB47n1JZmmMnz06xqQmn9unysYwmzcYg7MGFQ==
X-Received: by 10.25.86.211 with SMTP id k202mr9431583lfb.69.1453834656387; Tue, 26 Jan 2016 10:57:36 -0800 (PST)
MIME-Version: 1.0
References: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> <569CDE25.90908@gmail.com>  <569E08F6.4040600@gmail.com> <56A7B52C.2040302@gmail.com>
In-Reply-To: <56A7B52C.2040302@gmail.com>
From: Thomas Broyer 
Date: Tue, 26 Jan 2016 18:57:26 +0000
Message-ID: 
To: Sergey Beryozkin , William Denniss 
Content-Type: multipart/alternative; boundary=001a1141ef2641983f052a4142d3
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 18:57:42 -0000

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

Fwiw, at Ozwillo, we track grants per user per client_id (we don't support
native apps; only web flows for now), and we don't do "incremental grants"
like Google: if you request scope B and the user had only granted scope A,
you'll get a token for scope B only. This is partly because our tokens are
not for our own APIs only, contrary to Google, so we want to allow clients
to get tokens with narrow scopes so they could have one token per
third-party API and prevent rogue resources from trying to use received
tokens at other APIs.

UI-wise, we tell the user what he already granted to the client, and even
let him grant scopes that the client has pre-registered as "possibly needed
at some time" (through a custom provisioning protocol), but the issued
token is always for the exact scopes that the client requested in this
specific request.
And if all requested scopes have already been granted, then we do a
transparent redirect without showing anything to the user (which is what
most other implementations do too)

Le mar. 26 janv. 2016 19:04, Sergey Beryozkin  a
=C3=A9crit :

> Hi
>
> I'm not sure if the next question is off topic or too low level,
> hopefully not,
>
> When the repeated authorization is skipped or only new scopes are
> requested to be authorized as per the incremented auth approach, is it
> reasonable to assume that the record that is used to track it all is
> actually the existing access token or is totally OIDC implementation
> specific ?
> I think using the existing token as a record is reasonable because it is
> time scoped and if we do not use the access token for keeping the track
> of the multiple approvals, etc, then one need to introduce one more
> record mirroring to some extent the access token...
>
> For example, the user session may have expired but the access token that
> was issued to a client web app on behalf of this user is still active,
> so when the user returns and signs in again, and for example, approves
> few more scopes, then the existing access token (the record) gets
> updated, instead of a new token being created.
>
> If it is reasonable then does it mean the sticky or incremental
> authorization works as long as the access token is available
> (refreshable) ?
>
> Sergey
>
>
>
>
> On 19/01/16 09:59, Sergey Beryozkin wrote:
> > Hi William
> >
> > Thanks for the advice. FYI we are also on the way to supporting the
> > incremental authorization of scopes - thanks for highlighting the
> > importance of this process on this list...
> >
> > Cheers, Sergey
> > On 19/01/16 03:10, William Denniss wrote:
> >> Agree with Justin, this is pretty common. We support it for re-auth as
> >> well as incremental auth (where the user has already approved scope "a=
"
> >> and is presented with a request for scopes "a b", they will only need =
to
> >> approve scope "b").  In fact if you don't do this, then incremental au=
th
> >> isn't really viable.
> >>
> >> Regarding security: don't do this for non-confidential clients where y=
ou
> >> can't verify the identity of the app by the redirect (e.g. a localhost
> >> redirect to an installed app).
> >>
> >> On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin  >> > wrote:
> >>
> >>     Hi Justin, thanks for the advice,
> >>
> >>     Cheers, Sergey
> >>
> >>     On 18/01/16 11:47, Justin Richer wrote:
> >>
> >>         Yes, this is common practice. Give the user the option to
> >>         remember the
> >>         decision. This is known as "trust on first use", or tofu. Our
> >>         server,
> >>         MITREid Connect, implements this as do many others.
> >>
> >>
> >>
> >>         -- Justin
> >>
> >>         / Sent from my phone /
> >>
> >>
> >>         -------- Original message --------
> >>         From: Sergey Beryozkin  >>         >
> >>         Date: 1/18/2016 5:59 AM (GMT-05:00)
> >>         To: oauth@ietf.org 
> >>         Subject: [OAUTH-WG] Can the repeated authorization of scopes b=
e
> >>         avoided ?
> >>
> >>         Hi All
> >>
> >>         The question relates to the process of showing the authorizati=
on
> >>         code/implicit flow consent screen to a user.
> >>
> >>
> >>         I'm discussing with my colleagues the possibility of avoiding
> >>         asking the
> >>         same user whose session has expired and who is re-authenticati=
ng
> >>         with AS
> >>         which scopes should be approved.
> >>
> >>         For example, suppose the OAuth2 client redirects a user with t=
he
> >>         requested scope 'a'. The user signs in to AS and is shown a
> >> consent
> >>         screen asking to approve the 'a' scope. The user approves 'a'
> >>         and the
> >>         flow continues.
> >>
> >>         Some time later, when the user's session has expired, the user
> is
> >>         redirected to AS with the same 'a' scope.
> >>
> >>         Would it be a good idea, at this point, not to show the user t=
he
> >>         consent
> >>         screen asking to approve the 'a' scope again ? For example, AS
> >> can
> >>         persist the fact that a given user has already approved 'a' fo=
r
> >>         a given
> >>         client earlier, so when the user re-authenticates, AS will use
> >>         this info
> >>         and will avoid showing the consent screen.
> >>
> >>         That seems to make sense, but I'm wondering, can there be some
> >>         security
> >>         implications associated with it, any recommendations/advices
> >>         will be welcome
> >>
> >>         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
> >>
> >>
> >
> >
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

Fwiw, at Ozwillo, we track grants per user per client_id (we don't supp=
ort native apps; only web flows for now), and we don't do "increme=
ntal grants" like Google: if you request scope B and the user had only=
 granted scope A, you'll get a token for scope B only. This is partly b=
ecause our tokens are not for our own APIs only, contrary to Google, so we =
want to allow clients to get tokens with narrow scopes so they could have o=
ne token per third-party API and prevent rogue resources from trying to use=
 received tokens at other APIs.

UI-wise, we tell the use=
r what he already granted to the client, and even let him grant scopes that=
 the client has pre-registered as "possibly needed at some time" =
(through a custom provisioning protocol), but the issued token is always fo=
r the exact scopes that the client requested in this specific request.
And if all requested scopes have already been granted, then we do a t=
ransparent redirect without showing anything to the user (which is what mos=
t other implementations do too)

Le=C2=A0mar. 26 janv. 2016 19:04,=C2=A0Sergey Beryozkin <sberyozkin@gmail.com> a =C3=A9crit=
=C2=A0:
Hi



I'm not sure if the next question is off topic or too low level,

hopefully not,



When the repeated authorization is skipped or only new scopes are

requested to be authorized as per the incremented auth approach, is it

reasonable to assume that the record that is used to track it all is

actually the existing access token or is totally OIDC implementation

specific ?

I think using the existing token as a record is reasonable because it is
time scoped and if we do not use the access token for keeping the track

of the multiple approvals, etc, then one need to introduce one more

record mirroring to some extent the access token...



For example, the user session may have expired but the access token that
was issued to a client web app on behalf of this user is still active,

so when the user returns and signs in again, and for example, approves

few more scopes, then the existing access token (the record) gets

updated, instead of a new token being created.



If it is reasonable then does it mean the sticky or incremental

authorization works as long as the access token is available

(refreshable) ?



Sergey









On 19/01/16 09:59, Sergey Beryozkin wrote:

> Hi William

>

> Thanks for the advice. FYI we are also on the way to supporting the
> incremental authorization of scopes - thanks for highlighting the

> importance of this process on this list...

>

> Cheers, Sergey

> On 19/01/16 03:10, William Denniss wrote:

>> Agree with Justin, this is pretty common. We support it for re-aut=
h as

>> well as incremental auth (where the user has already approved scop=
e "a"

>> and is presented with a request for scopes "a b", they w=
ill only need to

>> approve scope "b").=C2=A0 In fact if you don't do th=
is, then incremental auth

>> isn't really viable.

>>

>> Regarding security: don't do this for non-confidential clients=
 where you

>> can't verify the identity of the app by the redirect (e.g. a l=
ocalhost

>> redirect to an installed app).

>>

>> On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin <sberyozkin@gmail.com

>> <mailto:sberyozkin@gmail.com>> wrote:

>>

>>=C2=A0 =C2=A0 =C2=A0Hi Justin, thanks for the advice,

>>

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

>>

>>=C2=A0 =C2=A0 =C2=A0On 18/01/16 11:47, Justin Richer wrote:

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, this is common practice. Giv=
e the user the option to

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0remember the

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0decision. This is known as "=
trust on first use", or tofu. Our

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0server,

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MITREid Connect, implements this =
as do many others.

>>

>>

>>

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

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/ Sent from my phone /

>>

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------- Original message -------=
-

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

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

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date: 1/18/2016 5:59 AM (GMT-05:0=
0)

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0To: oauth@ietf.org <mailto:oauth@ietf.org>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: [OAUTH-WG] Can the repea=
ted authorization of scopes be

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0avoided ?

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi All

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The question relates to the proce=
ss of showing the authorization

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0code/implicit flow consent screen=
 to a user.

>>

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I'm discussing with my collea=
gues the possibility of avoiding

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0asking the

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0same user whose session has expir=
ed and who is re-authenticating

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0with AS

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which scopes should be approved.<=
br>
>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0For example, suppose the OAuth2 c=
lient redirects a user with the

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0requested scope 'a'. The =
user signs in to AS and is shown a

>> consent

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0screen asking to approve the '=
;a' scope. The user approves 'a'

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and the

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0flow continues.

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Some time later, when the user=
9;s session has expired, the user is

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0redirected to AS with the same &#=
39;a' scope.

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Would it be a good idea, at this =
point, not to show the user the

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

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0screen asking to approve the '=
;a' scope again ? For example, AS

>> can

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0persist the fact that a given use=
r has already approved 'a' for

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a given

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client earlier, so when the user =
re-authenticates, AS will use

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this info

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and will avoid showing the consen=
t screen.

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0That seems to make sense, but I&#=
39;m wondering, can there be some

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

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0implications associated with it, =
any recommendations/advices

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0will be welcome

>>

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

>>

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_________________________________=
______________

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

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

>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.iet=
f.org/mailman/listinfo/oauth

>>

>>

>>=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/=
listinfo/oauth

>>

>>

>

>



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--001a1141ef2641983f052a4142d3--


From nobody Tue Jan 26 10:59:10 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BBE1B2B9E for ; Tue, 26 Jan 2016 10:59:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIRltKs6y9O8 for ; Tue, 26 Jan 2016 10:59:01 -0800 (PST)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7981B2B9D for ; Tue, 26 Jan 2016 10:59:01 -0800 (PST)
Received: by mail-ig0-x232.google.com with SMTP id t15so66244569igr.0 for ; Tue, 26 Jan 2016 10:59:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LbuDjbVEKrpJgQf9Vc/xXcDnha1/kHMhIYWmgHb2gx8=; b=PPFozX8EXTlNlIX4xVPnzKJVLYGL41h0S7cHaENSP72tRBzocmf3A+lUWB6h0ap10l 57PPNuW9JHQ3krJknxQxODss+XBz3YLaiqO+v07cZVnHnybzA64/stPvCplfLy21E5Hz eeYiFs3NowER+HNhR2CdL11dyf8APmVBsOTAI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=LbuDjbVEKrpJgQf9Vc/xXcDnha1/kHMhIYWmgHb2gx8=; b=PgO8dxQ97D0Rn2fro8KgiA4u+UCCiz42Sex75T7NcsurXaas3q5N7+BH2xOw8mkH84 zlWjnm+UiA91FUTvoFD6fc/GMhYDqHjF/t7SZQcyG1PNHQtxIYf0oNE7D/MI4iryP+jO jVcmeCNdKUm0F75IeV7fmf4c6VjLDGXKqiNdu8FWs03QbVFaBrelR6ld/HaAvO7c2c0w EqWRqpW9kGRk201zzm1vPe8/rsAgDi7aXO3/jDvK0Vx1M/9uK8hsc9xX9o7GPwaJC7cg vH1e2ZzDGm5KIR2tq82yVpQx6X8QAkdHvKcY6NHUoVq4QUgxyJmYkOJTu3ytZPdmTqZV Hbvg==
X-Gm-Message-State: AG10YOQjxl8/DHsPoVU05o6jbQErzvEanRKwmzQ/KBZ6tNp2uviJrflhN+2yPGYQ/jSYF3LoLCsS7Thz/Zf5Q1/k
X-Received: by 10.50.18.112 with SMTP id v16mr24140525igd.57.1453834740515; Tue, 26 Jan 2016 10:59:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.212.69 with HTTP; Tue, 26 Jan 2016 10:58:30 -0800 (PST)
In-Reply-To: <56A78EEF.4090706@aol.com>
References: <569E2076.2090405@gmx.net>  <569F915D.8020806@mit.edu>             <56A78EEF.4090706@aol.com>
From: Brian Campbell 
Date: Tue, 26 Jan 2016 11:58:30 -0700
Message-ID: 
To: George Fletcher 
Content-Type: multipart/alternative; boundary=089e0149bd924570ff052a41478d
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 18:59:08 -0000

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

I'm staying that it's sufficiently unlikely that it shouldn't be part of
the threat model and that a discovery lookup on iss isn't necessary.



On Tue, Jan 26, 2016 at 8:21 AM, George Fletcher  wrote:

> While it's a different way of getting the endpoints mixed up, I don't
> think that makes it invalid. If we are going to address the attack vector=
 I
> believe we should solve it for "all" cases not just the ones that seem mo=
st
> likely.
>
> Thanks,
> George
>
> On 1/26/16 8:37 AM, Brian Campbell wrote:
>
> I'm not sure what's described in the blog post is actually a variant of a=
n
> attack that anyone is really concerned about? A client developer would ha=
ve
> to change a production system to use an unfamiliar value for the token
> endpoint based solely on a an email without even looking at service
> documentation or metadata.
>
>
> On Fri, Jan 22, 2016 at 6:29 PM, Nat Sakimura  wrote:
>
>> I wrote a blog on why the current mix-up draft approach does not solve
>> the issue.
>>
>>
>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc=
6749/
>>
>> Hopefully, the point I am making is clearer by this.
>>
>> Best,
>>
>> Nat
>>
>> 2016=E5=B9=B41=E6=9C=8823=E6=97=A5(=E5=9C=9F) 8:32 Mike Jones < 
>> Michael.Jones@microsoft.com>:
>>
>>> I like the =E2=80=9Cfrom which the authorization server's configuration
>>> information location can be derived=E2=80=9D language.  Thanks.  I=E2=
=80=99ll plan to
>>> incorporate that the next time the draft is revised.
>>>
>>>
>>>
>>>                                                                 -- Mike
>>>
>>>
>>>
>>> *From:* Brian Campbell [mailto: 
>>> bcampbell@pingidentity.com]
>>> *Sent:* Friday, January 22, 2016 3:26 PM
>>> *To:* Nat Sakimura < sakimura@gmail.com>
>>> *Cc:* Mike Jones < 
>>> Michael.Jones@microsoft.com>; Justin Richer ; <
>>> oauth@ietf.org> 
>>>
>>>
>>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>>
>>>
>>>
>>> I agree that the language describing OAuth issuer could and should be
>>> improved. The text now reads like it is the exact and full URL where th=
e
>>> metadata/discovery document is located. Perhaps something more like "th=
e
>>> URL from which the authorization server's configuration information
>>> location can be derived" and explain that adding the .well-known bits t=
o
>>> the issuer is where the configuration information can actually be found=
.
>>>
>>>
>>>
>>> On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura < 
>>> sakimura@gmail.com> wrote:
>>>
>>> Re: iss. I discussed this a bit with Nov in more details. It probably i=
s
>>> a sloppy language of the specs that is making it difficult to read what=
 you
>>> wanted to achieve.
>>>
>>>
>>>
>>> In mix-up-mitigation draft, OAuth issuer is "the URL of the
>>> authorization server's configuration information location". In OAuth
>>> discovery draft, there is something called "OAuth 2.0 Configuration
>>> Information Location URL", which is equal to "OpenID Connect Issuer".
>>>
>>> When I wrote the statement, I thought you were pointing to the URL that
>>> you can actually pull the configuration information by "the URL of the
>>> authorizaiton server's configuration information location" since otherw=
ise
>>> you would have used the term "OAuth 2.0 Configuration Information Locat=
ion
>>> URL". But after all, you probably meant these two are the same. Then I
>>> would strongly recommend to fix the language.
>>>
>>> Now, even If that is the case, the relationship like
>>>
>>> =C2=B7         iss + .well-know/openid-configuration =3D Connect OP con=
fig
>>> endoint
>>>
>>> =C2=B7         OAuth config endpoint - .well-known/openid-configuration=
 =3D
>>> OAuth iss
>>>
>>> is very confusing.
>>>
>>>
>>>
>>> You also claim that your approach is simpler, but to me, your approach
>>> seem to be overly complex. It requires discovery and the check for the
>>> value of the discovered config information to work as the mitigation.
>>> (Right. Draft -01 does not have it, so it does not solve the mix-up iss=
ue.)
>>> With oauth-meta, you do not need it.
>>>
>>>
>>>
>>> Finally, your point that HATEOAS reminds you of WSDL, it is not. If you
>>> want to have something similar to WSDL in REST API area, it is Swagger.
>>> (Actually, it is gaining a lot of momentum recently, but that's beside =
the
>>> fact ;-). And the point here is not the format but the fact that we nee=
d to
>>> have a way to associate metadata to the data. The root cause of this mi=
x-up
>>> attack is that the metadata and data is not associated properly. We hav=
e a
>>> standard way of associating the data and metadata with link-rel such as
>>> RFC5988 so why not use it? Link-rel-href pattern is used a lot now. Mos=
t
>>> modern web pages actually have it. Using a proper way to associate meta=
data
>>> with data will save you from a lot of other attacks in the future. Inst=
ead
>>> of doing patch works, we should solve it architecturally.
>>>
>>>
>>>
>>> Nat
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 10:34 Mike Jones < 
>>> Michael.Jones@microsoft.com>:
>>>
>>> Nat, I=E2=80=99m confused by this statement in the message you referenc=
e =E2=80=9CUnfortunately,
>>> this does not match the value of OAuth issuer defined in Section 2
>>> of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as
>>> specified in 3.1. As such, validation as specified in bullet 1 of Secti=
on 4
>>> fails in Google's case -- OR it means that the document is internally
>>> inconsistent.=E2=80=9D.  The issuer definition in draft-jones-oauth-dis=
covery
>>> is 100% compatible with the one in OpenID Connect Discovery, by design.=
  In
>>> the Google example, both the OpenID issuer and the OAuth issuer values
>>> would be the string =E2=80=9C 
>>> https://accounts.google.com=E2=80=9D.  What is the inconsistency that y=
ou
>>> perceive?
>>>
>>>
>>>
>>> The discussion of the duplication problem happened in the private
>>> meetings in Yokohama.
>>>
>>>
>>>
>>> I will admit, in Yokohama, I didn=E2=80=99t speak up in the public meet=
ings to
>>> point out that a simpler alternative to oauth-meta was already being
>>> discussed there in private, because then I would have had to talk about=
 the
>>> security issues, which we=E2=80=99d decided not to publicly do at that =
point.  So I
>>> stayed silent during the poll, out of politeness.  Perhaps I should hav=
e
>>> found a way to say something then anyway, but that=E2=80=99s water unde=
r the bridge
>>> now.
>>>
>>>
>>>
>>> Finally, for what it=E2=80=99s worth, the HATEOAS stuff reminds me far =
too much
>>> of Web Services Description Language (WSDL) =E2=80=93 part of the compl=
exity
>>> baggage that helped sink Web Services.  The use of =E2=80=9Clink rel=E2=
=80=9D to define an
>>> interaction vocabulary and publish endpoints for that vocabulary seems
>>> pretty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=
=93 another cute =E2=80=9CWebby=E2=80=9D
>>> innovation that never caught on.  The industry has pretty much voted wi=
th
>>> its feet and is using JSON for publishing discovery data structures =E2=
=80=93 not
>>> =E2=80=9Clink rel=E2=80=9D.  I am against us reverting to the =E2=80=9C=
link rel=E2=80=9D proposal from 2008
>>> that never caught on when JSON is simpler and does a better job.
>>>
>>>
>>>
>>>                                                                 -- Mike
>>>
>>>
>>>
>>> *From:* Nat Sakimura [mailto: sakimura@gmail.com]
>>> *Sent:* Thursday, January 21, 2016 6:24 AM
>>> *To:* Justin Richer < jricher@mit.edu>; Mike Jones <
>>> Michael.Jones@microsoft.com>
>>> *Cc:* William Denniss < wdenniss@google.com>; <
>>> oauth@ietf.org> < oauth@ietf.org>
>>>
>>>
>>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>>
>>>
>>>
>>> Mike,
>>>
>>>
>>>
>>> You just criticize my draft. That's ok, but I would really like to get
>>> some response to my questions stated in
>>> 
>>> https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To
>>> me, it just does not seem to work, and the combination of the oauth-met=
a
>>> and PKCE seems to be much more elegan, nicer, and much simpler to
>>> implement. If you just give up the dynamic response at the authorizatio=
n
>>> endpoint, then you even do not have to touch the code but just change a
>>> config file.
>>>
>>>
>>>
>>> Please convince me by answering to my questions.
>>>
>>>
>>>
>>> For the record of Yokohama, I do not recall much about duplication in
>>> OAuth session. The poll in the room was 19 for / zero against / 4
>>> persons need more information. Indeed, it is not duplicating much. And =
if
>>> you move to a new model without pre-configured discovery, it is not
>>> duplicating any but the resource endpoint URI, which is optional and is=
 for
>>> the cases where the client did not know the concrete resource endpoint =
to
>>> start with.
>>>
>>>
>>>
>>> I understand your usecases always start from a concrete endpoint
>>> location. Mine do not. In a four party model, it is likely not. The use=
r
>>> just want to have the service to fetch his data from some resource
>>> endpoint. He just hits the service. He does not hit the resource endpoi=
nt
>>> directly. For example, in the case of a consumer using a personal finan=
ce
>>> platform (PFP)to manage his pension fund, he hits the PFP and not the
>>> Pension fund. Assuming that the pension fund has delegated the
>>> authorization control to the authorization server, then, the authorizat=
ion
>>> server should return both the access token and the endpoint of the pens=
ion
>>> fund so that the PFP can pull the data using them. A similar model hold=
s
>>> for personal health service and health care providers.
>>>
>>>
>>>
>>> Best,
>>>
>>>
>>>
>>> Nat
>>>
>>>
>>>
>>>
>>>
>>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 21:18 Justin Richer < jricher@mit.edu>:
>>>
>>> Convergence is exactly what I=E2=80=99m arguing for, though. These thin=
gs ought
>>> to work together.
>>>
>>>
>>>
>>>  =E2=80=94 Justin
>>>
>>>
>>>
>>> On Jan 21, 2016, at 2:55 AM, Mike Jones < 
>>> Michael.Jones@microsoft.com> wrote:
>>>
>>>
>>>
>>> My memory of the discussions of the oauth-meta draft in Yokohama were
>>> that many people felt that it was unnecessarily dynamically duplicating=
 a
>>> lot of information that the client already had.  Most of us that were a=
ware
>>> of the attacks then were in favor of a more targeted, minimal approach.
>>> You were listened to in Yokohama, but that didn=E2=80=99t necessarily m=
ean that
>>> people agreed with the approach.  Participants were already aware of th=
e
>>> oauth-meta proposal in Darmstadt but no one spoke up in favor of it tha=
t I
>>> can recall.  Rather, I think people were thinking that =E2=80=9Cless is=
 more=E2=80=9D.
>>>
>>>
>>>
>>> There have also been discussions in the last day about how dynamically
>>> returning a resource URL, which oauth-meta does, is both unnecessary (s=
ince
>>> the client initiated the resource authorization already knowing what
>>> resource it wants to access) and often problematic, since many
>>> authorization servers can authorize access to multiple resources.  If
>>> anything, the client should be telling the authorization server what
>>> resource it wants to access =E2=80=93 not the other way around.
>>>
>>>
>>>
>>> I=E2=80=99m not saying that there aren=E2=80=99t some good ideas in the=
 oauth-meta draft
>>> =E2=80=93 I=E2=80=99m sure there are, just as there are in the approach=
 designed by the
>>> participants in Darmstadt.  While I volunteered to write the first draf=
t of
>>> the mix-up-mitigation approach, it really reflects something a lot of
>>> people have already bought into =E2=80=93 as evidenced in the passion i=
n the
>>> high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D thread=
, and not just my
>>> personal project.
>>>
>>>
>>>
>>> If you think there are things missing or wrong in the mix-up-mitigation
>>> draft, please say what they are.  That will help us quickly converge on=
 a
>>> solution that will work for everyone.
>>>
>>>
>>>
>>>                                                           Sincerely,
>>>
>>>                                                           -- Mike
>>>
>>>
>>>
>>> *From:* Nat Sakimura [ mailto:sakimura@gmail.com
>>> ]
>>> *Sent:* Wednesday, January 20, 2016 11:17 PM
>>> *To:* Mike Jones < 
>>> Michael.Jones@microsoft.com>; William Denniss < 
>>> wdenniss@google.com>; Justin Richer < jricher@mit.edu>
>>> *Cc:* oauth@ietf.org
>>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>>
>>>
>>>
>>> Hi Mike.
>>>
>>>
>>>
>>> Conversely, I would like to ask why this approach does not work for
>>> Mix-up attack. As Nov stated, we in fact have discussed the approach in
>>> quite a length back in Yokohama. I really would like to know why it doe=
s
>>> not work.
>>>
>>>
>>>
>>> Besides, for oauth-meta approach, mix-up attack is only one of the thin=
g
>>> it solves.
>>>
>>>
>>>
>>> Nat Sakimura
>>>
>>>
>>>
>>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones < 
>>> Michael.Jones@microsoft.com>:
>>>
>>> Not to be negative, but I disagree with adopting
>>> draft-sakimura-oauth-meta.  We should define and promote one mitigation
>>> approach to the mix-up attacks.  Having two would confuse implementers =
and
>>> cause compatibility problems =E2=80=93 reducing overall security.
>>>
>>>
>>>
>>> The approach defined in draft-jones-oauth-mix-up-mitigation was created
>>> in collaboration with the security researchers who identified the probl=
ems
>>> in the first place, was vigorously discussed in the security meeting Ha=
nnes
>>> and Torsten held in Darmstadt, and has been since refined based on
>>> substantial input from the working group.  And at least three implement=
ers
>>> have already stated that they=E2=80=99ve implemented it.  I=E2=80=99m n=
ot saying that it=E2=80=99s,
>>> but if there are things missing or things that need to be improved in o=
ur
>>> approach, we should do it there, rather introducing a competing approac=
h.
>>>
>>>
>>>
>>> Also, standard OAuth deployments register the client and then use the
>>> information gathered at registration time for subsequent protocol
>>> interactions.  They do not need all the configuration information for t=
he
>>> authorization server to be retransmitted at runtime.  The oauth-meta dr=
aft
>>> goes too far in that direction, at least as I see it.  Returning things=
 two
>>> ways creates its own problems, as discussed in the Duplicate Informatio=
n
>>> Attacks security considerations section (7.2) of the mix-up-mitigation
>>> draft.
>>>
>>>
>>>
>>> I=E2=80=99ll note that the mix-up-mitigation approach is compatible wit=
h
>>> existing practice in both static and dynamic metadata discovery.  Reply=
ing
>>> to Justin=E2=80=99s comment that =E2=80=9CIt's the pre-configured disco=
very document
>>> that's at the root of the mix-up attack in the first place=E2=80=9D =E2=
=80=93 this is
>>> not the case.  The attacks can be performed without either discovery or
>>> dynamic registration.
>>>
>>>
>>>
>>> I would be interested in hearing a technical discussion on whether ther=
e
>>> are aspects of the oauth-meta approach that mitigate aspects of the att=
acks
>>> that the mix-up-mitigation approach does not.  That could help inform
>>> whether there are additional things we should add to or change in the
>>> mix-up draft.
>>>
>>>
>>>
>>>                                                           -- Mike
>>>
>>>
>>>
>>> *From:* OAuth [mailto: oauth-bounces@ietf.org] =
*On
>>> Behalf Of *William Denniss
>>> *Sent:* Wednesday, January 20, 2016 10:37 PM
>>> *To:* Justin Richer < jricher@mit.edu>
>>> *Cc:* oauth@ietf.org
>>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>>
>>>
>>>
>>> +1 to adopt this, and I agree with Justin's comments.
>>>
>>>
>>>
>>> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer < 
>>> jricher@mit.edu> wrote:
>>>
>>> +1
>>>
>>> Inline discovery and pre-configured discovery (ie, .well-known) should
>>> at the very least be compatible and developed together. It's the
>>> pre-configured discovery document that's at the root of the mix-up atta=
ck
>>> in the first place.
>>>
>>>  -- Justin
>>>
>>>
>>>
>>> On 1/19/2016 10:30 PM, Nat Sakimura wrote:
>>>
>>> Just to give more context, at IETF 94, I have done a presentation on
>>> discovery.
>>>
>>>
>>>
>>> According to the minutes,
>>>
>>>
>>>
>>>     (f) Discovery (Nat)
>>>
>>>
>>>
>>>              Nat explains his document as an example of the work that h=
as to be done
>>>
>>>              in the area of discovery, which is a topic that has been i=
dentified
>>>
>>>              as necessary for interoperability since many years but so =
far there
>>>
>>>              was not time to work on it. Mike, John and Nat are working=
 on a new
>>>
>>>              document that describes additional discovery-relevant comp=
onents.
>>>
>>>
>>>
>>>              Poll: 19 for / zero against / 4 persons need more informat=
ion.
>>>
>>>
>>>
>>> The document discussed there was
>>> 
>>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
>>> simple (only 1-page!) but a very powerful document that nudges towards
>>> HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix=
-up
>>> attack without introducing the concept of issuer which is not in RFC674=
9.
>>> It is also good for selecting different endpoints depending on the user
>>> authentication and authorization results and more privacy sensitive tha=
n
>>> pre-announced Discovery document. It also allows you to find to which
>>> protected resource endpoint you can use the access token against.
>>>
>>>
>>>
>>> In the last sentence of the minutes, it talks about "a new document tha=
t
>>> describes additional discovery-relevant components". This is
>>> 
>>> https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went
>>> for the call for adoption. However, it is only a half of the story. I
>>> believe  
>>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was
>>> discussed at IETF 94 and had support there should be adopted as well.
>>>
>>>
>>>
>>> Nat Sakimura
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura < 
>>> sakimura@gmail.com>:
>>>
>>> Thanks Hannes.
>>>
>>>
>>>
>>> I did not find
>>> 
>>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which was
>>> discussed in Yokohama, and was largely in agreement if my recollection =
is
>>> correct. Why is it not in the call for adoption?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig <=
 
>>> hannes.tschofenig@gmx.net>:
>>>
>>> Hi all,
>>>
>>> we have submitted our new charter to the IESG (see
>>> 
>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
>>> since some IESG members like to see an updated list of milestones as
>>> well. For this reason, based on a suggestion from Barry, we are also
>>> starting a call for adoption concurrently with the review of the charte=
r
>>> text by the IESG.
>>>
>>> We will post separate mails on the individual documents. Your feedback
>>> is important! Please take the time to look at the documents and provide
>>> your feedback.
>>>
>>> Ciao
>>> Hannes & Derek
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> 
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> OAuth mailing list
>>>
>>> OAuth@ietf.org
>>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> 
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> 
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
>

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


I'm staying that it's sufficiently unlikely that i=
t shouldn't be part of the threat model and that a discovery lookup on =
iss isn't necessary. 



<=
div class=3D"gmail_quote">On Tue, Jan 26, 2016 at 8:21 AM, George Fletcher =
<gffletch@aol.com> wrote:

 =20
   =20
 =20
  

    While it's a different =
way
      of getting the endpoints mixed up, I don't think that makes it
      invalid. If we are going to address the attack vector I believe we
      should solve it for "all" cases not just the ones that seem=
 most
      likely.

      

      Thanks,

      George

    

    
On 1/26/16 8:37 AM, Brian Campbell
      wrote:

    

    

      
I'm not sure what's described in the blog po=
st is
        actually a variant of an attack that anyone is really concerned
        about? A client developer would have to change a production
        system to use an unfamiliar value for the token endpoint based
        solely on a an email without even looking at service
        documentation or metadata. 

        


        

      

      


        
On Fri, Jan 22, 2016 at 6:29 PM, Nat
          Sakimura <sakimura@gmail.com>
          wrote:

          

            
I wrote a blog on why the current mix-up
              draft approach does not solve the issue.=C2=A0
              


              

              
              


              

              
Hopefully, the point I am making is clearer by this.=C2=
=A0

              


              

              
Best,=C2=A0

              


              

              
Nat

            

            

            

              
2016=E5=B9=B41=E6=9C=8823=E6=97=A5(=E5=9C=9F=
) 8:32 Mike Jones <Michael.Jones@microsoft.com>:

              

              

                

                  

                    

                      

                        
I
                            like the =E2=80=9Cfrom which the
                          authorization server's configuration
                          information location can be derived=E2=80=9D
                            language.=C2=A0 Thanks.=C2=A0 I=E2=80=99ll plan=
 to incorporate
                            that the next time the draft is revised.=


                        
=C2=A0=


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

                        
=C2=A0=


                        
From:
                            Brian Campbell [mailto:bcampbell@pingidentity.com]
                            

                            Sent: Friday, January 22, 2016 3:26
                            PM

                            To: Nat Sakimura <sakimura@gmail.com>

                            Cc: Mike Jones <Michael.Jones@microsoft.com>;
                            Justin Richer <jricher@mit.edu>;
                            <oauth@ietf.org>
                            <oauth@ietf.org>

                      

                    

                    

                      

                        


                            Subject: Re: [OAUTH-WG] Call for
                            Adoption

                      

                    

                    

                      

                        
=C2=A0

                        

                          
I agree that
                            the language describing OAuth issuer could
                            and should be improved. The text now reads
                            like it is the exact and full URL where the
                            metadata/discovery document is located.
                            Perhaps something more like "the URL from
                            which the authorization server's
                            configuration information location can be
                            derived" and explain that adding the
                            .well-known bits to the issuer is where the
                            configuration information can actually be
                            found.

                            

                          

                        

                        

                          
=C2=A0

                          

                            
On Thu, Jan 21, 2016 at
                              7:07 PM, Nat Sakimura <sakimura@gmail.com>
                              wrote:

                            

                              

                                
Re: iss. I
                                  discussed this a bit with Nov in more
                                  details. It probably is a sloppy
                                  language of the specs that is making
                                  it difficult to read what you wanted
                                  to achieve.=C2=A0

                                

                                  
=C2=A0

                                

                                

                                  
In
                                      mix-up-mitigation draft, OAuth
                                      issuer is "the URL of the
                                      authorization server's
                                      configuration information
                                      location". In OAuth discovery
                                      draft, there is something called
                                      "OAuth 2.0 Configuration
                                      Information Location URL", which
                                      is equal to "OpenID Connect
                                      Issuer".=C2=A0

                                  
When
                                      I wrote the statement, I thought
                                      you were pointing to the URL that
                                      you can actually pull the
                                      configuration information by "th=
e
                                      URL of the authorizaiton server's
                                      configuration information
                                      location" since otherwise you
                                      would have used the term "OAuth
                                      2.0 Configuration Information
                                      Location URL". But after all, yo=
u
                                      probably meant these two are the
                                      same. Then I would strongly
                                      recommend to fix the language.=C2=A0<=
/span>

                                  
Now,
                                      even If that is the case, the
                                      relationship like=C2=A0

                                  

                                    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
                                        i=
ss
                                      + .well-know/openid-configuration
                                      =3D Connect OP config endoint<=
/p>
                                  

                                    =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0
                                        O=
Auth
                                      config endpoint -
                                      .well-known/openid-configuration =3D
                                      OAuth iss

                                  

                                    
is
                                        very confusing.=C2=A0

                                  

                                

                                

                                  
=C2=A0

                                

                                

                                  
You
                                      also claim that your approach is
                                      simpler, but to me, your approach
                                      seem to be overly complex. It
                                      requires discovery and the check
                                      for the value of the discovered
                                      config information to work as the
                                      mitigation. (Right. Draft -01 does
                                      not have it, so it does not solve
                                      the mix-up issue.) With
                                      oauth-meta, you do not need it.=C2=A0=


                                

                                

                                  
=C2=A0

                                

                                

                                  
Final=
ly,
                                      your point that HATEOAS reminds
                                      you of WSDL, it is not. If you
                                      want to have something similar to
                                      WSDL in REST API area, it is
                                      Swagger. (Actually, it is gaining
                                      a lot of momentum recently, but
                                      that's beside the fact ;-). And
                                      the point here is not the format
                                      but the fact that we need to have
                                      a way to associate metadata to the
                                      data. The root cause of this
                                      mix-up attack is that the metadata
                                      and data is not associated
                                      properly. We have a standard way
                                      of associating the data and
                                      metadata with link-rel such as
                                      RFC5988 so why not use it?
                                      Link-rel-href pattern is used a
                                      lot now. Most modern web pages
                                      actually have it. Using a proper
                                      way to associate metadata with
                                      data will save you from a lot of
                                      other attacks in the future.
                                      Instead of doing patch works, we
                                      should solve it=C2=A0architecturally.=
=C2=A0

                                

                                

                                  
=C2=A0

                                

                                

                                  
Nat

                                

                                

                                  
=C2=A0

                                

                                

                                  
=C2=A0

                                

                              

                              
=C2=A0

                              

                                

                                  
2016=E5=B9=
=B41=E6=9C=8822=E6=97=A5(=E9=87=91)
                                    10:34 Mike Jones <Michael.Jones@microsoft.com>=
;:

                                

                                

                                  

                                    

                                      

                                        

                                          
Nat,
                                              I=E2=80=99m confused by this
                                              statement in the message
                                              you reference =E2=80=9CUnfortunately, this does not =
match
                                              the value of OAuth issuer
                                              defined in Section 2
                                              of=C2=A0draft-jones-oauth-mix=
-up-mitigation-01
                                              nor the 'iss' returne=
d as
                                              specified in 3.1.=C2=A0As suc=
h,
                                              validation as specified in
                                              bullet 1 of Section 4
                                              fails in Google's case --
                                              OR it means that the
                                              document is internally
                                              inconsistent.=E2=80=9D.=C2=A0
                                              The issuer definition in
                                              draft-jones-oauth-discovery
                                              is 100% compatible with
                                              the one in OpenID Connect
                                              Discovery, by design.=C2=A0 I=
n
                                              the Google example, both
                                              the OpenID issuer and the
                                              OAuth issuer values would
                                              be the string =E2=80=9Chttps://accounts.google.com=E2=
=80=9D.=C2=A0
                                              What is the inconsistency
                                              that you perceive?

                                          
=C2=A0

                                          
The
                                              discussion of the
                                              duplication problem
                                              happened in the private
                                              meetings in Yokohama.<=
/p>
                                          
=C2=A0

                                          
I
                                              will admit, in Yokohama, I
                                              didn=E2=80=99t speak up in th=
e
                                              public meetings to point
                                              out that a simpler
                                              alternative to oauth-meta
                                              was already being
                                              discussed there in
                                              private, because then I
                                              would have had to talk
                                              about the security issues,
                                              which we=E2=80=99d decided no=
t to
                                              publicly do at that
                                              point.=C2=A0 So I stayed sile=
nt
                                              during the poll, out of
                                              politeness.=C2=A0 Perhaps I
                                              should have found a way to
                                              say something then anyway,
                                              but that=E2=80=99s water unde=
r the
                                              bridge now.

                                          
=C2=A0

                                          
Finally,
                                              for what it=E2=80=99s worth, =
the
                                              HATEOAS stuff reminds me
                                              far too much of Web
                                              Services Description
                                              Language (WSDL) =E2=80=93 par=
t of
                                              the complexity baggage
                                              that helped sink Web
                                              Services.=C2=A0 The use of
                                              =E2=80=9Clink rel=E2=80=9D to=
 define an
                                              interaction vocabulary and
                                              publish endpoints for that
                                              vocabulary seems pretty
                                              baroque and reminiscent of
                                              =E2=80=9Cmicroformats=E2=80=
=9D =E2=80=93 another
                                              cute =E2=80=9CWebby=E2=80=9D =
innovation
                                              that never caught on.=C2=A0 T=
he
                                              industry has pretty much
                                              voted with its feet and is
                                              using JSON for publishing
                                              discovery data structures
                                              =E2=80=93 not =E2=80=9Clink r=
el=E2=80=9D.=C2=A0 I am
                                              against us reverting to
                                              the =E2=80=9Clink rel=E2=80=
=9D proposal
                                              from 2008 that never
                                              caught on when JSON is
                                              simpler and does a better
                                              job.

                                          
=C2=A0

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

                                          
=C2=A0

                                          
From:<=
/span> Nat
                                              Sakimura [mailto:sakimura@gmail.com]
                                              

                                              Sent: Thursday,
                                              January 21, 2016 6:24 AM

                                              To: Justin Richer
                                              <jricher@mit.edu>;
                                              Mike Jones <Michael.Jones@microsoft.com>

                                              Cc: William Denniss
                                              <wdenniss@google.com>;
                                              <oauth@ietf.org>
                                              <oauth@ietf.org>

                                        

                                      

                                      

                                        

                                          


                                              Subject: Re:
                                              [OAUTH-WG] Call for
                                              Adoption

                                        

                                      

                                      

                                        

                                          
=C2=A0

                                          

                                            
Mike,=C2=
=A0

                                            

                                              
=C2=A0=


                                            

                                            

                                              
You
                                                just criticize my draft.
                                                That's ok, but I would
                                                really like to get some
                                                response to my questions
                                                stated in=C2=A0https://www.ietf.org/mail-archive/web/oau=
th/current/msg15483.html=C2=A0.

                                                To me, it just does not
                                                seem to work, and the
                                                combination of the
                                                oauth-meta and PKCE
                                                seems to be much more
                                                elegan, nicer, and much
                                                simpler to implement. If
                                                you just give up the
                                                dynamic response at the
                                                authorization endpoint,
                                                then you even do not
                                                have to touch the code
                                                but just change a config
                                                file.=C2=A0

                                            

                                            

                                              
=C2=A0=


                                            

                                            

                                              
Please
                                                convince me by answering
                                                to my questions.=C2=A0

                                            

                                            

                                              
=C2=A0=


                                            

                                            

                                              
For
                                                the record of Yokohama,
                                                I do not recall much
                                                about duplication in
                                                OAuth session. The poll
                                                in the room was=C2=A019
                                                  for / zero against / 4
                                                  persons need more
                                                  information. Indeed,
                                                  it is not duplicating
                                                  much. And if you move
                                                  to a new model without
                                                  pre-configured
                                                  discovery, it is not
                                                  duplicating any but
                                                  the resource endpoint
                                                  URI, which is optional
                                                  and is for the cases
                                                  where the client did
                                                  not know the concrete
                                                  resource endpoint to
                                                  start with.=C2=A0<=
/p>
                                            

                                            

                                              
=C2=A0=


                                            

                                            

                                              
I understand your usecases always
                                                  start from a concrete
                                                  endpoint location.
                                                  Mine do not. In a four
                                                  party model, it is
                                                  likely not. The user
                                                  just want to have the
                                                  service to fetch his
                                                  data from some
                                                  resource endpoint. He
                                                  just hits the service.
                                                  He does not hit the
                                                  resource endpoint
                                                  directly. For example,
                                                  in the case of a
                                                  consumer using a
                                                  personal finance
                                                  platform (PFP)to
                                                  manage his pension
                                                  fund, he hits the PFP
                                                  and not the Pension
                                                  fund. Assuming that
                                                  the pension fund has
                                                  delegated the
                                                  authorization control
                                                  to the authorization
                                                  server, then, the
                                                  authorization server
                                                  should return both the
                                                  access token and the
                                                  endpoint of the
                                                  pension fund so that
                                                  the PFP can pull the
                                                  data using them. A
                                                  similar model holds
                                                  for personal health
                                                  service and health
                                                  care providers.=C2=A0

                                            

                                            

                                              
=C2=A0=


                                            

                                            

                                              
Best,=C2=A0

                                            

                                            

                                              
=C2=A0=


                                            

                                            

                                              
Nat
                                            

                                            

                                              
=C2=A0=


                                            

                                          

                                          
=C2=A0

                                          

                                            

                                              
2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=
=E6=9C=A8) 21:18 Justin Richer <jricher@mit.edu>:

                                            

                                            

                                              

                                                
Conv=
ergence
                                                  is exactly what I=E2=80=
=99m
                                                  arguing for, though.
                                                  These things ought to
                                                  work together.

                                              

                                              

                                                

                                                  
=
=C2=A0

                                                

                                                

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

                                                

                                              

                                              

                                                

                                                  
=
=C2=A0

                                                  

                                                    

                                                      

                                                        
On
                                                          Jan 21, 2016,
                                                          at 2:55 AM,
                                                          Mike Jones
                                                          <Michael.Jones@microsoft.com>
                                                          wrote:

                                                      

                                                      
=C2=A0

                                                      

                                                        

                                                          

                                                          
My
                                                          memory of the
                                                          discussions of
                                                          the oauth-meta
                                                          draft in
                                                          Yokohama were
                                                          that many
                                                          people felt
                                                          that it was
                                                          unnecessarily
                                                          dynamically
                                                          duplicating a
                                                          lot of
                                                          information
                                                          that the
                                                          client already
                                                          had.=C2=A0 Most o=
f
                                                          us that were
                                                          aware of the
                                                          attacks then
                                                          were in favor
                                                          of a more
                                                          targeted,
                                                          minimal
                                                          approach.=C2=A0 Y=
ou
                                                          were listened
                                                          to in
                                                          Yokohama, but
                                                          that didn=E2=80=
=99t
                                                          necessarily
                                                          mean that
                                                          people agreed
                                                          with the
                                                          approach.=C2=A0
                                                          Participants
                                                          were already
                                                          aware of the
                                                          oauth-meta
                                                          proposal in
                                                          Darmstadt but
                                                          no one spoke
                                                          up in favor of
                                                          it that I can
                                                          recall.=C2=A0
                                                          Rather, I
                                                          think people
                                                          were thinking
                                                          that =E2=80=9Cles=
s is
                                                          more=E2=80=9D.

                                                          
=C2=A0

                                                          
There
                                                          have also been
                                                          discussions in
                                                          the last day
                                                          about how
                                                          dynamically
                                                          returning a
                                                          resource URL,
                                                          which
                                                          oauth-meta
                                                          does, is both
                                                          unnecessary
                                                          (since the
                                                          client
                                                          initiated the
                                                          resource
                                                          authorization
                                                          already
                                                          knowing what
                                                          resource it
                                                          wants to
                                                          access) and
                                                          often
                                                          problematic,
                                                          since many
                                                          authorization
                                                          servers can
                                                          authorize
                                                          access to
                                                          multiple
                                                          resources.=C2=A0 =
If
                                                          anything, the
                                                          client should
                                                          be telling the
                                                          authorization
                                                          server what
                                                          resource it
                                                          wants to
                                                          access =E2=80=93 =
not
                                                          the other way
                                                          around.
                                                          
=C2=A0

                                                          
I=E2=80=99m
                                                          not saying
                                                          that there
                                                          aren=E2=80=99t so=
me
                                                          good ideas in
                                                          the oauth-meta
                                                          draft =E2=80=93 I=
=E2=80=99m
                                                          sure there
                                                          are, just as
                                                          there are in
                                                          the approach
                                                          designed by
                                                          the
                                                          participants
                                                          in Darmstadt.=C2=
=A0
                                                          While I
                                                          volunteered to
                                                          write the
                                                          first draft of
                                                          the
                                                          mix-up-mitigation
                                                          approach, it
                                                          really
                                                          reflects
                                                          something a
                                                          lot of people
                                                          have already
                                                          bought into =E2=
=80=93
                                                          as evidenced
                                                          in the passion
                                                          in the
                                                          high-volume
                                                          =E2=80=9CMix-Up A=
bout
                                                          The Mix-Up
                                                          Mitigation=E2=80=
=9D
                                                          thread, and
                                                          not just my
                                                          personal
                                                          project.
                                                          
=C2=A0

                                                          
If
                                                          you think
                                                          there are
                                                          things missing
                                                          or wrong in
                                                          the
                                                          mix-up-mitigation
                                                          draft, please
                                                          say what they
                                                          are.=C2=A0 That
                                                          will help us
                                                          quickly
                                                          converge on a
                                                          solution that
                                                          will work for
                                                          everyone.<=
/p>
                                                          
=C2=A0

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
                                                          Sincerely,=


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

                                                          
From: Nat
                                                          Sakimura [mailto:sakimura@gmail.com]
                                                          

                                                          Sent:
                                                          Wednesday,
                                                          January 20,
                                                          2016 11:17 PM

                                                          To:
                                                          Mike Jones
                                                          <Michael.Jones@microsoft.com>;
                                                          William
                                                          Denniss <wdenniss@google.com>;
                                                          Justin Richer
                                                          <jricher@mit.edu>

                                                          Cc: oauth@ietf.org

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          Call for
                                                          Adoption
                                                          
=C2=A0

                                                          

                                                          
Hi
                                                          Mike.=C2=A0

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Conversely,
                                                          I would like
                                                          to ask why
                                                          this approach
                                                          does not work
                                                          for Mix-up
                                                          attack.=C2=A0As N=
ov
                                                          stated, we in
                                                          fact have
                                                          discussed the
                                                          approach in
                                                          quite a length
                                                          back in
                                                          Yokohama. I
                                                          really would
                                                          like to know
                                                          why it does
                                                          not work.=C2=A0
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Besides,
                                                          for oauth-meta
                                                          approach,
                                                          mix-up attack
                                                          is only one of
                                                          the thing it
                                                          solves.=C2=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Nat
                                                          Sakimura

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones <Michael.Jones@microsoft.com>:

                                                          

                                                          

                                                          

                                                          

                                                          
Not
                                                          to be
                                                          negative, but
                                                          I disagree
                                                          with adopting
                                                          draft-sakimura-oa=
uth-meta.=C2=A0
                                                          We should
                                                          define and
                                                          promote one
                                                          mitigation
                                                          approach to
                                                          the mix-up
                                                          attacks.=C2=A0
                                                          Having two
                                                          would confuse
                                                          implementers
                                                          and cause
                                                          compatibility
                                                          problems =E2=80=
=93
                                                          reducing
                                                          overall
                                                          security.<=
/p>
                                                          
=C2=A0

                                                          
The
                                                          approach
                                                          defined in
                                                          draft-jones-oauth=
-mix-up-mitigation
                                                          was created in
                                                          collaboration
                                                          with the
                                                          security
                                                          researchers
                                                          who identified
                                                          the problems
                                                          in the first
                                                          place, was
                                                          vigorously
                                                          discussed in
                                                          the security
                                                          meeting Hannes
                                                          and Torsten
                                                          held in
                                                          Darmstadt, and
                                                          has been since
                                                          refined based
                                                          on substantial
                                                          input from the
                                                          working
                                                          group.=C2=A0 And =
at
                                                          least three
                                                          implementers
                                                          have already
                                                          stated that
                                                          they=E2=80=99ve
                                                          implemented
                                                          it.=C2=A0 I=E2=80=
=99m not
                                                          saying that
                                                          it=E2=80=99s, but=
 if
                                                          there are
                                                          things missing
                                                          or things that
                                                          need to be
                                                          improved in
                                                          our approach,
                                                          we should do
                                                          it there,
                                                          rather
                                                          introducing a
                                                          competing
                                                          approach.<=
/p>
                                                          
=C2=A0

                                                          
Also,
                                                          standard OAuth
                                                          deployments
                                                          register the
                                                          client and
                                                          then use the
                                                          information
                                                          gathered at
                                                          registration
                                                          time for
                                                          subsequent
                                                          protocol
                                                          interactions.=C2=
=A0
                                                          They do not
                                                          need all the
                                                          configuration
                                                          information
                                                          for the
                                                          authorization
                                                          server to be
                                                          retransmitted
                                                          at runtime.=C2=A0
                                                          The oauth-meta
                                                          draft goes too
                                                          far in that
                                                          direction, at
                                                          least as I see
                                                          it.=C2=A0 Returni=
ng
                                                          things two
                                                          ways creates
                                                          its own
                                                          problems, as
                                                          discussed in
                                                          the Duplicate
                                                          Information
                                                          Attacks
                                                          security
                                                          considerations
                                                          section (7.2)
                                                          of the
                                                          mix-up-mitigation
                                                          draft.

                                                          
=C2=A0

                                                          
I=E2=80=99ll
                                                          note that the
                                                          mix-up-mitigation
                                                          approach is
                                                          compatible
                                                          with existing
                                                          practice in
                                                          both static
                                                          and dynamic
                                                          metadata
                                                          discovery.=C2=A0
                                                          Replying to
                                                          Justin=E2=80=99s
                                                          comment that =E2=
=80=9CIt's
                                                          the
                                                          pre-configured
                                                          discovery
                                                          document
                                                          that's at the
                                                          root of the
                                                          mix-up attack
                                                          in the first
                                                          place=E2=80=9D
                                                          =E2=80=93 this is=
 not
                                                          the case.=C2=A0 T=
he
                                                          attacks can be
                                                          performed
                                                          without either
                                                          discovery or
                                                          dynamic
                                                          registration.

                                                          
=C2=A0

                                                          
I
                                                          would be
                                                          interested in
                                                          hearing a
                                                          technical
                                                          discussion on
                                                          whether there
                                                          are aspects of
                                                          the oauth-meta
                                                          approach that
                                                          mitigate
                                                          aspects of the
                                                          attacks that
                                                          the
                                                          mix-up-mitigation
                                                          approach does
                                                          not.=C2=A0 That
                                                          could help
                                                          inform whether
                                                          there are
                                                          additional
                                                          things we
                                                          should add to
                                                          or change in
                                                          the mix-up
                                                          draft.

                                                          
=C2=A0

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

                                                          
From:
                                                          OAuth [mailto:oauth-bounces@ietf.org]
                                                          On Behalf
                                                          Of William
                                                          Denniss

                                                          Sent:
                                                          Wednesday,
                                                          January 20,
                                                          2016 10:37 PM

                                                          To:
                                                          Justin Richer
                                                          <jricher@mit.edu>

                                                          Cc: oauth@ietf.org

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          Call for
                                                          Adoption
                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          
+1
                                                          to adopt this,
                                                          and I agree
                                                          with Justin's
                                                          comments.

                                                          

                                                          
=C2=A0

                                                          

                                                          
On
                                                          Wed, Jan 20,
                                                          2016 at 9:53
                                                          PM, Justin
                                                          Richer <jricher@mit.edu>
                                                          wrote:

                                                          

                                                          

                                                          
+1

                                                          

                                                          Inline
                                                          discovery and
                                                          pre-configured
                                                          discovery (ie,
                                                          .well-known)
                                                          should at the
                                                          very least be
                                                          compatible and
                                                          developed
                                                          together. It'=
s
                                                          the
                                                          pre-configured
                                                          discovery
                                                          document
                                                          that's at the
                                                          root of the
                                                          mix-up attack
                                                          in the first
                                                          place.

                                                          

                                                          =C2=A0-- Justin

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          
On
                                                          1/19/2016
                                                          10:30 PM, Nat
                                                          Sakimura
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Just
                                                          to give more
                                                          context, at
                                                          IETF 94, I
                                                          have done a
                                                          presentation
                                                          on discovery.=C2=
=A0
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
According
                                                          to the
                                                          minutes,=C2=A0
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=C2=A0=C2=A0=C2=A0 (f) Discovery (Nat)

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0Nat explains his document as an example of the work=
 that has to be done

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 in the area of discovery, which is a topic that has been=
 identified

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 as necessary for interoperability since many years but s=
o far there

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 was not time to work on it. Mike, John and Nat are worki=
ng on a new

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 document that describes additional discovery-relevant co=
mponents.

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0Poll: 19 for / zero against / 4 persons need more i=
nformation.

                                                          
=C2=A0

                                                          
The
                                                          document
                                                          discussed
                                                          there was
                                                          
https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
                                                          simple (only
                                                          1-page!) but a
                                                          very powerful
                                                          document that
                                                          nudges towards
                                                          HATEOAS which
                                                          is at the core
                                                          of
                                                          RESTful-ness.
                                                          It also
                                                          mitigates the
                                                          Mix-up attack
                                                          without
                                                          introducing
                                                          the concept of
                                                          issuer which
                                                          is not in
                                                          RFC6749. It is
                                                          also good for
                                                          selecting
                                                          different
                                                          endpoints
                                                          depending on
                                                          the user
                                                          authentication
                                                          and
                                                          authorization
                                                          results and
                                                          more privacy
                                                          sensitive than
                                                          pre-announced
                                                          Discovery
                                                          document. It
                                                          also allows
                                                          you to find to
                                                          which
                                                          protected
                                                          resource
                                                          endpoint you
                                                          can use the
                                                          access token
                                                          against.=C2=A0
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          
In
                                                          the last
                                                          sentence of
                                                          the minutes,
                                                          it talks about
                                                          "a new
                                                          document that
                                                          describes
                                                          additional
                                                          discovery-relevan=
t
                                                          components".
                                                          This is=C2=A0https://tools.ietf.org/html/draft-jones-oauth=
-discovery-00.=C2=A0

                                                          It went for
                                                          the call for
                                                          adoption.
                                                          However, it is
                                                          only a half of
                                                          the story. I
                                                          believe=C2=A0https://tools.ietf.org/html/draft-sakimura-oauth-me=
ta-05=C2=A0that
                                                          was discussed
                                                          at IETF 94 and
                                                          had support
                                                          there=C2=A0should
                                                          be adopted as
                                                          well.=C2=A0 

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Nat
                                                          Sakimura

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura <sakimura@gmail.com>:

                                                          

                                                          

                                                          

                                                          
Thanks
                                                          Hannes.=C2=A0
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
I
                                                          did not find=C2=
=A0https://tools.ietf.org/html/draft-sakimura-o=
auth-meta-05,=C2=A0which
                                                          was discussed
                                                          in Yokohama,
                                                          and was
                                                          largely in
                                                          agreement if
                                                          my
                                                          recollection
                                                          is correct.
                                                          Why is it not
                                                          in the call
                                                          for adoption?=C2=
=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:

                                                          

                                                          

                                                          

                                                          

                                                          
Hi
                                                          all,

                                                          

                                                          we have
                                                          submitted our
                                                          new charter to
                                                          the IESG (see

                                                          http://www.ietf.org/mail-archive/web/oauth/curre=
nt/msg15379.html)
                                                          and

                                                          since some
                                                          IESG members
                                                          like to see an
                                                          updated list
                                                          of milestones
                                                          as

                                                          well. For this
                                                          reason, based
                                                          on a
                                                          suggestion
                                                          from Barry, we
                                                          are also

                                                          starting a
                                                          call for
                                                          adoption
                                                          concurrently
                                                          with the
                                                          review of the
                                                          charter

                                                          text by the
                                                          IESG.

                                                          

                                                          We will post
                                                          separate mails
                                                          on the
                                                          individual
                                                          documents.
                                                          Your feedback

                                                          is important!
                                                          Please take
                                                          the time to
                                                          look at the
                                                          documents and
                                                          provide

                                                          your feedback.
                                                          

                                                          Ciao

                                                          Hannes &
                                                          Derek

                                                          

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.iet=
f.org/mailman/listinfo/oauth

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          
____________=
___________________________________

                                                          
OAuth mailin=
g list

                                                          
OAuth@ietf.org

                                                          
https://www.i=
etf.org/mailman/listinfo/oauth

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          


_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.iet=
f.org/mailman/listinfo/oauth

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          
_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.iet=
f.org/mailman/listinfo/oauth

                                                          

                                                          

                                                          

                                                        

                                                      

                                                    

                                                  

                                                  
=
=C2=A0

                                                

                                              

                                            

                                          

                                        

                                      

                                    

                                  

                                

                              

                              


_______________________________________________

                                OAuth mailing list

                                OAuth@ietf.org

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

                            

                          

                          
=C2=A0

                        

                      

                    

                  

                

              

            

          

        

        

      

      

      

      

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


    

    

  






--089e0149bd924570ff052a41478d--


From nobody Tue Jan 26 11:14:04 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD6F1B2BC8 for ; Tue, 26 Jan 2016 11:14:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeUTSjnOPap7 for ; Tue, 26 Jan 2016 11:13:54 -0800 (PST)
Received: from omr-a011e.mx.aol.com (omr-a011e.mx.aol.com [204.29.186.59]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB2B1B2BC5 for ; Tue, 26 Jan 2016 11:13:53 -0800 (PST)
Received: from mtaout-mab02.mx.aol.com (mtaout-mab02.mx.aol.com [172.26.249.82]) by omr-a011e.mx.aol.com (Outbound Mail Relay) with ESMTP id 88A72380063A; Tue, 26 Jan 2016 14:13:52 -0500 (EST)
Received: from [10.172.102.124] (unknown [10.172.102.124]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mab02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id C08ED38000334; Tue, 26 Jan 2016 14:07:20 -0500 (EST)
To: Brian Campbell 
References: <569E2076.2090405@gmx.net>             <56A78EEF.4090706@aol.com> 
From: George Fletcher 
Organization: AOL LLC
Message-ID: <56A7C3E8.8080601@aol.com>
Date: Tue, 26 Jan 2016 14:07:20 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070007090200040301030004"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1453835241; bh=xqZY4Y1R/TxqlmkgUUrXflbGxc/P1bCT4fmG7PekDng=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=LnKr7rJm5fZrkUtAPbceSTXDxBZTBaegG079Qhoz5kOnk5My153P8rzZQurbNDiTu 2Y+wrjJzfmaCrFq6bsD+GQBw20U3Dhg9gyQOkJV7Lp+BsA5DDQQizddQqOtqXmKR9L MLUhAiclsP7gIhUQGnXHrfZj5YbCNnWbqpIdUN68=
x-aol-sid: 3039ac1af95256a7c3e83fa0
X-AOL-IP: 10.172.102.124
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 19:14:02 -0000

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

So I'm fine with not requiring discovery in the simple case of an RS 
supporting a single AS. However, once the RS moves to supporting 
multiple authorization servers then I believe that discovery based on 
the 'iss' string is required. The discovery results can be cached so a 
discovery lookup per transaction is not required.

Thanks,
George

On 1/26/16 1:58 PM, Brian Campbell wrote:
> I'm staying that it's sufficiently unlikely that it shouldn't be part 
> of the threat model and that a discovery lookup on iss isn't necessary.
>
>
>
> On Tue, Jan 26, 2016 at 8:21 AM, George Fletcher  > wrote:
>
>     While it's a different way of getting the endpoints mixed up, I
>     don't think that makes it invalid. If we are going to address the
>     attack vector I believe we should solve it for "all" cases not
>     just the ones that seem most likely.
>
>     Thanks,
>     George
>
>     On 1/26/16 8:37 AM, Brian Campbell wrote:
>>     I'm not sure what's described in the blog post is actually a
>>     variant of an attack that anyone is really concerned about? A
>>     client developer would have to change a production system to use
>>     an unfamiliar value for the token endpoint based solely on a an
>>     email without even looking at service documentation or metadata.
>>
>>
>>     On Fri, Jan 22, 2016 at 6:29 PM, Nat Sakimura >     > wrote:
>>
>>         I wrote a blog on why the current mix-up draft approach does
>>         not solve the issue.
>>
>>         http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6749/
>>
>>         Hopefully, the point I am making is clearer by this.
>>
>>         Best,
>>
>>         Nat
>>
>>         2016年1月23日(土) 8:32 Mike Jones
>>         >         >:
>>
>>             I like the “from which the authorization server's
>>             configuration information location can be derivedâ€
>>             language.  Thanks.  I’ll plan to incorporate that the
>>             next time the draft is revised.
>>
>>             -- Mike
>>
>>             *From:*Brian Campbell [mailto:bcampbell@pingidentity.com
>>             ]
>>             *Sent:* Friday, January 22, 2016 3:26 PM
>>             *To:* Nat Sakimura >             >
>>             *Cc:* Mike Jones >             >; Justin Richer
>>             >;
>>             > >             >
>>
>>
>>             *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>             I agree that the language describing OAuth issuer could
>>             and should be improved. The text now reads like it is the
>>             exact and full URL where the metadata/discovery document
>>             is located. Perhaps something more like "the URL from
>>             which the authorization server's configuration
>>             information location can be derived" and explain that
>>             adding the .well-known bits to the issuer is where the
>>             configuration information can actually be found.
>>
>>             On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura
>>             > wrote:
>>
>>                 Re: iss. I discussed this a bit with Nov in more
>>                 details. It probably is a sloppy language of the
>>                 specs that is making it difficult to read what you
>>                 wanted to achieve.
>>
>>                 In mix-up-mitigation draft, OAuth issuer is "the URL
>>                 of the authorization server's configuration
>>                 information location". In OAuth discovery draft,
>>                 there is something called "OAuth 2.0 Configuration
>>                 Information Location URL", which is equal to "OpenID
>>                 Connect Issuer".
>>
>>                 When I wrote the statement, I thought you were
>>                 pointing to the URL that you can actually pull the
>>                 configuration information by "the URL of the
>>                 authorizaiton server's configuration information
>>                 location" since otherwise you would have used the
>>                 term "OAuth 2.0 Configuration Information Location
>>                 URL". But after all, you probably meant these two are
>>                 the same. Then I would strongly recommend to fix the
>>                 language.
>>
>>                 Now, even If that is the case, the relationship like
>>
>>                 ·iss + .well-know/openid-configuration = Connect OP
>>                 config endoint
>>
>>                 ·OAuth config endpoint -
>>                 .well-known/openid-configuration = OAuth iss
>>
>>                 is very confusing.
>>
>>                 You also claim that your approach is simpler, but to
>>                 me, your approach seem to be overly complex. It
>>                 requires discovery and the check for the value of the
>>                 discovered config information to work as the
>>                 mitigation. (Right. Draft -01 does not have it, so it
>>                 does not solve the mix-up issue.) With oauth-meta,
>>                 you do not need it.
>>
>>                 Finally, your point that HATEOAS reminds you of WSDL,
>>                 it is not. If you want to have something similar to
>>                 WSDL in REST API area, it is Swagger. (Actually, it
>>                 is gaining a lot of momentum recently, but that's
>>                 beside the fact ;-). And the point here is not the
>>                 format but the fact that we need to have a way to
>>                 associate metadata to the data. The root cause of
>>                 this mix-up attack is that the metadata and data is
>>                 not associated properly. We have a standard way of
>>                 associating the data and metadata with link-rel such
>>                 as RFC5988 so why not use it? Link-rel-href pattern
>>                 is used a lot now. Most modern web pages actually
>>                 have it. Using a proper way to associate metadata
>>                 with data will save you from a lot of other attacks
>>                 in the future. Instead of doing patch works, we
>>                 should solve it architecturally.
>>
>>                 Nat
>>
>>                 2016年1月22日(金) 10:34 Mike Jones
>>                 >                 >:
>>
>>                     Nat, I’m confused by this statement in the
>>                     message you reference “Unfortunately, this does
>>                     not match the value of OAuth issuer defined in
>>                     Section 2
>>                     of draft-jones-oauth-mix-up-mitigation-01 nor the
>>                     'iss' returned as specified in 3.1. As such,
>>                     validation as specified in bullet 1 of Section 4
>>                     fails in Google's case -- OR it means that the
>>                     document is internally inconsistent.â€. The issuer
>>                     definition in draft-jones-oauth-discovery is 100%
>>                     compatible with the one in OpenID Connect
>>                     Discovery, by design.  In the Google example,
>>                     both the OpenID issuer and the OAuth issuer
>>                     values would be the string
>>                     “https://accounts.google.comâ€. What is the
>>                     inconsistency that you perceive?
>>
>>                     The discussion of the duplication problem
>>                     happened in the private meetings in Yokohama.
>>
>>                     I will admit, in Yokohama, I didn’t speak up in
>>                     the public meetings to point out that a simpler
>>                     alternative to oauth-meta was already being
>>                     discussed there in private, because then I would
>>                     have had to talk about the security issues, which
>>                     we’d decided not to publicly do at that point. So
>>                     I stayed silent during the poll, out of
>>                     politeness. Perhaps I should have found a way to
>>                     say something then anyway, but that’s water under
>>                     the bridge now.
>>
>>                     Finally, for what it’s worth, the HATEOAS stuff
>>                     reminds me far too much of Web Services
>>                     Description Language (WSDL) – part of the
>>                     complexity baggage that helped sink Web
>>                     Services.  The use of “link rel†to define an
>>                     interaction vocabulary and publish endpoints for
>>                     that vocabulary seems pretty baroque and
>>                     reminiscent of “microformats†– another cute
>>                     “Webby†innovation that never caught on.  The
>>                     industry has pretty much voted with its feet and
>>                     is using JSON for publishing discovery data
>>                     structures – not “link relâ€.  I am against us
>>                     reverting to the “link rel†proposal from 2008
>>                     that never caught on when JSON is simpler and
>>                     does a better job.
>>
>>                     -- Mike
>>
>>                     *From:*Nat Sakimura [mailto:sakimura@gmail.com
>>                     ]
>>                     *Sent:* Thursday, January 21, 2016 6:24 AM
>>                     *To:* Justin Richer >                     >; Mike Jones
>>                     >                     >
>>                     *Cc:* William Denniss >                     >; >                     > >                     >
>>
>>
>>                     *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>                     Mike,
>>
>>                     You just criticize my draft. That's ok, but I
>>                     would really like to get some response to my
>>                     questions stated in
>>                     https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html .
>>                     To me, it just does not seem to work, and the
>>                     combination of the oauth-meta and PKCE seems to
>>                     be much more elegan, nicer, and much simpler to
>>                     implement. If you just give up the dynamic
>>                     response at the authorization endpoint, then you
>>                     even do not have to touch the code but just
>>                     change a config file.
>>
>>                     Please convince me by answering to my questions.
>>
>>                     For the record of Yokohama, I do not recall much
>>                     about duplication in OAuth session. The poll in
>>                     the room was 19 for / zero against / 4 persons
>>                     need more information. Indeed, it is not
>>                     duplicating much. And if you move to a new model
>>                     without pre-configured discovery, it is not
>>                     duplicating any but the resource endpoint URI,
>>                     which is optional and is for the cases where the
>>                     client did not know the concrete resource
>>                     endpoint to start with.
>>
>>                     I understand your usecases always start from a
>>                     concrete endpoint location. Mine do not. In a
>>                     four party model, it is likely not. The user just
>>                     want to have the service to fetch his data from
>>                     some resource endpoint. He just hits the service.
>>                     He does not hit the resource endpoint directly.
>>                     For example, in the case of a consumer using a
>>                     personal finance platform (PFP)to manage his
>>                     pension fund, he hits the PFP and not the Pension
>>                     fund. Assuming that the pension fund has
>>                     delegated the authorization control to the
>>                     authorization server, then, the authorization
>>                     server should return both the access token and
>>                     the endpoint of the pension fund so that the PFP
>>                     can pull the data using them. A similar model
>>                     holds for personal health service and health care
>>                     providers.
>>
>>                     Best,
>>
>>                     Nat
>>
>>                     2016年1月21日(木) 21:18 Justin Richer
>>                     >:
>>
>>                         Convergence is exactly what I’m arguing for,
>>                         though. These things ought to work together.
>>
>>                          — Justin
>>
>>                             On Jan 21, 2016, at 2:55 AM, Mike Jones
>>                             >                             > wrote:
>>
>>                             My memory of the discussions of the
>>                             oauth-meta draft in Yokohama were that
>>                             many people felt that it was
>>                             unnecessarily dynamically duplicating a
>>                             lot of information that the client
>>                             already had.  Most of us that were aware
>>                             of the attacks then were in favor of a
>>                             more targeted, minimal approach.  You
>>                             were listened to in Yokohama, but that
>>                             didn’t necessarily mean that people
>>                             agreed with the approach. Participants
>>                             were already aware of the oauth-meta
>>                             proposal in Darmstadt but no one spoke up
>>                             in favor of it that I can recall. Rather,
>>                             I think people were thinking that “less
>>                             is moreâ€.
>>
>>                             There have also been discussions in the
>>                             last day about how dynamically returning
>>                             a resource URL, which oauth-meta does, is
>>                             both unnecessary (since the client
>>                             initiated the resource authorization
>>                             already knowing what resource it wants to
>>                             access) and often problematic, since many
>>                             authorization servers can authorize
>>                             access to multiple resources.  If
>>                             anything, the client should be telling
>>                             the authorization server what resource it
>>                             wants to access – not the other way around.
>>
>>                             I’m not saying that there aren’t some
>>                             good ideas in the oauth-meta draft – I’m
>>                             sure there are, just as there are in the
>>                             approach designed by the participants in
>>                             Darmstadt. While I volunteered to write
>>                             the first draft of the mix-up-mitigation
>>                             approach, it really reflects something a
>>                             lot of people have already bought into –
>>                             as evidenced in the passion in the
>>                             high-volume “Mix-Up About The Mix-Up
>>                             Mitigation†thread, and not just my
>>                             personal project.
>>
>>                             If you think there are things missing or
>>                             wrong in the mix-up-mitigation draft,
>>                             please say what they are.  That will help
>>                             us quickly converge on a solution that
>>                             will work for everyone.
>>
>>                             Sincerely,
>>
>>                             -- Mike
>>
>>                             *From:*Nat Sakimura
>>                             [mailto:sakimura@gmail.com]
>>                             *Sent:* Wednesday, January 20, 2016 11:17 PM
>>                             *To:* Mike Jones
>>                             >                             >;
>>                             William Denniss >                             >; Justin
>>                             Richer >                             >
>>                             *Cc:* oauth@ietf.org 
>>                             *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>                             Hi Mike.
>>
>>                             Conversely, I would like to ask why this
>>                             approach does not work for Mix-up
>>                             attack. As Nov stated, we in fact have
>>                             discussed the approach in quite a length
>>                             back in Yokohama. I really would like to
>>                             know why it does not work.
>>
>>                             Besides, for oauth-meta approach, mix-up
>>                             attack is only one of the thing it solves.
>>
>>                             Nat Sakimura
>>
>>                             2016年1月21日(木) 16:02 Mike Jones
>>                             >                             >:
>>
>>                                 Not to be negative, but I disagree
>>                                 with adopting
>>                                 draft-sakimura-oauth-meta. We should
>>                                 define and promote one mitigation
>>                                 approach to the mix-up attacks.
>>                                 Having two would confuse implementers
>>                                 and cause compatibility problems –
>>                                 reducing overall security.
>>
>>                                 The approach defined in
>>                                 draft-jones-oauth-mix-up-mitigation
>>                                 was created in collaboration with the
>>                                 security researchers who identified
>>                                 the problems in the first place, was
>>                                 vigorously discussed in the security
>>                                 meeting Hannes and Torsten held in
>>                                 Darmstadt, and has been since refined
>>                                 based on substantial input from the
>>                                 working group.  And at least three
>>                                 implementers have already stated that
>>                                 they’ve implemented it.  I’m not
>>                                 saying that it’s, but if there are
>>                                 things missing or things that need to
>>                                 be improved in our approach, we
>>                                 should do it there, rather
>>                                 introducing a competing approach.
>>
>>                                 Also, standard OAuth deployments
>>                                 register the client and then use the
>>                                 information gathered at registration
>>                                 time for subsequent protocol
>>                                 interactions. They do not need all
>>                                 the configuration information for the
>>                                 authorization server to be
>>                                 retransmitted at runtime. The
>>                                 oauth-meta draft goes too far in that
>>                                 direction, at least as I see it. 
>>                                 Returning things two ways creates its
>>                                 own problems, as discussed in the
>>                                 Duplicate Information Attacks
>>                                 security considerations section (7.2)
>>                                 of the mix-up-mitigation draft.
>>
>>                                 I’ll note that the mix-up-mitigation
>>                                 approach is compatible with existing
>>                                 practice in both static and dynamic
>>                                 metadata discovery. Replying to
>>                                 Justin’s comment that “It's the
>>                                 pre-configured discovery document
>>                                 that's at the root of the mix-up
>>                                 attack in the first place†– this is
>>                                 not the case.  The attacks can be
>>                                 performed without either discovery or
>>                                 dynamic registration.
>>
>>                                 I would be interested in hearing a
>>                                 technical discussion on whether there
>>                                 are aspects of the oauth-meta
>>                                 approach that mitigate aspects of the
>>                                 attacks that the mix-up-mitigation
>>                                 approach does not.  That could help
>>                                 inform whether there are additional
>>                                 things we should add to or change in
>>                                 the mix-up draft.
>>
>>                                 -- Mike
>>
>>                                 *From:*OAuth
>>                                 [mailto:oauth-bounces@ietf.org
>>                                 ] *On
>>                                 Behalf Of *William Denniss
>>                                 *Sent:* Wednesday, January 20, 2016
>>                                 10:37 PM
>>                                 *To:* Justin Richer >                                 >
>>                                 *Cc:* oauth@ietf.org
>>                                 
>>                                 *Subject:* Re: [OAUTH-WG] Call for
>>                                 Adoption
>>
>>                                 +1 to adopt this, and I agree with
>>                                 Justin's comments.
>>
>>                                 On Wed, Jan 20, 2016 at 9:53 PM,
>>                                 Justin Richer >                                 > wrote:
>>
>>                                     +1
>>
>>                                     Inline discovery and
>>                                     pre-configured discovery (ie,
>>                                     .well-known) should at the very
>>                                     least be compatible and developed
>>                                     together. It's the pre-configured
>>                                     discovery document that's at the
>>                                     root of the mix-up attack in the
>>                                     first place.
>>
>>                                      -- Justin
>>
>>                                     On 1/19/2016 10:30 PM, Nat
>>                                     Sakimura wrote:
>>
>>                                         Just to give more context, at
>>                                         IETF 94, I have done a
>>                                         presentation on discovery.
>>
>>                                         According to the minutes,
>>
>>                                             (f) Discovery (Nat)
>>
>>                                                      Nat explains his
>>                                         document as an example of the
>>                                         work that has to be done
>>
>>                                                      in the area of
>>                                         discovery, which is a topic
>>                                         that has been identified
>>
>>                                                      as necessary for
>>                                         interoperability since many
>>                                         years but so far there
>>
>>                                                      was not time to
>>                                         work on it. Mike, John and
>>                                         Nat are working on a new
>>
>>                                                      document that
>>                                         describes additional
>>                                         discovery-relevant components.
>>
>>                                                      Poll: 19 for /
>>                                         zero against / 4 persons need
>>                                         more information.
>>
>>                                         The document discussed there
>>                                         was
>>                                         https://tools.ietf.org/html/draft-sakimura-oauth-meta-05.
>>                                         This is a simple (only
>>                                         1-page!) but a very powerful
>>                                         document that nudges towards
>>                                         HATEOAS which is at the core
>>                                         of RESTful-ness. It also
>>                                         mitigates the Mix-up attack
>>                                         without introducing the
>>                                         concept of issuer which is
>>                                         not in RFC6749. It is also
>>                                         good for selecting different
>>                                         endpoints depending on the
>>                                         user authentication and
>>                                         authorization results and
>>                                         more privacy sensitive than
>>                                         pre-announced Discovery
>>                                         document. It also allows you
>>                                         to find to which protected
>>                                         resource endpoint you can use
>>                                         the access token against.
>>
>>                                         In the last sentence of the
>>                                         minutes, it talks about "a
>>                                         new document that describes
>>                                         additional discovery-relevant
>>                                         components". This is
>>                                         https://tools.ietf.org/html/draft-jones-oauth-discovery-00.
>>                                         It went for the call for
>>                                         adoption. However, it is only
>>                                         a half of the story. I
>>                                         believe
>>                                         https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that
>>                                         was discussed at IETF 94 and
>>                                         had support there should be
>>                                         adopted as well.
>>
>>                                         Nat Sakimura
>>
>>                                         2016年1月20日(水) 12:05 Nat
>>                                         Sakimura >                                         >:
>>
>>                                             Thanks Hannes.
>>
>>                                             I did not find
>>                                             https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which
>>                                             was discussed in
>>                                             Yokohama, and was largely
>>                                             in agreement if my
>>                                             recollection is correct.
>>                                             Why is it not in the call
>>                                             for adoption?
>>
>>                                             2016å¹´1月19æ—¥(ç«) 20:39
>>                                             Hannes Tschofenig
>>                                             >:
>>
>>                                                 Hi all,
>>
>>                                                 we have submitted our
>>                                                 new charter to the
>>                                                 IESG (see
>>                                                 http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html)
>>                                                 and
>>                                                 since some IESG
>>                                                 members like to see
>>                                                 an updated list of
>>                                                 milestones as
>>                                                 well. For this
>>                                                 reason, based on a
>>                                                 suggestion from
>>                                                 Barry, we are also
>>                                                 starting a call for
>>                                                 adoption concurrently
>>                                                 with the review of
>>                                                 the charter
>>                                                 text by the IESG.
>>
>>                                                 We will post separate
>>                                                 mails on the
>>                                                 individual documents.
>>                                                 Your feedback
>>                                                 is important! Please
>>                                                 take the time to look
>>                                                 at the documents and
>>                                                 provide
>>                                                 your feedback.
>>
>>                                                 Ciao
>>                                                 Hannes & Derek
>>
>>                                                 _______________________________________________
>>                                                 OAuth mailing list
>>                                                 OAuth@ietf.org
>>                                                 
>>                                                 https://www.ietf.org/mailman/listinfo/oauth
>>
>>                                         _______________________________________________
>>
>>                                         OAuth mailing list
>>
>>                                         OAuth@ietf.org
>>                                         
>>
>>                                         https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>                                     _______________________________________________
>>                                     OAuth mailing list
>>                                     OAuth@ietf.org
>>                                     
>>                                     https://www.ietf.org/mailman/listinfo/oauth
>>
>>                                 _______________________________________________
>>                                 OAuth mailing list
>>                                 OAuth@ietf.org 
>>                                 https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>                 _______________________________________________
>>                 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
>
>

-- 
Chief Architect
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


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


  
    
  
  
    So I'm fine with not
      requiring discovery in the simple case of an RS supporting a
      single AS. However, once the RS moves to supporting multiple
      authorization servers then I believe that discovery based on the
      'iss' string is required. The discovery results can be cached so a
      discovery lookup per transaction is not required.

      

      Thanks,

      George

    

    
On 1/26/16 1:58 PM, Brian Campbell
      wrote:

    

    

      
I'm staying that it's sufficiently unlikely that it
        shouldn't be part of the threat model and that a discovery
        lookup on iss isn't necessary. 

        

        

      

      


        
On Tue, Jan 26, 2016 at 8:21 AM, George
          Fletcher <gffletch@aol.com>
          wrote:

          

            
 While it's a
                different way of getting the endpoints mixed up, I don't
                think that makes it invalid. If we are going to address
                the attack vector I believe we should solve it for "all"
                cases not just the ones that seem most likely.

                

                Thanks,

                George

              

              
On 1/26/16 8:37 AM, Brian Campbell wrote:

              

              

                
I'm not sure what's described in the blog
                  post is actually a variant of an attack that anyone is
                  really concerned about? A client developer would have
                  to change a production system to use an unfamiliar
                  value for the token endpoint based solely on a an
                  email without even looking at service documentation or
                  metadata. 

                  


                  

                

                


                  
On Fri, Jan 22, 2016 at 6:29
                    PM, Nat Sakimura <sakimura@gmail.com>
                    wrote:

                    

                      
I wrote a blog on why the current
                        mix-up draft approach does not solve the issue. 
                        


                        

                        
                        


                        

                        
Hopefully, the point I am making is clearer
                          by this. 

                        


                        

                        
Best, 

                        


                        

                        
Nat

                      

                      

                      

                        
2016年1月23日(土) 8:32 Mike Jones
                          <Michael.Jones@microsoft.com>:

                        

                        

                          

                            

                              

                                

                                  
I
                                      like the “from which the
                                    authorization server's configuration
                                    information location can be derivedâ€
                                      language.  Thanks.  I’ll plan to
                                      incorporate that the next time the
                                      draft is revised.

                                  
 

                                  
                                                               

                                      -- Mike

                                  
 

                                  
From:
                                      Brian Campbell [mailto:bcampbell@pingidentity.com]
                                      

                                      Sent: Friday, January 22,
                                      2016 3:26 PM

                                      To: Nat Sakimura <sakimura@gmail.com>

                                      Cc: Mike Jones <Michael.Jones@microsoft.com>;

                                      Justin Richer <jricher@mit.edu>;

                                      <oauth@ietf.org>

                                      <oauth@ietf.org>

                                

                              

                              

                                

                                  


                                      Subject: Re: [OAUTH-WG]
                                      Call for Adoption

                                

                              

                              

                                

                                  
 

                                  

                                    
I
                                      agree that the language describing
                                      OAuth issuer could and should be
                                      improved. The text now reads like
                                      it is the exact and full URL where
                                      the metadata/discovery document is
                                      located. Perhaps something more
                                      like "the URL from which the
                                      authorization server's
                                      configuration information location
                                      can be derived" and explain that
                                      adding the .well-known bits to the
                                      issuer is where the configuration
                                      information can actually be found.

                                      

                                    

                                  

                                  

                                    
 

                                    

                                      
On Thu, Jan
                                        21, 2016 at 7:07 PM, Nat
                                        Sakimura <sakimura@gmail.com>

                                        wrote:

                                      

                                        

                                          
Re: iss.
                                            I discussed this a bit with
                                            Nov in more details. It
                                            probably is a sloppy
                                            language of the specs that
                                            is making it difficult to
                                            read what you wanted to
                                            achieve. 

                                          

                                            
 

                                          

                                          

                                            
In

                                                mix-up-mitigation draft,
                                                OAuth issuer is "the URL
                                                of the authorization
                                                server's configuration
                                                information location".
                                                In OAuth discovery
                                                draft, there is
                                                something called "OAuth
                                                2.0 Configuration
                                                Information Location
                                                URL", which is equal to
                                                "OpenID Connect
                                                Issuer". 

                                            
When

                                                I wrote the statement, I
                                                thought you were
                                                pointing to the URL that
                                                you can actually pull
                                                the configuration
                                                information by "the URL
                                                of the authorizaiton
                                                server's configuration
                                                information location"
                                                since otherwise you
                                                would have used the term
                                                "OAuth 2.0 Configuration
                                                Information Location
                                                URL". But after all, you
                                                probably meant these two
                                                are the same. Then I
                                                would strongly recommend
                                                to fix the language. 

                                            
Now,

                                                even If that is the
                                                case, the relationship
                                                like 

                                            

                                              ·        

                                                  iss

                                                +
                                                .well-know/openid-configuration
                                                = Connect OP config
                                                endoint

                                            

                                              ·        

                                                  OAuth

                                                config endpoint -
                                                .well-known/openid-configuration
                                                = OAuth iss

                                            

                                              
is

                                                  very confusing. 

                                            

                                          

                                          

                                            
 

                                          

                                          

                                            
You

                                                also claim that your
                                                approach is simpler, but
                                                to me, your approach
                                                seem to be overly
                                                complex. It requires
                                                discovery and the check
                                                for the value of the
                                                discovered config
                                                information to work as
                                                the mitigation. (Right.
                                                Draft -01 does not have
                                                it, so it does not solve
                                                the mix-up issue.) With
                                                oauth-meta, you do not
                                                need it. 

                                          

                                          

                                            
 

                                          

                                          

                                            
Finally,

                                                your point that HATEOAS
                                                reminds you of WSDL, it
                                                is not. If you want to
                                                have something similar
                                                to WSDL in REST API
                                                area, it is Swagger.
                                                (Actually, it is gaining
                                                a lot of momentum
                                                recently, but that's
                                                beside the fact ;-). And
                                                the point here is not
                                                the format but the fact
                                                that we need to have a
                                                way to associate
                                                metadata to the data.
                                                The root cause of this
                                                mix-up attack is that
                                                the metadata and data is
                                                not associated properly.
                                                We have a standard way
                                                of associating the data
                                                and metadata with
                                                link-rel such as RFC5988
                                                so why not use it?
                                                Link-rel-href pattern is
                                                used a lot now. Most
                                                modern web pages
                                                actually have it. Using
                                                a proper way to
                                                associate metadata with
                                                data will save you from
                                                a lot of other attacks
                                                in the future. Instead
                                                of doing patch works, we
                                                should solve
                                                it architecturally. 

                                          

                                          

                                            
 

                                          

                                          

                                            
Nat

                                          

                                          

                                            
 

                                          

                                          

                                            
 

                                          

                                        

                                        
 

                                        

                                          

                                            
2016年1月22日(金)
                                              10:34 Mike Jones <Michael.Jones@microsoft.com>:

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    
Nat,

                                                        I’m confused by
                                                        this statement
                                                        in the message
                                                        you reference “Unfortunately, this does not match
                                                        the value of
                                                        OAuth issuer
                                                        defined in
                                                        Section 2
                                                        of draft-jones-oauth-mix-up-mitigation-01
                                                        nor the 'iss'
                                                        returned as
                                                        specified in
                                                        3.1. As such,
                                                        validation as
                                                        specified in
                                                        bullet 1 of
                                                        Section 4 fails
                                                        in Google's case
                                                        -- OR it means
                                                        that the
                                                        document is
                                                        internally
                                                        inconsistent.â€. 

                                                        The issuer
                                                        definition in
                                                        draft-jones-oauth-discovery
                                                        is 100%
                                                        compatible with
                                                        the one in
                                                        OpenID Connect
                                                        Discovery, by
                                                        design.  In the
                                                        Google example,
                                                        both the OpenID
                                                        issuer and the
                                                        OAuth issuer
                                                        values would be
                                                        the string “https://accounts.google.comâ€. 

                                                        What is the
                                                        inconsistency
                                                        that you
                                                        perceive?

                                                    
 

                                                    
The

                                                        discussion of
                                                        the duplication
                                                        problem happened
                                                        in the private
                                                        meetings in
                                                        Yokohama.

                                                    
 

                                                    
I
                                                        will admit, in
                                                        Yokohama, I
                                                        didn’t speak up
                                                        in the public
                                                        meetings to
                                                        point out that a
                                                        simpler
                                                        alternative to
                                                        oauth-meta was
                                                        already being
                                                        discussed there
                                                        in private,
                                                        because then I
                                                        would have had
                                                        to talk about
                                                        the security
                                                        issues, which
                                                        we’d decided not
                                                        to publicly do
                                                        at that point. 
                                                        So I stayed
                                                        silent during
                                                        the poll, out of
                                                        politeness. 
                                                        Perhaps I should
                                                        have found a way
                                                        to say something
                                                        then anyway, but
                                                        that’s water
                                                        under the bridge
                                                        now.

                                                    
 

                                                    
Finally,

                                                        for what it’s
                                                        worth, the
                                                        HATEOAS stuff
                                                        reminds me far
                                                        too much of Web
                                                        Services
                                                        Description
                                                        Language (WSDL)
                                                        – part of the
                                                        complexity
                                                        baggage that
                                                        helped sink Web
                                                        Services.  The
                                                        use of “link
                                                        rel†to define
                                                        an interaction
                                                        vocabulary and
                                                        publish
                                                        endpoints for
                                                        that vocabulary
                                                        seems pretty
                                                        baroque and
                                                        reminiscent of
                                                        “microformats†–
                                                        another cute
                                                        “Webbyâ€
                                                        innovation that
                                                        never caught
                                                        on.  The
                                                        industry has
                                                        pretty much
                                                        voted with its
                                                        feet and is
                                                        using JSON for
                                                        publishing
                                                        discovery data
                                                        structures – not
                                                        “link relâ€.  I
                                                        am against us
                                                        reverting to the
                                                        “link relâ€
                                                        proposal from
                                                        2008 that never
                                                        caught on when
                                                        JSON is simpler
                                                        and does a
                                                        better job.

                                                    
 

                                                    
                                                               

                                                        -- Mike

                                                    
 

                                                    
From: Nat
                                                        Sakimura
                                                        [mailto:sakimura@gmail.com]
                                                        

                                                        Sent:
                                                        Thursday,
                                                        January 21, 2016
                                                        6:24 AM

                                                        To:
                                                        Justin Richer
                                                        <jricher@mit.edu>;
                                                        Mike Jones <Michael.Jones@microsoft.com>

                                                        Cc:
                                                        William Denniss
                                                        <wdenniss@google.com>;

                                                        <oauth@ietf.org> <oauth@ietf.org>

                                                  

                                                

                                                

                                                  

                                                    


                                                        Subject:
                                                        Re: [OAUTH-WG]
                                                        Call for
                                                        Adoption

                                                  

                                                

                                                

                                                  

                                                    
 

                                                    

                                                      
Mike, 

                                                      

                                                        
 

                                                      

                                                      

                                                        
You

                                                          just criticize
                                                          my draft.
                                                          That's ok, but
                                                          I would really
                                                          like to get
                                                          some response
                                                          to my
                                                          questions
                                                          stated in https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html .


                                                          To me, it just
                                                          does not seem
                                                          to work, and
                                                          the
                                                          combination of
                                                          the oauth-meta
                                                          and PKCE seems
                                                          to be much
                                                          more elegan,
                                                          nicer, and
                                                          much simpler
                                                          to implement.
                                                          If you just
                                                          give up the
                                                          dynamic
                                                          response at
                                                          the
                                                          authorization
                                                          endpoint, then
                                                          you even do
                                                          not have to
                                                          touch the code
                                                          but just
                                                          change a
                                                          config file. 

                                                      

                                                      

                                                        
 

                                                      

                                                      

                                                        
Please

                                                          convince me by
                                                          answering to
                                                          my questions. 

                                                      

                                                      

                                                        
 

                                                      

                                                      

                                                        
For

                                                          the record of
                                                          Yokohama, I do
                                                          not recall
                                                          much about
                                                          duplication in
                                                          OAuth session.
                                                          The poll in
                                                          the room was 19 for / zero against / 4 persons
                                                          need more
                                                          information.
                                                          Indeed, it is
                                                          not
                                                          duplicating
                                                          much. And if
                                                          you move to a
                                                          new model
                                                          without
                                                          pre-configured
                                                          discovery, it
                                                          is not
                                                          duplicating
                                                          any but the
                                                          resource
                                                          endpoint URI,
                                                          which is
                                                          optional and
                                                          is for the
                                                          cases where
                                                          the client did
                                                          not know the
                                                          concrete
                                                          resource
                                                          endpoint to
                                                          start with. 

                                                      

                                                      

                                                        
 

                                                      

                                                      

                                                        
I understand your usecases always
                                                          start from a
                                                          concrete
                                                          endpoint
                                                          location. Mine
                                                          do not. In a
                                                          four party
                                                          model, it is
                                                          likely not.
                                                          The user just
                                                          want to have
                                                          the service to
                                                          fetch his data
                                                          from some
                                                          resource
                                                          endpoint. He
                                                          just hits the
                                                          service. He
                                                          does not hit
                                                          the resource
                                                          endpoint
                                                          directly. For
                                                          example, in
                                                          the case of a
                                                          consumer using
                                                          a personal
                                                          finance
                                                          platform
                                                          (PFP)to manage
                                                          his pension
                                                          fund, he hits
                                                          the PFP and
                                                          not the
                                                          Pension fund.
                                                          Assuming that
                                                          the pension
                                                          fund has
                                                          delegated the
                                                          authorization
                                                          control to the
                                                          authorization
                                                          server, then,
                                                          the
                                                          authorization
                                                          server should
                                                          return both
                                                          the access
                                                          token and the
                                                          endpoint of
                                                          the pension
                                                          fund so that
                                                          the PFP can
                                                          pull the data
                                                          using them. A
                                                          similar model
                                                          holds for
                                                          personal
                                                          health service
                                                          and health
                                                          care
                                                          providers. 

                                                      

                                                      

                                                        
 

                                                      

                                                      

                                                        
Best, 

                                                      

                                                      

                                                        
 

                                                      

                                                      

                                                        
Nat

                                                      

                                                      

                                                        
 

                                                      

                                                    

                                                    
 

                                                    

                                                      

                                                        
2016年1月21日(木)
                                                          21:18 Justin
                                                          Richer <jricher@mit.edu>:

                                                      

                                                      

                                                        

                                                          
Convergence

                                                          is exactly
                                                          what I’m
                                                          arguing for,
                                                          though. These
                                                          things ought
                                                          to work
                                                          together.

                                                        

                                                        

                                                          

                                                          
 

                                                          

                                                          

                                                          
 —

                                                          Justin

                                                          

                                                        

                                                        

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          
On

                                                          Jan 21, 2016,
                                                          at 2:55 AM,
                                                          Mike Jones
                                                          <Michael.Jones@microsoft.com>

                                                          wrote:

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          
My

                                                          memory of the
                                                          discussions of
                                                          the oauth-meta
                                                          draft in
                                                          Yokohama were
                                                          that many
                                                          people felt
                                                          that it was
                                                          unnecessarily
                                                          dynamically
                                                          duplicating a
                                                          lot of
                                                          information
                                                          that the
                                                          client already
                                                          had.  Most of
                                                          us that were
                                                          aware of the
                                                          attacks then
                                                          were in favor
                                                          of a more
                                                          targeted,
                                                          minimal
                                                          approach.  You
                                                          were listened
                                                          to in
                                                          Yokohama, but
                                                          that didn’t
                                                          necessarily
                                                          mean that
                                                          people agreed
                                                          with the
                                                          approach. 
                                                          Participants
                                                          were already
                                                          aware of the
                                                          oauth-meta
                                                          proposal in
                                                          Darmstadt but
                                                          no one spoke
                                                          up in favor of
                                                          it that I can
                                                          recall. 
                                                          Rather, I
                                                          think people
                                                          were thinking
                                                          that “less is
                                                          moreâ€.

                                                          
 

                                                          
There

                                                          have also been
                                                          discussions in
                                                          the last day
                                                          about how
                                                          dynamically
                                                          returning a
                                                          resource URL,
                                                          which
                                                          oauth-meta
                                                          does, is both
                                                          unnecessary
                                                          (since the
                                                          client
                                                          initiated the
                                                          resource
                                                          authorization
                                                          already
                                                          knowing what
                                                          resource it
                                                          wants to
                                                          access) and
                                                          often
                                                          problematic,
                                                          since many
                                                          authorization
                                                          servers can
                                                          authorize
                                                          access to
                                                          multiple
                                                          resources.  If
                                                          anything, the
                                                          client should
                                                          be telling the
                                                          authorization
                                                          server what
                                                          resource it
                                                          wants to
                                                          access – not
                                                          the other way
                                                          around.

                                                          
 

                                                          
I’m

                                                          not saying
                                                          that there
                                                          aren’t some
                                                          good ideas in
                                                          the oauth-meta
                                                          draft – I’m
                                                          sure there
                                                          are, just as
                                                          there are in
                                                          the approach
                                                          designed by
                                                          the
                                                          participants
                                                          in Darmstadt. 
                                                          While I
                                                          volunteered to
                                                          write the
                                                          first draft of
                                                          the
                                                          mix-up-mitigation
                                                          approach, it
                                                          really
                                                          reflects
                                                          something a
                                                          lot of people
                                                          have already
                                                          bought into –
                                                          as evidenced
                                                          in the passion
                                                          in the
                                                          high-volume
                                                          “Mix-Up About
                                                          The Mix-Up
                                                          Mitigationâ€
                                                          thread, and
                                                          not just my
                                                          personal
                                                          project.

                                                          
 

                                                          
If

                                                          you think
                                                          there are
                                                          things missing
                                                          or wrong in
                                                          the
                                                          mix-up-mitigation
                                                          draft, please
                                                          say what they
                                                          are.  That
                                                          will help us
                                                          quickly
                                                          converge on a
                                                          solution that
                                                          will work for
                                                          everyone.

                                                          
 

                                                          
                                                         

                                                          Sincerely,

                                                          
                                                         

                                                          -- Mike

                                                          
 

                                                          
From: Nat
                                                          Sakimura [mailto:sakimura@gmail.com]
                                                          

                                                          Sent:
                                                          Wednesday,
                                                          January 20,
                                                          2016 11:17 PM

                                                          To:
                                                          Mike Jones
                                                          <Michael.Jones@microsoft.com>;

                                                          William
                                                          Denniss <wdenniss@google.com>;

                                                          Justin Richer
                                                          <jricher@mit.edu>

                                                          Cc: oauth@ietf.org

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          Call for
                                                          Adoption

                                                          
 

                                                          

                                                          
Hi

                                                          Mike. 

                                                          

                                                          
 

                                                          

                                                          

                                                          
Conversely,

                                                          I would like
                                                          to ask why
                                                          this approach
                                                          does not work
                                                          for Mix-up
                                                          attack. As Nov
                                                          stated, we in
                                                          fact have
                                                          discussed the
                                                          approach in
                                                          quite a length
                                                          back in
                                                          Yokohama. I
                                                          really would
                                                          like to know
                                                          why it does
                                                          not work. 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
Besides,

                                                          for oauth-meta
                                                          approach,
                                                          mix-up attack
                                                          is only one of
                                                          the thing it
                                                          solves. 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
Nat

                                                          Sakimura

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
2016年1月21日(木)
                                                          16:02 Mike
                                                          Jones <Michael.Jones@microsoft.com>:

                                                          

                                                          

                                                          

                                                          

                                                          
Not

                                                          to be
                                                          negative, but
                                                          I disagree
                                                          with adopting
                                                          draft-sakimura-oauth-meta. 

                                                          We should
                                                          define and
                                                          promote one
                                                          mitigation
                                                          approach to
                                                          the mix-up
                                                          attacks. 
                                                          Having two
                                                          would confuse
                                                          implementers
                                                          and cause
                                                          compatibility
                                                          problems –
                                                          reducing
                                                          overall
                                                          security.

                                                          
 

                                                          
The

                                                          approach
                                                          defined in
                                                          draft-jones-oauth-mix-up-mitigation
                                                          was created in
                                                          collaboration
                                                          with the
                                                          security
                                                          researchers
                                                          who identified
                                                          the problems
                                                          in the first
                                                          place, was
                                                          vigorously
                                                          discussed in
                                                          the security
                                                          meeting Hannes
                                                          and Torsten
                                                          held in
                                                          Darmstadt, and
                                                          has been since
                                                          refined based
                                                          on substantial
                                                          input from the
                                                          working
                                                          group.  And at
                                                          least three
                                                          implementers
                                                          have already
                                                          stated that
                                                          they’ve
                                                          implemented
                                                          it.  I’m not
                                                          saying that
                                                          it’s, but if
                                                          there are
                                                          things missing
                                                          or things that
                                                          need to be
                                                          improved in
                                                          our approach,
                                                          we should do
                                                          it there,
                                                          rather
                                                          introducing a
                                                          competing
                                                          approach.

                                                          
 

                                                          
Also,

                                                          standard OAuth
                                                          deployments
                                                          register the
                                                          client and
                                                          then use the
                                                          information
                                                          gathered at
                                                          registration
                                                          time for
                                                          subsequent
                                                          protocol
                                                          interactions. 
                                                          They do not
                                                          need all the
                                                          configuration
                                                          information
                                                          for the
                                                          authorization
                                                          server to be
                                                          retransmitted
                                                          at runtime. 
                                                          The oauth-meta
                                                          draft goes too
                                                          far in that
                                                          direction, at
                                                          least as I see
                                                          it.  Returning
                                                          things two
                                                          ways creates
                                                          its own
                                                          problems, as
                                                          discussed in
                                                          the Duplicate
                                                          Information
                                                          Attacks
                                                          security
                                                          considerations
                                                          section (7.2)
                                                          of the
                                                          mix-up-mitigation
                                                          draft.

                                                          
 

                                                          
I’ll

                                                          note that the
                                                          mix-up-mitigation

                                                          approach is
                                                          compatible
                                                          with existing
                                                          practice in
                                                          both static
                                                          and dynamic
                                                          metadata
                                                          discovery. 
                                                          Replying to
                                                          Justin’s
                                                          comment that “It's

                                                          the
                                                          pre-configured
                                                          discovery
                                                          document
                                                          that's at the
                                                          root of the
                                                          mix-up attack
                                                          in the first
                                                          placeâ€
                                                          – this is not
                                                          the case.  The
                                                          attacks can be
                                                          performed
                                                          without either
                                                          discovery or
                                                          dynamic
                                                          registration.

                                                          
 

                                                          
I
                                                          would be
                                                          interested in
                                                          hearing a
                                                          technical
                                                          discussion on
                                                          whether there
                                                          are aspects of
                                                          the oauth-meta
                                                          approach that
                                                          mitigate
                                                          aspects of the
                                                          attacks that
                                                          the
                                                          mix-up-mitigation
                                                          approach does
                                                          not.  That
                                                          could help
                                                          inform whether
                                                          there are
                                                          additional
                                                          things we
                                                          should add to
                                                          or change in
                                                          the mix-up
                                                          draft.

                                                          
 

                                                          
                                                         

                                                          -- Mike

                                                          
 

                                                          
From:
                                                          OAuth [mailto:oauth-bounces@ietf.org]
                                                          On Behalf
                                                          Of William

                                                          Denniss

                                                          Sent:
                                                          Wednesday,
                                                          January 20,
                                                          2016 10:37 PM

                                                          To:
                                                          Justin Richer
                                                          <jricher@mit.edu>

                                                          Cc: oauth@ietf.org

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          Call for
                                                          Adoption

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          
+1

                                                          to adopt this,
                                                          and I agree
                                                          with Justin's
                                                          comments.

                                                          

                                                          
 

                                                          

                                                          
On

                                                          Wed, Jan 20,
                                                          2016 at 9:53
                                                          PM, Justin
                                                          Richer <jricher@mit.edu>

                                                          wrote:

                                                          

                                                          

                                                          
+1

                                                          

                                                          Inline
                                                          discovery and
                                                          pre-configured
                                                          discovery (ie,
                                                          .well-known)
                                                          should at the
                                                          very least be
                                                          compatible and
                                                          developed
                                                          together. It's
                                                          the
                                                          pre-configured
                                                          discovery
                                                          document
                                                          that's at the
                                                          root of the
                                                          mix-up attack
                                                          in the first
                                                          place.

                                                          

                                                           -- Justin

                                                          

                                                          

                                                          
 

                                                          

                                                          
On

                                                          1/19/2016
                                                          10:30 PM, Nat
                                                          Sakimura
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Just

                                                          to give more
                                                          context, at
                                                          IETF 94, I
                                                          have done a
                                                          presentation
                                                          on discovery. 
                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
According

                                                          to the
                                                          minutes, 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
    (f) Discovery (Nat)

                                                          
          

                                                          
             Nat explains his document as an example of the work that has to be done

                                                          
             in the area of discovery, which is a topic that has been identified

                                                          
             as necessary for interoperability since many years but so far there

                                                          
             was not time to work on it. Mike, John and Nat are working on a new

                                                          
             document that describes additional discovery-relevant components.

                                                          
          

                                                          
             Poll: 19 for / zero against / 4 persons need more information.

                                                          
 

                                                          
The

                                                          document
                                                          discussed
                                                          there was 
                                                          https://tools.ietf.org/html/draft-sakimura-oauth-meta-05.
                                                          This is a
                                                          simple (only
                                                          1-page!) but a
                                                          very powerful
                                                          document that
                                                          nudges towards
                                                          HATEOAS which
                                                          is at the core
                                                          of
                                                          RESTful-ness.
                                                          It also
                                                          mitigates the
                                                          Mix-up attack
                                                          without
                                                          introducing
                                                          the concept of
                                                          issuer which
                                                          is not in
                                                          RFC6749. It is
                                                          also good for
                                                          selecting
                                                          different
                                                          endpoints
                                                          depending on
                                                          the user
                                                          authentication
                                                          and
                                                          authorization
                                                          results and
                                                          more privacy
                                                          sensitive than
                                                          pre-announced
                                                          Discovery
                                                          document. It
                                                          also allows
                                                          you to find to
                                                          which
                                                          protected
                                                          resource
                                                          endpoint you
                                                          can use the
                                                          access token
                                                          against. 

                                                          

                                                          

                                                          
 

                                                          

                                                          
In

                                                          the last
                                                          sentence of
                                                          the minutes,
                                                          it talks about
                                                          "a new
                                                          document that
                                                          describes
                                                          additional
                                                          discovery-relevant
                                                          components".
                                                          This is https://tools.ietf.org/html/draft-jones-oauth-discovery-00. 


                                                          It went for
                                                          the call for
                                                          adoption.
                                                          However, it is
                                                          only a half of
                                                          the story. I
                                                          believe https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that

                                                          was discussed
                                                          at IETF 94 and
                                                          had support
                                                          there should
                                                          be adopted as
                                                          well.  

                                                          

                                                          
 

                                                          

                                                          

                                                          
Nat

                                                          Sakimura

                                                          

                                                          
 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
2016年1月20日(水)
                                                          12:05 Nat
                                                          Sakimura <sakimura@gmail.com>:

                                                          

                                                          

                                                          

                                                          
Thanks

                                                          Hannes.  

                                                          

                                                          
 

                                                          

                                                          

                                                          
I
                                                          did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which

                                                          was discussed
                                                          in Yokohama,
                                                          and was
                                                          largely in
                                                          agreement if
                                                          my
                                                          recollection
                                                          is correct.
                                                          Why is it not
                                                          in the call
                                                          for adoption? 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          
2016å¹´1月19æ—¥(ç«)
                                                          20:39 Hannes
                                                          Tschofenig
                                                          <hannes.tschofenig@gmx.net>:

                                                          

                                                          

                                                          

                                                          

                                                          
Hi

                                                          all,

                                                          

                                                          we have
                                                          submitted our
                                                          new charter to
                                                          the IESG (see

                                                          http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html)
                                                          and

                                                          since some
                                                          IESG members
                                                          like to see an
                                                          updated list
                                                          of milestones
                                                          as

                                                          well. For this
                                                          reason, based
                                                          on a
                                                          suggestion
                                                          from Barry, we
                                                          are also

                                                          starting a
                                                          call for
                                                          adoption
                                                          concurrently
                                                          with the
                                                          review of the
                                                          charter

                                                          text by the
                                                          IESG.

                                                          

                                                          We will post
                                                          separate mails
                                                          on the
                                                          individual
                                                          documents.
                                                          Your feedback

                                                          is important!
                                                          Please take
                                                          the time to
                                                          look at the
                                                          documents and
                                                          provide

                                                          your feedback.

                                                          

                                                          Ciao

                                                          Hannes &
                                                          Derek

                                                          

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          
_______________________________________________

                                                          
OAuth mailing list

                                                          
OAuth@ietf.org

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

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          


_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          

                                                          

                                                          
 

                                                          

                                                          

                                                          

                                                          

                                                          
_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

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

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
 

                                                          

                                                        

                                                      

                                                    

                                                  

                                                

                                              

                                            

                                          

                                        

                                        


_______________________________________________

                                          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


              

              

            

          

        

        

      

    

    

    
-- 
Chief Architect                   
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  


--------------070007090200040301030004--


From nobody Tue Jan 26 11:35:44 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719111B2BFF for ; Tue, 26 Jan 2016 11:35:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3J9hs1YDcRQ for ; Tue, 26 Jan 2016 11:35:40 -0800 (PST)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9DE1B2BFA for ; Tue, 26 Jan 2016 11:35:40 -0800 (PST)
Received: from [79.218.87.147] (helo=[192.168.71.102]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aO9OL-0000eM-Va; Tue, 26 Jan 2016 20:35:06 +0100
To: Hannes Tschofenig , "oauth@ietf.org" 
References: <569E2298.3010508@gmx.net>
From: Torsten Lodderstedt 
Message-ID: <56A7CA7D.3050602@lodderstedt.net>
Date: Tue, 26 Jan 2016 20:35:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <569E2298.3010508@gmx.net>
Content-Type: multipart/alternative; boundary="------------030006050304080801010800"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 19:35:43 -0000

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

Hi,

I support the adoption of this document as starting point for our work 
towards OAuth discovery.

Restating what I already posted after the last IETF meeting: It seems 
the document assumes the AS can always be discoverd using the user id of 
the resource owner. I think the underlying assumption is resource 
servers accept access token of different (any?) user specific AS (and 
OP)? From my perspective, RSs nowadays typically trust _the_ AS of their 
security domain/ecosystem and all resource owners need to have an user 
account with this particular AS. So I would assume the process to start 
at the RS. I think the spec needs to cover the latter case as well.

kinds regards,
Torsten.

Am 19.01.2016 um 12:48 schrieb Hannes Tschofenig:
> Hi all,
>
> this is the call for adoption of OAuth 2.0 Discovery, see
> https://tools.ietf.org/html/draft-jones-oauth-discovery-00
>
> Please let us know by Feb 2nd whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>
> Note: If you already stated your opinion at the IETF meeting in Yokohama
> then you don't need to re-state your opinion, if you want.
>
> The feedback at the Yokohama IETF meeting was the following: 19 for /
> zero against / 4 persons need more information.
>
> Ciao
> Hannes & Derek
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------030006050304080801010800
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi,

    

    I support the adoption of this document as starting point for our
    work towards OAuth discovery.

    

    Restating what I already posted after the last IETF meeting: It
    seems the document assumes the AS can always be discoverd using the
    user id of the resource owner. I think the underlying assumption is
    resource servers accept access token of different (any?) user
    specific AS (and OP)? From my perspective, RSs nowadays typically
    trust _the_ AS of their security domain/ecosystem and all resource
    owners need to have an user account with this particular AS. So I
    would assume the process to start at the RS. I think the spec needs
    to cover the latter case as well. 

    

    kinds regards,

    Torsten.

    

    
Am 19.01.2016 um 12:48 schrieb Hannes
      Tschofenig:

    

    

      
Hi all,

this is the call for adoption of OAuth 2.0 Discovery, see
https://tools.ietf.org/html/draft-jones-oauth-discovery-00

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

Note: If you already stated your opinion at the IETF meeting in Yokohama
then you don't need to re-state your opinion, if you want.

The feedback at the Yokohama IETF meeting was the following: 19 for /
zero against / 4 persons need more information.

Ciao
Hannes & Derek



      

      

      

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


    

    

  


--------------030006050304080801010800--


From nobody Tue Jan 26 11:44:11 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6911B2C26 for ; Tue, 26 Jan 2016 11:44:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level: 
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py7niBES0Ess for ; Tue, 26 Jan 2016 11:44:01 -0800 (PST)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FEB11B2C27 for ; Tue, 26 Jan 2016 11:44:01 -0800 (PST)
Received: by mail-io0-x231.google.com with SMTP id 77so197225042ioc.2 for ; Tue, 26 Jan 2016 11:44:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wpHOu/2r7EUYW7dYg10gHbjZ/LlNR/CzZ0b5WvEHKVw=; b=Vc8u7d6KmVROiF0c6TjbPZuRyosTBvGnKTqzEdVmkOSxlP8NFeXw9oeuA6p+VZ0Hgl L3hG+9Y5ElbMDAA55TMkVL4H9MBcuekyyyMLxfl4MKvkLhNyP4gA4q2vn/y6L6+rfoPA 0Nl7yet5tpUicElAz8xIqDu/qTD3Or8bkp4qo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wpHOu/2r7EUYW7dYg10gHbjZ/LlNR/CzZ0b5WvEHKVw=; b=RlkiKjyaLy3dIyUJnlrEYU5m8BxVRyIx+pl6bya4hTq03JOeuPuKUt9eNLr5bQ/8t0 ypCNIsiKqZCea3pI10FapF0iS9TuOd7q7Un1+kSWsdZ3JT+mLKOYuxT8gFXD21CLlzMX n38//gEYnN8NDaS0GpJQWOI6BAZTC0ZsmBoF2K12k5L+bB2B+XQMXrvHYM/9JtQnFUGT T0Pk7HUR+rRpAhRnyPG11EYDFJa37bv2b0OdteMmcXBtzTO5YG9yw8zu4qkr2DKn9ZSS rq8hVuCprzJmlUEIjm+BKwqYpL00m/Wwbq7DmH0Xc1PPRjG97lDWsa4YYjqBq1uQacpu F3BA==
X-Gm-Message-State: AG10YOThaqDAwg+BxoOgfD6rwsxV14K36w9OefozfnYxPPlc3jlo3OOVINHY50DUQBBXjh+j18rpk/ddoOMTL1+s
X-Received: by 10.107.16.226 with SMTP id 95mr27977429ioq.147.1453837440588; Tue, 26 Jan 2016 11:44:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.212.69 with HTTP; Tue, 26 Jan 2016 11:43:30 -0800 (PST)
In-Reply-To: <56A7C3E8.8080601@aol.com>
References: <569E2076.2090405@gmx.net>             <56A78EEF.4090706@aol.com>  <56A7C3E8.8080601@aol.com>
From: Brian Campbell 
Date: Tue, 26 Jan 2016 12:43:30 -0700
Message-ID: 
To: George Fletcher 
Content-Type: multipart/alternative; boundary=001a113ecda0356dda052a41e812
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 19:44:09 -0000

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

I understand what you're saying but disagree with the premise.

On Tue, Jan 26, 2016 at 12:07 PM, George Fletcher  wrote:

> So I'm fine with not requiring discovery in the simple case of an RS
> supporting a single AS. However, once the RS moves to supporting multiple
> authorization servers then I believe that discovery based on the 'iss'
> string is required. The discovery results can be cached so a discovery
> lookup per transaction is not required.
>
> Thanks,
> George
>
> On 1/26/16 1:58 PM, Brian Campbell wrote:
>
> I'm staying that it's sufficiently unlikely that it shouldn't be part of
> the threat model and that a discovery lookup on iss isn't necessary.
>
>
>
> On Tue, Jan 26, 2016 at 8:21 AM, George Fletcher  wrote=
:
>
>> While it's a different way of getting the endpoints mixed up, I don't
>> think that makes it invalid. If we are going to address the attack vecto=
r I
>> believe we should solve it for "all" cases not just the ones that seem m=
ost
>> likely.
>>
>> Thanks,
>> George
>>
>> On 1/26/16 8:37 AM, Brian Campbell wrote:
>>
>> I'm not sure what's described in the blog post is actually a variant of
>> an attack that anyone is really concerned about? A client developer woul=
d
>> have to change a production system to use an unfamiliar value for the to=
ken
>> endpoint based solely on a an email without even looking at service
>> documentation or metadata.
>>
>>
>> On Fri, Jan 22, 2016 at 6:29 PM, Nat Sakimura < 
>> sakimura@gmail.com> wrote:
>>
>>> I wrote a blog on why the current mix-up draft approach does not solve
>>> the issue.
>>>
>>>
>>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rf=
c6749/
>>>
>>> Hopefully, the point I am making is clearer by this.
>>>
>>> Best,
>>>
>>> Nat
>>>
>>> 2016=E5=B9=B41=E6=9C=8823=E6=97=A5(=E5=9C=9F) 8:32 Mike Jones :
>>>
>>>> I like the =E2=80=9Cfrom which the authorization server's configuratio=
n
>>>> information location can be derived=E2=80=9D language.  Thanks.  I=E2=
=80=99ll plan to
>>>> incorporate that the next time the draft is revised.
>>>>
>>>>
>>>>
>>>>                                                                 -- Mik=
e
>>>>
>>>>
>>>>
>>>> *From:* Brian Campbell [mailto: 
>>>> bcampbell@pingidentity.com]
>>>> *Sent:* Friday, January 22, 2016 3:26 PM
>>>> *To:* Nat Sakimura < sakimura@gmail.com>
>>>> *Cc:* Mike Jones < 
>>>> Michael.Jones@microsoft.com>; Justin Richer < 
>>>> jricher@mit.edu>;  
>>>>
>>>>
>>>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>>>
>>>>
>>>>
>>>> I agree that the language describing OAuth issuer could and should be
>>>> improved. The text now reads like it is the exact and full URL where t=
he
>>>> metadata/discovery document is located. Perhaps something more like "t=
he
>>>> URL from which the authorization server's configuration information
>>>> location can be derived" and explain that adding the .well-known bits =
to
>>>> the issuer is where the configuration information can actually be foun=
d.
>>>>
>>>>
>>>>
>>>> On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura < 
>>>> sakimura@gmail.com> wrote:
>>>>
>>>> Re: iss. I discussed this a bit with Nov in more details. It probably
>>>> is a sloppy language of the specs that is making it difficult to read =
what
>>>> you wanted to achieve.
>>>>
>>>>
>>>>
>>>> In mix-up-mitigation draft, OAuth issuer is "the URL of the
>>>> authorization server's configuration information location". In OAuth
>>>> discovery draft, there is something called "OAuth 2.0 Configuration
>>>> Information Location URL", which is equal to "OpenID Connect Issuer".
>>>>
>>>> When I wrote the statement, I thought you were pointing to the URL tha=
t
>>>> you can actually pull the configuration information by "the URL of the
>>>> authorizaiton server's configuration information location" since other=
wise
>>>> you would have used the term "OAuth 2.0 Configuration Information Loca=
tion
>>>> URL". But after all, you probably meant these two are the same. Then I
>>>> would strongly recommend to fix the language.
>>>>
>>>> Now, even If that is the case, the relationship like
>>>>
>>>> =C2=B7         iss + .well-know/openid-configuration =3D Connect OP co=
nfig
>>>> endoint
>>>>
>>>> =C2=B7         OAuth config endpoint - .well-known/openid-configuratio=
n =3D
>>>> OAuth iss
>>>>
>>>> is very confusing.
>>>>
>>>>
>>>>
>>>> You also claim that your approach is simpler, but to me, your approach
>>>> seem to be overly complex. It requires discovery and the check for the
>>>> value of the discovered config information to work as the mitigation.
>>>> (Right. Draft -01 does not have it, so it does not solve the mix-up is=
sue.)
>>>> With oauth-meta, you do not need it.
>>>>
>>>>
>>>>
>>>> Finally, your point that HATEOAS reminds you of WSDL, it is not. If yo=
u
>>>> want to have something similar to WSDL in REST API area, it is Swagger=
.
>>>> (Actually, it is gaining a lot of momentum recently, but that's beside=
 the
>>>> fact ;-). And the point here is not the format but the fact that we ne=
ed to
>>>> have a way to associate metadata to the data. The root cause of this m=
ix-up
>>>> attack is that the metadata and data is not associated properly. We ha=
ve a
>>>> standard way of associating the data and metadata with link-rel such a=
s
>>>> RFC5988 so why not use it? Link-rel-href pattern is used a lot now. Mo=
st
>>>> modern web pages actually have it. Using a proper way to associate met=
adata
>>>> with data will save you from a lot of other attacks in the future. Ins=
tead
>>>> of doing patch works, we should solve it architecturally.
>>>>
>>>>
>>>>
>>>> Nat
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 10:34 Mike Jones < 
>>>> Michael.Jones@microsoft.com>:
>>>>
>>>> Nat, I=E2=80=99m confused by this statement in the message you referen=
ce =E2=80=9CUnfortunately,
>>>> this does not match the value of OAuth issuer defined in Section 2
>>>> of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as
>>>> specified in 3.1. As such, validation as specified in bullet 1 of Sect=
ion 4
>>>> fails in Google's case -- OR it means that the document is internally
>>>> inconsistent.=E2=80=9D.  The issuer definition in draft-jones-oauth-di=
scovery
>>>> is 100% compatible with the one in OpenID Connect Discovery, by design=
.  In
>>>> the Google example, both the OpenID issuer and the OAuth issuer values
>>>> would be the string =E2=80=9C 
>>>> https://accounts.google.com=E2=80=9D.  What is the inconsistency that =
you
>>>> perceive?
>>>>
>>>>
>>>>
>>>> The discussion of the duplication problem happened in the private
>>>> meetings in Yokohama.
>>>>
>>>>
>>>>
>>>> I will admit, in Yokohama, I didn=E2=80=99t speak up in the public mee=
tings to
>>>> point out that a simpler alternative to oauth-meta was already being
>>>> discussed there in private, because then I would have had to talk abou=
t the
>>>> security issues, which we=E2=80=99d decided not to publicly do at that=
 point.  So I
>>>> stayed silent during the poll, out of politeness.  Perhaps I should ha=
ve
>>>> found a way to say something then anyway, but that=E2=80=99s water und=
er the bridge
>>>> now.
>>>>
>>>>
>>>>
>>>> Finally, for what it=E2=80=99s worth, the HATEOAS stuff reminds me far=
 too much
>>>> of Web Services Description Language (WSDL) =E2=80=93 part of the comp=
lexity
>>>> baggage that helped sink Web Services.  The use of =E2=80=9Clink rel=
=E2=80=9D to define an
>>>> interaction vocabulary and publish endpoints for that vocabulary seems
>>>> pretty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=
=80=93 another cute =E2=80=9CWebby=E2=80=9D
>>>> innovation that never caught on.  The industry has pretty much voted w=
ith
>>>> its feet and is using JSON for publishing discovery data structures =
=E2=80=93 not
>>>> =E2=80=9Clink rel=E2=80=9D.  I am against us reverting to the =E2=80=
=9Clink rel=E2=80=9D proposal from 2008
>>>> that never caught on when JSON is simpler and does a better job.
>>>>
>>>>
>>>>
>>>>                                                                 -- Mik=
e
>>>>
>>>>
>>>>
>>>> *From:* Nat Sakimura [mailto: sakimura@gmail.com]
>>>> *Sent:* Thursday, January 21, 2016 6:24 AM
>>>> *To:* Justin Richer < jricher@mit.edu>; Mike Jones <
>>>> Michael.Jones@microsoft.com>
>>>> *Cc:* William Denniss < wdenniss@google.com>; <
>>>> oauth@ietf.org> < oauth@ietf.org>
>>>>
>>>>
>>>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>>>
>>>>
>>>>
>>>> Mike,
>>>>
>>>>
>>>>
>>>> You just criticize my draft. That's ok, but I would really like to get
>>>> some response to my questions stated in
>>>> 
>>>> https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To
>>>> me, it just does not seem to work, and the combination of the oauth-me=
ta
>>>> and PKCE seems to be much more elegan, nicer, and much simpler to
>>>> implement. If you just give up the dynamic response at the authorizati=
on
>>>> endpoint, then you even do not have to touch the code but just change =
a
>>>> config file.
>>>>
>>>>
>>>>
>>>> Please convince me by answering to my questions.
>>>>
>>>>
>>>>
>>>> For the record of Yokohama, I do not recall much about duplication in
>>>> OAuth session. The poll in the room was 19 for / zero against / 4
>>>> persons need more information. Indeed, it is not duplicating much. And=
 if
>>>> you move to a new model without pre-configured discovery, it is not
>>>> duplicating any but the resource endpoint URI, which is optional and i=
s for
>>>> the cases where the client did not know the concrete resource endpoint=
 to
>>>> start with.
>>>>
>>>>
>>>>
>>>> I understand your usecases always start from a concrete endpoint
>>>> location. Mine do not. In a four party model, it is likely not. The us=
er
>>>> just want to have the service to fetch his data from some resource
>>>> endpoint. He just hits the service. He does not hit the resource endpo=
int
>>>> directly. For example, in the case of a consumer using a personal fina=
nce
>>>> platform (PFP)to manage his pension fund, he hits the PFP and not the
>>>> Pension fund. Assuming that the pension fund has delegated the
>>>> authorization control to the authorization server, then, the authoriza=
tion
>>>> server should return both the access token and the endpoint of the pen=
sion
>>>> fund so that the PFP can pull the data using them. A similar model hol=
ds
>>>> for personal health service and health care providers.
>>>>
>>>>
>>>>
>>>> Best,
>>>>
>>>>
>>>>
>>>> Nat
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 21:18 Justin Richer < jricher@mit.edu>:
>>>>
>>>> Convergence is exactly what I=E2=80=99m arguing for, though. These thi=
ngs ought
>>>> to work together.
>>>>
>>>>
>>>>
>>>>  =E2=80=94 Justin
>>>>
>>>>
>>>>
>>>> On Jan 21, 2016, at 2:55 AM, Mike Jones < 
>>>> Michael.Jones@microsoft.com> wrote:
>>>>
>>>>
>>>>
>>>> My memory of the discussions of the oauth-meta draft in Yokohama were
>>>> that many people felt that it was unnecessarily dynamically duplicatin=
g a
>>>> lot of information that the client already had.  Most of us that were =
aware
>>>> of the attacks then were in favor of a more targeted, minimal approach=
.
>>>> You were listened to in Yokohama, but that didn=E2=80=99t necessarily =
mean that
>>>> people agreed with the approach.  Participants were already aware of t=
he
>>>> oauth-meta proposal in Darmstadt but no one spoke up in favor of it th=
at I
>>>> can recall.  Rather, I think people were thinking that =E2=80=9Cless i=
s more=E2=80=9D.
>>>>
>>>>
>>>>
>>>> There have also been discussions in the last day about how dynamically
>>>> returning a resource URL, which oauth-meta does, is both unnecessary (=
since
>>>> the client initiated the resource authorization already knowing what
>>>> resource it wants to access) and often problematic, since many
>>>> authorization servers can authorize access to multiple resources.  If
>>>> anything, the client should be telling the authorization server what
>>>> resource it wants to access =E2=80=93 not the other way around.
>>>>
>>>>
>>>>
>>>> I=E2=80=99m not saying that there aren=E2=80=99t some good ideas in th=
e oauth-meta
>>>> draft =E2=80=93 I=E2=80=99m sure there are, just as there are in the a=
pproach designed by
>>>> the participants in Darmstadt.  While I volunteered to write the first
>>>> draft of the mix-up-mitigation approach, it really reflects something =
a lot
>>>> of people have already bought into =E2=80=93 as evidenced in the passi=
on in the
>>>> high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D threa=
d, and not just my
>>>> personal project.
>>>>
>>>>
>>>>
>>>> If you think there are things missing or wrong in the mix-up-mitigatio=
n
>>>> draft, please say what they are.  That will help us quickly converge o=
n a
>>>> solution that will work for everyone.
>>>>
>>>>
>>>>
>>>>                                                           Sincerely,
>>>>
>>>>                                                           -- Mike
>>>>
>>>>
>>>>
>>>> *From:* Nat Sakimura [ mailto:sakimura@gmail.com
>>>> ]
>>>> *Sent:* Wednesday, January 20, 2016 11:17 PM
>>>> *To:* Mike Jones < 
>>>> Michael.Jones@microsoft.com>; William Denniss < 
>>>> wdenniss@google.com>; Justin Richer < jricher@mit.edu=
>
>>>> *Cc:* oauth@ietf.org
>>>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>>>
>>>>
>>>>
>>>> Hi Mike.
>>>>
>>>>
>>>>
>>>> Conversely, I would like to ask why this approach does not work for
>>>> Mix-up attack. As Nov stated, we in fact have discussed the approach i=
n
>>>> quite a length back in Yokohama. I really would like to know why it do=
es
>>>> not work.
>>>>
>>>>
>>>>
>>>> Besides, for oauth-meta approach, mix-up attack is only one of the
>>>> thing it solves.
>>>>
>>>>
>>>>
>>>> Nat Sakimura
>>>>
>>>>
>>>>
>>>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones < 
>>>> Michael.Jones@microsoft.com>:
>>>>
>>>> Not to be negative, but I disagree with adopting
>>>> draft-sakimura-oauth-meta.  We should define and promote one mitigatio=
n
>>>> approach to the mix-up attacks.  Having two would confuse implementers=
 and
>>>> cause compatibility problems =E2=80=93 reducing overall security.
>>>>
>>>>
>>>>
>>>> The approach defined in draft-jones-oauth-mix-up-mitigation was create=
d
>>>> in collaboration with the security researchers who identified the prob=
lems
>>>> in the first place, was vigorously discussed in the security meeting H=
annes
>>>> and Torsten held in Darmstadt, and has been since refined based on
>>>> substantial input from the working group.  And at least three implemen=
ters
>>>> have already stated that they=E2=80=99ve implemented it.  I=E2=80=99m =
not saying that it=E2=80=99s,
>>>> but if there are things missing or things that need to be improved in =
our
>>>> approach, we should do it there, rather introducing a competing approa=
ch.
>>>>
>>>>
>>>>
>>>> Also, standard OAuth deployments register the client and then use the
>>>> information gathered at registration time for subsequent protocol
>>>> interactions.  They do not need all the configuration information for =
the
>>>> authorization server to be retransmitted at runtime.  The oauth-meta d=
raft
>>>> goes too far in that direction, at least as I see it.  Returning thing=
s two
>>>> ways creates its own problems, as discussed in the Duplicate Informati=
on
>>>> Attacks security considerations section (7.2) of the mix-up-mitigation
>>>> draft.
>>>>
>>>>
>>>>
>>>> I=E2=80=99ll note that the mix-up-mitigation approach is compatible wi=
th
>>>> existing practice in both static and dynamic metadata discovery.  Repl=
ying
>>>> to Justin=E2=80=99s comment that =E2=80=9CIt's the pre-configured disc=
overy document
>>>> that's at the root of the mix-up attack in the first place=E2=80=9D =
=E2=80=93 this is
>>>> not the case.  The attacks can be performed without either discovery o=
r
>>>> dynamic registration.
>>>>
>>>>
>>>>
>>>> I would be interested in hearing a technical discussion on whether
>>>> there are aspects of the oauth-meta approach that mitigate aspects of =
the
>>>> attacks that the mix-up-mitigation approach does not.  That could help
>>>> inform whether there are additional things we should add to or change =
in
>>>> the mix-up draft.
>>>>
>>>>
>>>>
>>>>                                                           -- Mike
>>>>
>>>>
>>>>
>>>> *From:* OAuth [mailto: oauth-bounces@ietf.org]=
 *On
>>>> Behalf Of *William Denniss
>>>> *Sent:* Wednesday, January 20, 2016 10:37 PM
>>>> *To:* Justin Richer < jricher@mit.edu>
>>>> *Cc:* oauth@ietf.org
>>>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>>>
>>>>
>>>>
>>>> +1 to adopt this, and I agree with Justin's comments.
>>>>
>>>>
>>>>
>>>> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer < 
>>>> jricher@mit.edu> wrote:
>>>>
>>>> +1
>>>>
>>>> Inline discovery and pre-configured discovery (ie, .well-known) should
>>>> at the very least be compatible and developed together. It's the
>>>> pre-configured discovery document that's at the root of the mix-up att=
ack
>>>> in the first place.
>>>>
>>>>  -- Justin
>>>>
>>>>
>>>>
>>>> On 1/19/2016 10:30 PM, Nat Sakimura wrote:
>>>>
>>>> Just to give more context, at IETF 94, I have done a presentation on
>>>> discovery.
>>>>
>>>>
>>>>
>>>> According to the minutes,
>>>>
>>>>
>>>>
>>>>     (f) Discovery (Nat)
>>>>
>>>>
>>>>
>>>>              Nat explains his document as an example of the work that =
has to be done
>>>>
>>>>              in the area of discovery, which is a topic that has been =
identified
>>>>
>>>>              as necessary for interoperability since many years but so=
 far there
>>>>
>>>>              was not time to work on it. Mike, John and Nat are workin=
g on a new
>>>>
>>>>              document that describes additional discovery-relevant com=
ponents.
>>>>
>>>>
>>>>
>>>>              Poll: 19 for / zero against / 4 persons need more informa=
tion.
>>>>
>>>>
>>>>
>>>> The document discussed there was
>>>> 
>>>> 
>>>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
>>>> simple (only 1-page!) but a very powerful document that nudges towards
>>>> HATEOAS which is at the core of RESTful-ness. It also mitigates the Mi=
x-up
>>>> attack without introducing the concept of issuer which is not in RFC67=
49.
>>>> It is also good for selecting different endpoints depending on the use=
r
>>>> authentication and authorization results and more privacy sensitive th=
an
>>>> pre-announced Discovery document. It also allows you to find to which
>>>> protected resource endpoint you can use the access token against.
>>>>
>>>>
>>>>
>>>> In the last sentence of the minutes, it talks about "a new document
>>>> that describes additional discovery-relevant components". This is
>>>> 
>>>> https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went
>>>> for the call for adoption. However, it is only a half of the story. I
>>>> believe  
>>>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was
>>>> discussed at IETF 94 and had support there should be adopted as well.
>>>>
>>>>
>>>>
>>>> Nat Sakimura
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura < 
>>>> sakimura@gmail.com>:
>>>>
>>>> Thanks Hannes.
>>>>
>>>>
>>>>
>>>> I did not find
>>>> 
>>>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, which was
>>>> discussed in Yokohama, and was largely in agreement if my recollection=
 is
>>>> correct. Why is it not in the call for adoption?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig =
< 
>>>> hannes.tschofenig@gmx.net>:
>>>>
>>>> Hi all,
>>>>
>>>> we have submitted our new charter to the IESG (see
>>>> 
>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
>>>> since some IESG members like to see an updated list of milestones as
>>>> well. For this reason, based on a suggestion from Barry, we are also
>>>> starting a call for adoption concurrently with the review of the chart=
er
>>>> text by the IESG.
>>>>
>>>> We will post separate mails on the individual documents. Your feedback
>>>> is important! Please take the time to look at the documents and provid=
e
>>>> your feedback.
>>>>
>>>> Ciao
>>>> Hannes & Derek
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> 
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> OAuth mailing list
>>>>
>>>> OAuth@ietf.org
>>>>
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> 
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> 
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>
>>
>>
>> _______________________________________________
>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oa=
uth
>>
>>
>>
>
> --
> Chief Architect
> Identity Services Engineering     Work: george.fletcher@teamaol.com
> AOL Inc.                          AIM:  gffletch
> Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
> Office: +1-703-265-2544           Photos: http://georgefletcher.photograp=
hy
>
>

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


I understand what you're saying but disagree with the =
premise.=C2=A0 

On Tue, Jan 26, 2016 at 12:07 PM, George Fletcher <gffletch@aol.com=
> wrote:

 =20
   =20
 =20
  

    So I'm fine with not
      requiring discovery in the simple case of an RS supporting a
      single AS. However, once the RS moves to supporting multiple
      authorization servers then I believe that discovery based on the
      'iss' string is required. The discovery results can be cached=
 so a
      discovery lookup per transaction is not required.

      

      Thanks,

      George

    

    
On 1/26/16 1:58 PM, Brian Campbell
      wrote:

    

    

      
I'm staying that it's sufficiently unlikely =
that it
        shouldn't be part of the threat model and that a discovery
        lookup on iss isn't necessary. 

        

        

      

      


        
On Tue, Jan 26, 2016 at 8:21 AM, George
          Fletcher <gffletch@aol.com>
          wrote:

          

            
 While it's a
                different way of getting the endpoints mixed up, I don'=
t
                think that makes it invalid. If we are going to address
                the attack vector I believe we should solve it for "al=
l"
                cases not just the ones that seem most likely.

                

                Thanks,

                George

              

              
On 1/26/16 8:37 AM, Brian Campbell wrote:

              

              

                
I'm not sure what's described in t=
he blog
                  post is actually a variant of an attack that anyone is
                  really concerned about? A client developer would have
                  to change a production system to use an unfamiliar
                  value for the token endpoint based solely on a an
                  email without even looking at service documentation or
                  metadata. 

                  


                  

                

                


                  
On Fri, Jan 22, 2016 at 6:29
                    PM, Nat Sakimura <sakimura@gmail.com>
                    wrote:

                    

                      
I wrote a blog on why the current
                        mix-up draft approach does not solve the issue.=C2=
=A0
                        


                        

                        
                        


                        

                        
Hopefully, the point I am making is clearer
                          by this.=C2=A0

                        


                        

                        
Best,=C2=A0

                        


                        

                        
Nat

                      

                      

                      

                        
2016=E5=B9=B41=E6=9C=8823=E6=97=A5=
(=E5=9C=9F) 8:32 Mike Jones
                          <Michael.Jones@microsoft.com>:

                        

                        

                          

                            

                              

                                

                                  
I
                                      like the =E2=80=9Cfrom which t=
he
                                    authorization server's configuratio=
n
                                    information location can be derived=E2=80=9D
                                      language.=C2=A0 Thanks.=C2=A0 I=E2=80=
=99ll plan to
                                      incorporate that the next time the
                                      draft is revised.

                                  
=C2=
=A0

                                  
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

                                      -- Mike

                                  
=C2=
=A0

                                  
From:
                                      Brian Campbell [mailto:bcampbell@pingidentity.com]
                                      

                                      Sent: Friday, January 22,
                                      2016 3:26 PM

                                      To: Nat Sakimura <sakimura@gmail.com>

                                      Cc: Mike Jones <Michael.Jones@microsoft.com=
>;

                                      Justin Richer <jricher@mit.edu>;

                                      <oauth@ietf.org>

                                      <oauth@ietf.org>

                                

                              

                              

                                

                                  


                                      Subject: Re: [OAUTH-WG]
                                      Call for Adoption

                                

                              

                              

                                

                                  
=C2=A0

                                  

                                    
I
                                      agree that the language describing
                                      OAuth issuer could and should be
                                      improved. The text now reads like
                                      it is the exact and full URL where
                                      the metadata/discovery document is
                                      located. Perhaps something more
                                      like "the URL from which the
                                      authorization server's
                                      configuration information location
                                      can be derived" and explain that
                                      adding the .well-known bits to the
                                      issuer is where the configuration
                                      information can actually be found.
                                      

                                    

                                  

                                  

                                    
=C2=A0

                                    

                                      
On Thu, Jan
                                        21, 2016 at 7:07 PM, Nat
                                        Sakimura <sakimura@gmail.com>

                                        wrote:

                                      

                                        

                                          
Re: iss.
                                            I discussed this a bit with
                                            Nov in more details. It
                                            probably is a sloppy
                                            language of the specs that
                                            is making it difficult to
                                            read what you wanted to
                                            achieve.=C2=A0

                                          

                                            
=C2=A0
                                          

                                          

                                            
In

                                                mix-up-mitigation draft,
                                                OAuth issuer is "the U=
RL
                                                of the authorization
                                                server's configuration
                                                information location".
                                                In OAuth discovery
                                                draft, there is
                                                something called "OAut=
h
                                                2.0 Configuration
                                                Information Location
                                                URL", which is equal t=
o
                                                "OpenID Connect
                                                Issuer".=C2=A0<=
/p>
                                            
When

                                                I wrote the statement, I
                                                thought you were
                                                pointing to the URL that
                                                you can actually pull
                                                the configuration
                                                information by "the UR=
L
                                                of the authorizaiton
                                                server's configuration
                                                information location"
                                                since otherwise you
                                                would have used the term
                                                "OAuth 2.0 Configurati=
on
                                                Information Location
                                                URL". But after all, y=
ou
                                                probably meant these two
                                                are the same. Then I
                                                would strongly recommend
                                                to fix the language.=C2=A0<=
/span>

                                            
Now,

                                                even If that is the
                                                case, the relationship
                                                like=C2=A0

                                            

                                              =C2=B7=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

                                                  iss

                                                +
                                                .well-know/openid-configura=
tion
                                                =3D Connect OP config
                                                endoint

                                            

                                              =C2=B7=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

                                                  OAuth

                                                config endpoint -
                                                .well-known/openid-configur=
ation
                                                =3D OAuth iss

                                            

                                              
is

                                                  very confusing.=C2=A0

                                            

                                          

                                          

                                            
=C2=A0
                                          

                                          

                                            
You

                                                also claim that your
                                                approach is simpler, but
                                                to me, your approach
                                                seem to be overly
                                                complex. It requires
                                                discovery and the check
                                                for the value of the
                                                discovered config
                                                information to work as
                                                the mitigation. (Right.
                                                Draft -01 does not have
                                                it, so it does not solve
                                                the mix-up issue.) With
                                                oauth-meta, you do not
                                                need it.=C2=A0

                                          

                                          

                                            
=C2=A0
                                          

                                          

                                            
Finally,

                                                your point that HATEOAS
                                                reminds you of WSDL, it
                                                is not. If you want to
                                                have something similar
                                                to WSDL in REST API
                                                area, it is Swagger.
                                                (Actually, it is gaining
                                                a lot of momentum
                                                recently, but that's
                                                beside the fact ;-). And
                                                the point here is not
                                                the format but the fact
                                                that we need to have a
                                                way to associate
                                                metadata to the data.
                                                The root cause of this
                                                mix-up attack is that
                                                the metadata and data is
                                                not associated properly.
                                                We have a standard way
                                                of associating the data
                                                and metadata with
                                                link-rel such as RFC5988
                                                so why not use it?
                                                Link-rel-href pattern is
                                                used a lot now. Most
                                                modern web pages
                                                actually have it. Using
                                                a proper way to
                                                associate metadata with
                                                data will save you from
                                                a lot of other attacks
                                                in the future. Instead
                                                of doing patch works, we
                                                should solve
                                                it=C2=A0architecturally.=C2=
=A0

                                          

                                          

                                            
=C2=A0
                                          

                                          

                                            
Nat

                                          

                                          

                                            
=C2=A0
                                          

                                          

                                            
=C2=A0
                                          

                                        

                                        
=C2=A0

                                        

                                          

                                            
2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=
=87=91)
                                              10:34 Mike Jones <Michael.Jones@microsoft=
.com>:

                                          

                                          

                                            

                                              

                                                

                                                  

                                                    
=
Nat,

                                                        I=E2=80=99m confuse=
d by
                                                        this statement
                                                        in the message
                                                        you reference =E2=
=80=9CUnfortunately, th=
is does not match
                                                        the value of
                                                        OAuth issuer
                                                        defined in
                                                        Section 2
                                                        of=C2=A0draft-jones=
-oauth-mix-up-mitigation-01
                                                        nor the 'iss=
9;
                                                        returned as
                                                        specified in
                                                        3.1.=C2=A0As such,
                                                        validation as
                                                        specified in
                                                        bullet 1 of
                                                        Section 4 fails
                                                        in Google's cas=
e
                                                        -- OR it means
                                                        that the
                                                        document is
                                                        internally
                                                        inconsistent.=E2=80=9D.=C2=A0

                                                        The issuer
                                                        definition in
                                                        draft-jones-oauth-d=
iscovery
                                                        is 100%
                                                        compatible with
                                                        the one in
                                                        OpenID Connect
                                                        Discovery, by
                                                        design.=C2=A0 In th=
e
                                                        Google example,
                                                        both the OpenID
                                                        issuer and the
                                                        OAuth issuer
                                                        values would be
                                                        the string =E2=80=
=9Chttps://accounts.google.com=
=E2=80=9D.=C2=A0

                                                        What is the
                                                        inconsistency
                                                        that you
                                                        perceive?
                                                    
=
=C2=A0

                                                    
=
The

                                                        discussion of
                                                        the duplication
                                                        problem happened
                                                        in the private
                                                        meetings in
                                                        Yokohama.
                                                    
=
=C2=A0

                                                    
=
I
                                                        will admit, in
                                                        Yokohama, I
                                                        didn=E2=80=99t spea=
k up
                                                        in the public
                                                        meetings to
                                                        point out that a
                                                        simpler
                                                        alternative to
                                                        oauth-meta was
                                                        already being
                                                        discussed there
                                                        in private,
                                                        because then I
                                                        would have had
                                                        to talk about
                                                        the security
                                                        issues, which
                                                        we=E2=80=99d decide=
d not
                                                        to publicly do
                                                        at that point.=C2=
=A0
                                                        So I stayed
                                                        silent during
                                                        the poll, out of
                                                        politeness.=C2=A0
                                                        Perhaps I should
                                                        have found a way
                                                        to say something
                                                        then anyway, but
                                                        that=E2=80=99s wate=
r
                                                        under the bridge
                                                        now.

                                                    
=
=C2=A0

                                                    
=
Finally,

                                                        for what it=E2=80=
=99s
                                                        worth, the
                                                        HATEOAS stuff
                                                        reminds me far
                                                        too much of Web
                                                        Services
                                                        Description
                                                        Language (WSDL)
                                                        =E2=80=93 part of t=
he
                                                        complexity
                                                        baggage that
                                                        helped sink Web
                                                        Services.=C2=A0 The
                                                        use of =E2=80=9Clin=
k
                                                        rel=E2=80=9D to def=
ine
                                                        an interaction
                                                        vocabulary and
                                                        publish
                                                        endpoints for
                                                        that vocabulary
                                                        seems pretty
                                                        baroque and
                                                        reminiscent of
                                                        =E2=80=9Cmicroforma=
ts=E2=80=9D =E2=80=93
                                                        another cute
                                                        =E2=80=9CWebby=E2=
=80=9D
                                                        innovation that
                                                        never caught
                                                        on.=C2=A0 The
                                                        industry has
                                                        pretty much
                                                        voted with its
                                                        feet and is
                                                        using JSON for
                                                        publishing
                                                        discovery data
                                                        structures =E2=80=
=93 not
                                                        =E2=80=9Clink rel=
=E2=80=9D.=C2=A0 I
                                                        am against us
                                                        reverting to the
                                                        =E2=80=9Clink rel=
=E2=80=9D
                                                        proposal from
                                                        2008 that never
                                                        caught on when
                                                        JSON is simpler
                                                        and does a
                                                        better job.<=
/p>
                                                    
=
=C2=A0

                                                    
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0

                                                        -- Mike

                                                    
=
=C2=A0

                                                    
=
From: Nat
                                                        Sakimura
                                                        [mailto:sakimura@gmail.com]
                                                        

                                                        Sent:
                                                        Thursday,
                                                        January 21, 2016
                                                        6:24 AM

                                                        To:
                                                        Justin Richer
                                                        <jricher@mit.edu>;
                                                        Mike Jones <Michael.Jones@micros=
oft.com>

                                                        Cc:
                                                        William Denniss
                                                        <wdenniss@google.com>;

                                                        <oauth@ietf.org> <oauth@ietf.org>

                                                  

                                                

                                                

                                                  

                                                    
=


                                                        Subject:
                                                        Re: [OAUTH-WG]
                                                        Call for
                                                        Adoption

                                                  

                                                

                                                

                                                  

                                                    
=
=C2=A0

                                                    

                                                      
Mike,=C2=A0

                                                      

                                                        
=C2=A0

                                                      

                                                      

                                                        
You

                                                          just criticize
                                                          my draft.
                                                          That's ok, bu=
t
                                                          I would really
                                                          like to get
                                                          some response
                                                          to my
                                                          questions
                                                          stated in=C2=A0https://www.ietf.org/mail-archi=
ve/web/oauth/current/msg15483.html=C2=A0.


                                                          To me, it just
                                                          does not seem
                                                          to work, and
                                                          the
                                                          combination of
                                                          the oauth-meta
                                                          and PKCE seems
                                                          to be much
                                                          more elegan,
                                                          nicer, and
                                                          much simpler
                                                          to implement.
                                                          If you just
                                                          give up the
                                                          dynamic
                                                          response at
                                                          the
                                                          authorization
                                                          endpoint, then
                                                          you even do
                                                          not have to
                                                          touch the code
                                                          but just
                                                          change a
                                                          config file.=C2=
=A0

                                                      

                                                      

                                                        
=C2=A0

                                                      

                                                      

                                                        
Please

                                                          convince me by
                                                          answering to
                                                          my questions.=C2=
=A0

                                                      

                                                      

                                                        
=C2=A0

                                                      

                                                      

                                                        
For

                                                          the record of
                                                          Yokohama, I do
                                                          not recall
                                                          much about
                                                          duplication in
                                                          OAuth session.
                                                          The poll in
                                                          the room was=C2=
=A019 for / zero against / 4 pe=
rsons
                                                          need more
                                                          information.
                                                          Indeed, it is
                                                          not
                                                          duplicating
                                                          much. And if
                                                          you move to a
                                                          new model
                                                          without
                                                          pre-configured
                                                          discovery, it
                                                          is not
                                                          duplicating
                                                          any but the
                                                          resource
                                                          endpoint URI,
                                                          which is
                                                          optional and
                                                          is for the
                                                          cases where
                                                          the client did
                                                          not know the
                                                          concrete
                                                          resource
                                                          endpoint to
                                                          start with.=C2=A0=


                                                      

                                                      

                                                        
=C2=A0

                                                      

                                                      

                                                        
I understand your usecases =
always
                                                          start from a
                                                          concrete
                                                          endpoint
                                                          location. Mine
                                                          do not. In a
                                                          four party
                                                          model, it is
                                                          likely not.
                                                          The user just
                                                          want to have
                                                          the service to
                                                          fetch his data
                                                          from some
                                                          resource
                                                          endpoint. He
                                                          just hits the
                                                          service. He
                                                          does not hit
                                                          the resource
                                                          endpoint
                                                          directly. For
                                                          example, in
                                                          the case of a
                                                          consumer using
                                                          a personal
                                                          finance
                                                          platform
                                                          (PFP)to manage
                                                          his pension
                                                          fund, he hits
                                                          the PFP and
                                                          not the
                                                          Pension fund.
                                                          Assuming that
                                                          the pension
                                                          fund has
                                                          delegated the
                                                          authorization
                                                          control to the
                                                          authorization
                                                          server, then,
                                                          the
                                                          authorization
                                                          server should
                                                          return both
                                                          the access
                                                          token and the
                                                          endpoint of
                                                          the pension
                                                          fund so that
                                                          the PFP can
                                                          pull the data
                                                          using them. A
                                                          similar model
                                                          holds for
                                                          personal
                                                          health service
                                                          and health
                                                          care
                                                          providers.=C2=A0<=
/span>

                                                      

                                                      

                                                        
=C2=A0

                                                      

                                                      

                                                        
Best,=C2=A0

                                                      

                                                      

                                                        
=C2=A0

                                                      

                                                      

                                                        
Nat

                                                      

                                                      

                                                        
=C2=A0

                                                      

                                                    

                                                    
=
=C2=A0

                                                    

                                                      

                                                        
2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
                                                          21:18 Justin
                                                          Richer <jricher@mit.edu>:

                                                      

                                                      

                                                        

                                                          
Convergence

                                                          is exactly
                                                          what I=E2=80=99m
                                                          arguing for,
                                                          though. These
                                                          things ought
                                                          to work
                                                          together.

                                                        

                                                        

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=C2=A0=E2=80=94

                                                          Justin

                                                          

                                                        

                                                        

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          
On

                                                          Jan 21, 2016,
                                                          at 2:55 AM,
                                                          Mike Jones
                                                          <Michael.Jones@microsoft.com>

                                                          wrote:

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          
My

                                                          memory of the
                                                          discussions of
                                                          the oauth-meta
                                                          draft in
                                                          Yokohama were
                                                          that many
                                                          people felt
                                                          that it was
                                                          unnecessarily
                                                          dynamically
                                                          duplicating a
                                                          lot of
                                                          information
                                                          that the
                                                          client already
                                                          had.=C2=A0 Most o=
f
                                                          us that were
                                                          aware of the
                                                          attacks then
                                                          were in favor
                                                          of a more
                                                          targeted,
                                                          minimal
                                                          approach.=C2=A0 Y=
ou
                                                          were listened
                                                          to in
                                                          Yokohama, but
                                                          that didn=E2=80=
=99t
                                                          necessarily
                                                          mean that
                                                          people agreed
                                                          with the
                                                          approach.=C2=A0
                                                          Participants
                                                          were already
                                                          aware of the
                                                          oauth-meta
                                                          proposal in
                                                          Darmstadt but
                                                          no one spoke
                                                          up in favor of
                                                          it that I can
                                                          recall.=C2=A0
                                                          Rather, I
                                                          think people
                                                          were thinking
                                                          that =E2=80=9Cles=
s is
                                                          more=E2=80=9D.

                                                          
=C2=A0

                                                          
There

                                                          have also been
                                                          discussions in
                                                          the last day
                                                          about how
                                                          dynamically
                                                          returning a
                                                          resource URL,
                                                          which
                                                          oauth-meta
                                                          does, is both
                                                          unnecessary
                                                          (since the
                                                          client
                                                          initiated the
                                                          resource
                                                          authorization
                                                          already
                                                          knowing what
                                                          resource it
                                                          wants to
                                                          access) and
                                                          often
                                                          problematic,
                                                          since many
                                                          authorization
                                                          servers can
                                                          authorize
                                                          access to
                                                          multiple
                                                          resources.=C2=A0 =
If
                                                          anything, the
                                                          client should
                                                          be telling the
                                                          authorization
                                                          server what
                                                          resource it
                                                          wants to
                                                          access =E2=80=93 =
not
                                                          the other way
                                                          around.
                                                          
=C2=A0

                                                          
I=E2=80=99m

                                                          not saying
                                                          that there
                                                          aren=E2=80=99t so=
me
                                                          good ideas in
                                                          the oauth-meta
                                                          draft =E2=80=93 I=
=E2=80=99m
                                                          sure there
                                                          are, just as
                                                          there are in
                                                          the approach
                                                          designed by
                                                          the
                                                          participants
                                                          in Darmstadt.=C2=
=A0
                                                          While I
                                                          volunteered to
                                                          write the
                                                          first draft of
                                                          the
                                                          mix-up-mitigation
                                                          approach, it
                                                          really
                                                          reflects
                                                          something a
                                                          lot of people
                                                          have already
                                                          bought into =E2=
=80=93
                                                          as evidenced
                                                          in the passion
                                                          in the
                                                          high-volume
                                                          =E2=80=9CMix-Up A=
bout
                                                          The Mix-Up
                                                          Mitigation=E2=80=
=9D
                                                          thread, and
                                                          not just my
                                                          personal
                                                          project.
                                                          
=C2=A0

                                                          
If

                                                          you think
                                                          there are
                                                          things missing
                                                          or wrong in
                                                          the
                                                          mix-up-mitigation
                                                          draft, please
                                                          say what they
                                                          are.=C2=A0 That
                                                          will help us
                                                          quickly
                                                          converge on a
                                                          solution that
                                                          will work for
                                                          everyone.<=
/p>
                                                          
=C2=A0

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

                                                          Sincerely,=


                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

                                                          -- Mike
                                                          
=C2=A0

                                                          
From: Nat
                                                          Sakimura [mailto:sakimura@gmail.com]
                                                          

                                                          Sent:
                                                          Wednesday,
                                                          January 20,
                                                          2016 11:17 PM

                                                          To:
                                                          Mike Jones
                                                          <Michael.Jones@microsoft.com>;

                                                          William
                                                          Denniss <wdenniss@google.com>;

                                                          Justin Richer
                                                          <jricher@mit.edu>

                                                          Cc: oauth@ietf.org

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          Call for
                                                          Adoption
                                                          
=C2=A0

                                                          

                                                          
Hi

                                                          Mike.=C2=A0

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Conversely,

                                                          I would like
                                                          to ask why
                                                          this approach
                                                          does not work
                                                          for Mix-up
                                                          attack.=C2=A0As N=
ov
                                                          stated, we in
                                                          fact have
                                                          discussed the
                                                          approach in
                                                          quite a length
                                                          back in
                                                          Yokohama. I
                                                          really would
                                                          like to know
                                                          why it does
                                                          not work.=C2=A0
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Besides,

                                                          for oauth-meta
                                                          approach,
                                                          mix-up attack
                                                          is only one of
                                                          the thing it
                                                          solves.=C2=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Nat

                                                          Sakimura

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
                                                          16:02 Mike
                                                          Jones <Michael.Jones@microsoft=
.com>:

                                                          

                                                          

                                                          

                                                          

                                                          
Not

                                                          to be
                                                          negative, but
                                                          I disagree
                                                          with adopting
                                                          draft-sakimura-oa=
uth-meta.=C2=A0

                                                          We should
                                                          define and
                                                          promote one
                                                          mitigation
                                                          approach to
                                                          the mix-up
                                                          attacks.=C2=A0
                                                          Having two
                                                          would confuse
                                                          implementers
                                                          and cause
                                                          compatibility
                                                          problems =E2=80=
=93
                                                          reducing
                                                          overall
                                                          security.<=
/p>
                                                          
=C2=A0

                                                          
The

                                                          approach
                                                          defined in
                                                          draft-jones-oauth=
-mix-up-mitigation
                                                          was created in
                                                          collaboration
                                                          with the
                                                          security
                                                          researchers
                                                          who identified
                                                          the problems
                                                          in the first
                                                          place, was
                                                          vigorously
                                                          discussed in
                                                          the security
                                                          meeting Hannes
                                                          and Torsten
                                                          held in
                                                          Darmstadt, and
                                                          has been since
                                                          refined based
                                                          on substantial
                                                          input from the
                                                          working
                                                          group.=C2=A0 And =
at
                                                          least three
                                                          implementers
                                                          have already
                                                          stated that
                                                          they=E2=80=99ve
                                                          implemented
                                                          it.=C2=A0 I=E2=80=
=99m not
                                                          saying that
                                                          it=E2=80=99s, but=
 if
                                                          there are
                                                          things missing
                                                          or things that
                                                          need to be
                                                          improved in
                                                          our approach,
                                                          we should do
                                                          it there,
                                                          rather
                                                          introducing a
                                                          competing
                                                          approach.<=
/p>
                                                          
=C2=A0

                                                          
Also,

                                                          standard OAuth
                                                          deployments
                                                          register the
                                                          client and
                                                          then use the
                                                          information
                                                          gathered at
                                                          registration
                                                          time for
                                                          subsequent
                                                          protocol
                                                          interactions.=C2=
=A0
                                                          They do not
                                                          need all the
                                                          configuration
                                                          information
                                                          for the
                                                          authorization
                                                          server to be
                                                          retransmitted
                                                          at runtime.=C2=A0
                                                          The oauth-meta
                                                          draft goes too
                                                          far in that
                                                          direction, at
                                                          least as I see
                                                          it.=C2=A0 Returni=
ng
                                                          things two
                                                          ways creates
                                                          its own
                                                          problems, as
                                                          discussed in
                                                          the Duplicate
                                                          Information
                                                          Attacks
                                                          security
                                                          considerations
                                                          section (7.2)
                                                          of the
                                                          mix-up-mitigation
                                                          draft.

                                                          
=C2=A0

                                                          
I=E2=80=99ll

                                                          note that the
                                                          mix-up-mitigation

                                                          approach is
                                                          compatible
                                                          with existing
                                                          practice in
                                                          both static
                                                          and dynamic
                                                          metadata
                                                          discovery.=C2=A0
                                                          Replying to
                                                          Justin=E2=80=99s
                                                          comment that =E2=
=80=9CIt's

                                                          the
                                                          pre-configured
                                                          discovery
                                                          document
                                                          that's at the
                                                          root of the
                                                          mix-up attack
                                                          in the first
                                                          place=E2=80=9D
                                                          =E2=80=93 this is=
 not
                                                          the case.=C2=A0 T=
he
                                                          attacks can be
                                                          performed
                                                          without either
                                                          discovery or
                                                          dynamic
                                                          registration.

                                                          
=C2=A0

                                                          
I
                                                          would be
                                                          interested in
                                                          hearing a
                                                          technical
                                                          discussion on
                                                          whether there
                                                          are aspects of
                                                          the oauth-meta
                                                          approach that
                                                          mitigate
                                                          aspects of the
                                                          attacks that
                                                          the
                                                          mix-up-mitigation
                                                          approach does
                                                          not.=C2=A0 That
                                                          could help
                                                          inform whether
                                                          there are
                                                          additional
                                                          things we
                                                          should add to
                                                          or change in
                                                          the mix-up
                                                          draft.

                                                          
=C2=A0

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

                                                          -- Mike
                                                          
=C2=A0

                                                          
From:
                                                          OAuth [mailto:oauth-bounces@ietf.org]
                                                          On Behalf
                                                          Of William

                                                          Denniss

                                                          Sent:
                                                          Wednesday,
                                                          January 20,
                                                          2016 10:37 PM

                                                          To:
                                                          Justin Richer
                                                          <jricher@mit.edu>

                                                          Cc: oauth@ietf.org

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          Call for
                                                          Adoption
                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          
+1

                                                          to adopt this,
                                                          and I agree
                                                          with Justin's
                                                          comments.

                                                          

                                                          
=C2=A0

                                                          

                                                          
On

                                                          Wed, Jan 20,
                                                          2016 at 9:53
                                                          PM, Justin
                                                          Richer <jricher@mit.edu>

                                                          wrote:

                                                          

                                                          

                                                          
+1

                                                          

                                                          Inline
                                                          discovery and
                                                          pre-configured
                                                          discovery (ie,
                                                          .well-known)
                                                          should at the
                                                          very least be
                                                          compatible and
                                                          developed
                                                          together. It'=
s
                                                          the
                                                          pre-configured
                                                          discovery
                                                          document
                                                          that's at the
                                                          root of the
                                                          mix-up attack
                                                          in the first
                                                          place.

                                                          

                                                          =C2=A0-- Justin

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          
On

                                                          1/19/2016
                                                          10:30 PM, Nat
                                                          Sakimura
                                                          wrote:

                                                          

                                                          

                                                          

                                                          
Just

                                                          to give more
                                                          context, at
                                                          IETF 94, I
                                                          have done a
                                                          presentation
                                                          on discovery.=C2=
=A0
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
According

                                                          to the
                                                          minutes,=C2=A0
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=C2=A0=C2=A0=C2=A0 (f) Discovery (Nat)

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0Nat explains his document as an example of the work=
 that has to be done

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 in the area of discovery, which is a topic that has been=
 identified

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 as necessary for interoperability since many years but s=
o far there

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 was not time to work on it. Mike, John and Nat are worki=
ng on a new

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 document that describes additional discovery-relevant co=
mponents.

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0Poll: 19 for / zero against / 4 persons need more i=
nformation.

                                                          
=C2=A0

                                                          
The

                                                          document
                                                          discussed
                                                          there was 
                                                          <=
/a>https://tools.ietf.org/html/draft-sakimura-oauth-meta-05=
.
                                                          This is a
                                                          simple (only
                                                          1-page!) but a
                                                          very powerful
                                                          document that
                                                          nudges towards
                                                          HATEOAS which
                                                          is at the core
                                                          of
                                                          RESTful-ness.
                                                          It also
                                                          mitigates the
                                                          Mix-up attack
                                                          without
                                                          introducing
                                                          the concept of
                                                          issuer which
                                                          is not in
                                                          RFC6749. It is
                                                          also good for
                                                          selecting
                                                          different
                                                          endpoints
                                                          depending on
                                                          the user
                                                          authentication
                                                          and
                                                          authorization
                                                          results and
                                                          more privacy
                                                          sensitive than
                                                          pre-announced
                                                          Discovery
                                                          document. It
                                                          also allows
                                                          you to find to
                                                          which
                                                          protected
                                                          resource
                                                          endpoint you
                                                          can use the
                                                          access token
                                                          against.=C2=A0
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          
In

                                                          the last
                                                          sentence of
                                                          the minutes,
                                                          it talks about
                                                          "a new
                                                          document that
                                                          describes
                                                          additional
                                                          discovery-relevan=
t
                                                          components".
                                                          This is=C2=A0https://tools.ietf.org/html/draft-jones-oauth=
-discovery-00.=C2=A0


                                                          It went for
                                                          the call for
                                                          adoption.
                                                          However, it is
                                                          only a half of
                                                          the story. I
                                                          believe=C2=A0https://tools.ietf.org/html/draft-sakimura-oauth-me=
ta-05=C2=A0that

                                                          was discussed
                                                          at IETF 94 and
                                                          had support
                                                          there=C2=A0should
                                                          be adopted as
                                                          well.=C2=A0 

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Nat

                                                          Sakimura

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4)
                                                          12:05 Nat
                                                          Sakimura <sakimura@gmail.com>:

                                                          

                                                          

                                                          

                                                          
Thanks

                                                          Hannes.=C2=A0 
                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
I
                                                          did not find=C2=
=A0https://tools.ietf.org/html/draft-sakimura-o=
auth-meta-05,=C2=A0which

                                                          was discussed
                                                          in Yokohama,
                                                          and was
                                                          largely in
                                                          agreement if
                                                          my
                                                          recollection
                                                          is correct.
                                                          Why is it not
                                                          in the call
                                                          for adoption?=C2=
=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB)
                                                          20:39 Hannes
                                                          Tschofenig
                                                          <hannes.tschofenig@gmx.net>=
:

                                                          

                                                          

                                                          

                                                          

                                                          
Hi

                                                          all,

                                                          

                                                          we have
                                                          submitted our
                                                          new charter to
                                                          the IESG (see

                                                          http://www.ietf.org/mail-archive/web/oauth/curre=
nt/msg15379.html)
                                                          and

                                                          since some
                                                          IESG members
                                                          like to see an
                                                          updated list
                                                          of milestones
                                                          as

                                                          well. For this
                                                          reason, based
                                                          on a
                                                          suggestion
                                                          from Barry, we
                                                          are also

                                                          starting a
                                                          call for
                                                          adoption
                                                          concurrently
                                                          with the
                                                          review of the
                                                          charter

                                                          text by the
                                                          IESG.

                                                          

                                                          We will post
                                                          separate mails
                                                          on the
                                                          individual
                                                          documents.
                                                          Your feedback

                                                          is important!
                                                          Please take
                                                          the time to
                                                          look at the
                                                          documents and
                                                          provide

                                                          your feedback.
                                                          

                                                          Ciao

                                                          Hannes &
                                                          Derek

                                                          

_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.iet=
f.org/mailman/listinfo/oauth

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          
____________=
___________________________________

                                                          
OAuth mailin=
g list

                                                          
OAuth@ietf.org

                                                          
https://www.i=
etf.org/mailman/listinfo/oauth

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          


_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.iet=
f.org/mailman/listinfo/oauth

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          

                                                          

                                                          
_______________________________________________

                                                          OAuth mailing
                                                          list

                                                          OAuth@ietf.org

                                                          https://www.iet=
f.org/mailman/listinfo/oauth

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                        

                                                      

                                                    

                                                  

                                                

                                              

                                            

                                          

                                        

                                        


_______________________________________________

                                          OAuth mailing list

                                          OAuth@ietf.org

                                          https://www.ietf.org/mailman/listi=
nfo/oauth

                                      

                                    

                                    
=C2=A0

                                  

                                

                              

                            

                          

                        

                      

                    

                  

                  

                

                

                

                

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


              

              

            

          

        

        

      

    

    

    
--=20
Chief Architect                  =20
Identity Services Engineering     Work: george.fletcher@teamaol.com
AOL Inc.                          AIM:  gffletch
Mobile: +1-703-462-3494           Twitter: http://twitter.com/gffletch
Office: +1-703-265-2544           Photos: http://georgefletcher.photography


  






--001a113ecda0356dda052a41e812--


From nobody Tue Jan 26 12:10:29 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF621A00CA for ; Tue, 26 Jan 2016 12:10:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.251
X-Spam-Level: 
X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxgfmWl-CSFE for ; Tue, 26 Jan 2016 12:10:22 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) (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 10F461B2C5B for ; Tue, 26 Jan 2016 12:10:22 -0800 (PST)
Received: from [79.218.87.147] (helo=[192.168.71.102]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aO9wP-0003Jm-Cq; Tue, 26 Jan 2016 21:10:17 +0100
To: Mike Jones , "oauth@ietf.org" 
References: 
From: Torsten Lodderstedt 
Message-ID: <56A7D29F.2080701@lodderstedt.net>
Date: Tue, 26 Jan 2016 21:10:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070202000207060400050100"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 20:10:28 -0000

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

Hi Mike,

I really like the new revision since it is much simpler :-)

My comments:

I'm fine with describing all mitigations we talked about in Darmstadt in 
one/this spec. But the state check at the tokens endpoint is supposed to 
be a mitigation against code injection/cut and paste attack, which is 
not directly related to IDP/AS mix up. So I would suggest to change the 
name of the spec, probably "OAuth security extensions"?

I think the code injection/cut and paste attack should be described more 
extensively in the introduction. It's important for the reader to 
understand, why this mitigation is defined at all. Moreover, I think the 
description of the mitigation is still incomplete/spread over the 
document. In order to detect code injection, the RP not only needs to 
send the state to the tokens endpoint, it also needs to (directly or 
indirectly) _bind_ the state to the particular user agent (session). 
Otherwise, the attacker can inject the state along with the solen code 
easily. I would suggest to merge

          "To prevent replay of the state in another browser instance by 
an attacker, the state value MUST be tied to the browser instance in a 
way that cannot be forged by an attacker. Section 4 of 
[I‑D.bradley‑oauth‑jwt‑encoded‑state]
          provides several examples of how a client can accomplish this."

into section 5.

I thought we had discussed to also give implementors a guideline on 
using state to prevent CSRF as well? How will we take care of that topic?

kinds regards,
Torsten.


Am 21.01.2016 um 07:28 schrieb Mike Jones:
>
> John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up 
> Mitigation draft.  Changes were:
>
> ·Simplified by no longer specifying the signed JWT method for 
> returning the mitigation information.
>
> ·Simplified by no longer depending upon publication of a discovery 
> metadata document.
>
> ·Added the “state†token request parameter.
>
> ·Added examples.
>
> ·Added John Bradley as an editor.
>
> The specification is available at:
>
> ·http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01
>
> An HTML-formatted version is also available at:
>
> ·http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html
>
> -- Mike
>
> P.S.  This note was also posted athttp://self-issued.info/?p=1526 and 
> as @selfissued .
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------070202000207060400050100
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Mike,

    

    I really like the new revision since it is much simpler :-)

    

    My comments:

    

    I'm fine with describing all mitigations we talked about in
    Darmstadt in one/this spec. But the state check at the tokens
    endpoint is supposed to be a mitigation against code injection/cut
    and paste attack, which is not directly related to IDP/AS mix up. So
    I would suggest to change the name of the spec, probably "OAuth
    security extensions"?

    

    I think the code injection/cut and paste attack should be described
    more extensively in the introduction. It's important for the reader
    to understand, why this mitigation is defined at all. Moreover, I
    think the description of the mitigation is still incomplete/spread
    over the document. In order to detect code injection, the RP not
    only needs to send the state to the tokens endpoint, it also needs
    to (directly or indirectly) _bind_ the state to the particular user
    agent (session). Otherwise, the attacker can inject the state along
    with the solen code easily. I would suggest to merge

    

             "To prevent replay of the state in another browser instance
    by an attacker, the state value MUST be tied to the browser instance
    in a way that cannot be forged by an attacker. Section 4 of
    [I‑D.bradley‑oauth‑jwt‑encoded‑state]    

             provides several examples of how a client can accomplish
    this."

    

    into section 5.

    

    I thought we had discussed to also give implementors a guideline on
    using state to prevent CSRF as well? How will we take care of that
    topic? 

    

    kinds regards,

    Torsten.

    

    

    
Am 21.01.2016 um 07:28 schrieb Mike
      Jones:

    

    

      
      
      
      

        
John Bradley and I collaborated to create
          the second OAuth 2.0 Mix-Up Mitigation draft.  Changes were:

        
·      
              Simplified by no longer
          specifying the signed JWT method for returning the mitigation
          information.

        
·      
              Simplified by no longer
          depending upon publication of a discovery metadata document.
          

        
·      
              Added the “stateâ€
          token request parameter.

        
·      
              Added examples.

        
·      
              Added John Bradley as
          an editor.

        
 

        
The specification is available at:

        
·      
              http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01

        
 

        
An HTML-formatted version is also available
          at:

        
·      
              http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html

        
 

        
                                                         
          -- Mike

        
 

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

        
 

      

      

      

      

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


    

    

  


--------------070202000207060400050100--


From nobody Tue Jan 26 12:11:33 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092A91B2C5B for ; Tue, 26 Jan 2016 12:11:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3OaS3HWIZbt for ; Tue, 26 Jan 2016 12:11:29 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::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 AF9161B2C90 for ; Tue, 26 Jan 2016 12:11:27 -0800 (PST)
Received: by mail-lb0-x236.google.com with SMTP id dx2so7469375lbd.3 for ; Tue, 26 Jan 2016 12:11:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:content-type; bh=+jPTu/ZAaN2gBAbtwPZMZAt+5CRSSimMMsvJlF3el5g=; b=mFDLs6ZKci69ZdjE4zrQxSYvLwplaZg2pMAc182dTK6oDtQL2xtwzbOW5l6/Si2gkn JXLcfbfPXhqUK/4ynwWRQm6uP2xWPP16lZUSeCBQigLzStnAv9l4TBfKgxd/9O8ut3eU tBMgLSXHOV477eFzafpakEfduSIrNNjRlbZ0c7KFj+xODrPgq+I5UGgCGHyo9PEOHiu0 h8zCKFnba/gNfEjt+upGWU+xoKidzJcxpidTjOWbUscauXHi4/5oQItBMn42iSZXHZR7 28QLRWcEEj/Hh048I4Me1Dj46ve+zHIS9JDU4egqekPvTVK22qZ5WpUUwue/Pz8vRQ9h iM4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :content-type; bh=+jPTu/ZAaN2gBAbtwPZMZAt+5CRSSimMMsvJlF3el5g=; b=S4Gy4CCtpRRl5U1EmWV5iYzPUuq9qa0hKNbwCTpuzhtMM1CoR2zyOnEwUfawA0uWr3 Xc81IaPb+drku9aOWyWWFnpgVVM8E1zNowbeKSOTK6TS3tpfh/WZ7lPhl5hj6t/n8b3n 26GEUxcUAkJmRtZPf9YjtK+aTut6iUtAyrKWWtQjf2SbZRvNntIcJ2W0RqBhqb5rOD6i UqqvAaplppZosJxcuTAOu1bDX4Ui34+wTnx0ys6ne5CIiWSBbjI+NaTKRPEurdvSKK9L HdTMvBoU/c7JJfuJubRI49I5x06JwbdVUZ8h+vBrgKWKDEzvxG3qjVwXyWfVeD0ZTb6w ZTWw==
X-Gm-Message-State: AG10YOSLUFZVIwmwI6+lFK6Afd7xX8jPiVLW7st5laINA3XLS+S9+jYu2vrsPVLystQe4A==
X-Received: by 10.112.132.66 with SMTP id os2mr9614522lbb.111.1453839085939; Tue, 26 Jan 2016 12:11:25 -0800 (PST)
Received: from dombp.local ([80.232.78.190]) by smtp.gmail.com with ESMTPSA id p66sm379656lfe.42.2016.01.26.12.11.24 for  (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 12:11:24 -0800 (PST)
Date: Tue, 26 Jan 2016 21:11:23 +0100
From: Dominick Baier 
To: oauth@ietf.org
Message-ID: 
X-Mailer: Airmail (351)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="56a7d2ec_37813967_289"
Archived-At: 
Subject: [OAUTH-WG] PKCE & Hybrid Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 20:11:31 -0000

--56a7d2ec_37813967_289
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,=C2=A0

PKCE only mentions OAuth 2.0 code flow - but wouldn=E2=80=99t that also a=
pply to OIDC hybrid flow e.g. code id=5Ftoken=3F

=E2=80=94=C2=A0
cheers
Dominick Baier


--56a7d2ec_37813967_289
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


      

        
John Bradley and I collaborated to create
          the second OAuth 2.0 Mix-Up Mitigation draft.  Changes were:<=
o:p>

        
<=
span style=3D"mso-list:Ignore">=C2=B7      
              Simplified by no longer
          specifying the signed JWT method for returning the mitigation
          information.

        
<=
span style=3D"mso-list:Ignore">=C2=B7      
              Simplified by no longer
          depending upon publication of a discovery metadata document.
          

        
<=
span style=3D"mso-list:Ignore">=C2=B7      
              Added the =E2=80=9Cstate=E2=80=9D
          token request parameter.

        
<=
span style=3D"mso-list:Ignore">=C2=B7      
              Added examples.<=
/p>
        
<=
span style=3D"mso-list:Ignore">=C2=B7      
              Added John Bradley as
          an editor.

        
 

        
The specification is available at:=


        
<=
span style=3D"mso-list:Ignore">=C2=B7      
              =
http://tools.ietf.org/html/draft-jones=
-oauth-mix-up-mitigation-01

        
 

        
An HTML-formatted version is also available
          at:

        
<=
span style=3D"mso-list:Ignore">=C2=B7      
              http://self-issued.info/=
docs/draft-jones-oauth-mix-up-mitigation-01.html

        
 

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

        
 

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

        
 

      

      

      

      

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


    
    

 =20


____________________=
___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai=
lman/listinfo/oauth
=

--Apple-Mail-DDB44199-F5B9-4754-A5F9-45D74D7946EA--


From nobody Tue Jan 26 15:03:22 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB581B32C5 for ; Tue, 26 Jan 2016 15:03:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDI5LLUuNTtH for ; Tue, 26 Jan 2016 15:03:17 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB061B32C1 for ; Tue, 26 Jan 2016 15:03:17 -0800 (PST)
X-AuditID: 12074422-f79c46d000006aa7-56-56a7fb34c241
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id B1.15.27303.43BF7A65; Tue, 26 Jan 2016 18:03:16 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u0QN3Fmd030088; Tue, 26 Jan 2016 18:03:15 -0500
Received: from [192.168.128.48] (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 u0QN3Dtj014934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 Jan 2016 18:03:14 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_B5AE43CA-7CAC-4D8E-8847-C74576C802AA"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: 
Date: Tue, 26 Jan 2016 18:03:12 -0500
Message-Id: <7E08DFCA-ADBC-481A-896A-2725E1F79EFA@mit.edu>
References: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> <569CDE25.90908@gmail.com>  <569E08F6.4040600@gmail.com> <56A7B52C.2040302@gmail.com> 
To: Thomas Broyer 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsUixG6nomvye3mYwc2JAhYn375is/i31N7i +L+LzBab5jSzO7B47Jx1l91jwaZSjyVLfjIFMEdx2aSk5mSWpRbp2yVwZZw62sVWcGkRY0XH qYVMDYxX2xi7GDk5JARMJKZPesUOYYtJXLi3nq2LkYtDSGAxk8Tsw7dZIZyNjBKTO66wQDi3 mST+777NBtLCLJAgcf/neTCbV0BP4tWty6wgtrCAr8SFj3fAxrIJqEpMX9PCBGJzCgRKXP41 F6yeBSi+7fovRpChzAKdjBJXz51lhhhkJdH1+yAzxLalTBKHdz4AmyoioCZx891GqMNlJXb/ fsQ0gVFgFpJDZiE5BCKuLbFs4WtmCFtTYn/3chZMcQ2Jzm8TWRcwsq1ilE3JrdLNTczMKU5N 1i1OTszLSy3SNdXLzSzRS00p3cQIjgoXpR2MPw8qHWIU4GBU4uE1OLQ8TIg1say4MvcQoyQH k5Iob+YLoBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3u+fgHK8KYmVValF+TApaQ4WJXHeXR1z w4QE0hNLUrNTUwtSi2CyMhwcShK88r+AGgWLUtNTK9Iyc0oQ0kwcnCDDeYCG84LU8BYXJOYW Z6ZD5E8xKkqJ8174CZQQAElklObB9YKSVsLbw6avGMWBXhHmFQdp5wEmPLjuV0CDmYAGH5QH G1ySiJCSamDMrbURlGja/lyUW0wnZsLN+G1uM+N2X/vw69DTdo2Xy37s1v07cfES7nd6G6al mSjzOi847LO+6JhI3O3dW3qP7P72onlb6syDp67obI3MZHfYeWH7dq9tIVNOL52/tvh5Ad8a a/PGZQJVsT9TFU5mZeSf0Jz0c+GH34/ljV/3ZHMtaBGV7HD+qcRSnJFoqMVcVJwIANKwMDU1 AwAA
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 26 Jan 2016 23:03:21 -0000

--Apple-Mail=_B5AE43CA-7CAC-4D8E-8847-C74576C802AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

In MITREid Connect we track grants per client_id per user, and we have a =
separate database object for storing them. I wouldn=E2=80=99t recommend =
simply updating an access token that=E2=80=99s already in the wild with =
more power =E2=80=94 that just sounds wrong.

 =E2=80=94 Justin

> On Jan 26, 2016, at 1:57 PM, Thomas Broyer  wrote:
>=20
> Fwiw, at Ozwillo, we track grants per user per client_id (we don't =
support native apps; only web flows for now), and we don't do =
"incremental grants" like Google: if you request scope B and the user =
had only granted scope A, you'll get a token for scope B only. This is =
partly because our tokens are not for our own APIs only, contrary to =
Google, so we want to allow clients to get tokens with narrow scopes so =
they could have one token per third-party API and prevent rogue =
resources from trying to use received tokens at other APIs.
>=20
> UI-wise, we tell the user what he already granted to the client, and =
even let him grant scopes that the client has pre-registered as =
"possibly needed at some time" (through a custom provisioning protocol), =
but the issued token is always for the exact scopes that the client =
requested in this specific request.
> And if all requested scopes have already been granted, then we do a =
transparent redirect without showing anything to the user (which is what =
most other implementations do too)
>=20
> Le mar. 26 janv. 2016 19:04, Sergey Beryozkin > a =C3=A9crit :
> Hi
>=20
> I'm not sure if the next question is off topic or too low level,
> hopefully not,
>=20
> When the repeated authorization is skipped or only new scopes are
> requested to be authorized as per the incremented auth approach, is it
> reasonable to assume that the record that is used to track it all is
> actually the existing access token or is totally OIDC implementation
> specific ?
> I think using the existing token as a record is reasonable because it =
is
> time scoped and if we do not use the access token for keeping the =
track
> of the multiple approvals, etc, then one need to introduce one more
> record mirroring to some extent the access token...
>=20
> For example, the user session may have expired but the access token =
that
> was issued to a client web app on behalf of this user is still active,
> so when the user returns and signs in again, and for example, approves
> few more scopes, then the existing access token (the record) gets
> updated, instead of a new token being created.
>=20
> If it is reasonable then does it mean the sticky or incremental
> authorization works as long as the access token is available
> (refreshable) ?
>=20
> Sergey
>=20
>=20
>=20
>=20
> On 19/01/16 09:59, Sergey Beryozkin wrote:
> > Hi William
> >
> > Thanks for the advice. FYI we are also on the way to supporting the
> > incremental authorization of scopes - thanks for highlighting the
> > importance of this process on this list...
> >
> > Cheers, Sergey
> > On 19/01/16 03:10, William Denniss wrote:
> >> Agree with Justin, this is pretty common. We support it for re-auth =
as
> >> well as incremental auth (where the user has already approved scope =
"a"
> >> and is presented with a request for scopes "a b", they will only =
need to
> >> approve scope "b").  In fact if you don't do this, then incremental =
auth
> >> isn't really viable.
> >>
> >> Regarding security: don't do this for non-confidential clients =
where you
> >> can't verify the identity of the app by the redirect (e.g. a =
localhost
> >> redirect to an installed app).
> >>
> >> On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin =

> >> >> wrote:
> >>
> >>     Hi Justin, thanks for the advice,
> >>
> >>     Cheers, Sergey
> >>
> >>     On 18/01/16 11:47, Justin Richer wrote:
> >>
> >>         Yes, this is common practice. Give the user the option to
> >>         remember the
> >>         decision. This is known as "trust on first use", or tofu. =
Our
> >>         server,
> >>         MITREid Connect, implements this as do many others.
> >>
> >>
> >>
> >>         -- Justin
> >>
> >>         / Sent from my phone /
> >>
> >>
> >>         -------- Original message --------
> >>         From: Sergey Beryozkin 
> >>         >>
> >>         Date: 1/18/2016 5:59 AM (GMT-05:00)
> >>         To: oauth@ietf.org  =
>
> >>         Subject: [OAUTH-WG] Can the repeated authorization of =
scopes be
> >>         avoided ?
> >>
> >>         Hi All
> >>
> >>         The question relates to the process of showing the =
authorization
> >>         code/implicit flow consent screen to a user.
> >>
> >>
> >>         I'm discussing with my colleagues the possibility of =
avoiding
> >>         asking the
> >>         same user whose session has expired and who is =
re-authenticating
> >>         with AS
> >>         which scopes should be approved.
> >>
> >>         For example, suppose the OAuth2 client redirects a user =
with the
> >>         requested scope 'a'. The user signs in to AS and is shown a
> >> consent
> >>         screen asking to approve the 'a' scope. The user approves =
'a'
> >>         and the
> >>         flow continues.
> >>
> >>         Some time later, when the user's session has expired, the =
user is
> >>         redirected to AS with the same 'a' scope.
> >>
> >>         Would it be a good idea, at this point, not to show the =
user the
> >>         consent
> >>         screen asking to approve the 'a' scope again ? For example, =
AS
> >> can
> >>         persist the fact that a given user has already approved 'a' =
for
> >>         a given
> >>         client earlier, so when the user re-authenticates, AS will =
use
> >>         this info
> >>         and will avoid showing the consent screen.
> >>
> >>         That seems to make sense, but I'm wondering, can there be =
some
> >>         security
> >>         implications associated with it, any =
recommendations/advices
> >>         will be welcome
> >>
> >>         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 =

> >>
> >>
> >
> >
>=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=_B5AE43CA-7CAC-4D8E-8847-C74576C802AA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

In MITREid Connect we track grants per client_id per user, =
and we have a separate database object for storing them. I wouldn=E2=80=99=
t recommend simply updating an access token that=E2=80=99s already in =
the wild with more power =E2=80=94 that just sounds wrong.

 =E2=80=94 =
Justin

On Jan 26, 2016, at 1:57 PM, Thomas Broyer =
<t.broyer@gmail.com> wrote:

Fwiw, at Ozwillo, we track grants per user per client_id (we =
don't support native apps; only web flows for now), and we don't do =
"incremental grants" like Google: if you request scope B and the user =
had only granted scope A, you'll get a token for scope B only. This is =
partly because our tokens are not for our own APIs only, contrary to =
Google, so we want to allow clients to get tokens with narrow scopes so =
they could have one token per third-party API and prevent rogue =
resources from trying to use received tokens at other APIs.

UI-wise, we tell the =
user what he already granted to the client, and even let him grant =
scopes that the client has pre-registered as "possibly needed at some =
time" (through a custom provisioning protocol), but the issued token is =
always for the exact scopes that the client requested in this specific =
request.
And if all requested scopes have already =
been granted, then we do a transparent redirect without showing anything =
to the user (which is what most other implementations do too)

Le mar. 26 janv. 2016 19:04, Sergey Beryozkin =
<sberyozkin@gmail.com> a =C3=A9crit :
Hi



I'm not sure if the next question is off topic or too low level,

hopefully not,



When the repeated authorization is skipped or only new scopes are

requested to be authorized as per the incremented auth approach, is =
it

reasonable to assume that the record that is used to track it all is

actually the existing access token or is totally OIDC implementation

specific ?

I think using the existing token as a record is reasonable because it =
is

time scoped and if we do not use the access token for keeping the =
track

of the multiple approvals, etc, then one need to introduce one more

record mirroring to some extent the access token...



For example, the user session may have expired but the access token =
that

was issued to a client web app on behalf of this user is still =
active,

so when the user returns and signs in again, and for example, =
approves

few more scopes, then the existing access token (the record) gets

updated, instead of a new token being created.



If it is reasonable then does it mean the sticky or incremental

authorization works as long as the access token is available

(refreshable) ?



Sergey









On 19/01/16 09:59, Sergey Beryozkin wrote:

> Hi William

>

> Thanks for the advice. FYI we are also on the way to supporting =
the

> incremental authorization of scopes - thanks for highlighting =
the

> importance of this process on this list...

>

> Cheers, Sergey

> On 19/01/16 03:10, William Denniss wrote:

>> Agree with Justin, this is pretty common. We support it for =
re-auth as

>> well as incremental auth (where the user has already approved =
scope "a"

>> and is presented with a request for scopes "a b", they will =
only need to

>> approve scope "b").  In fact if you don't do this, then =
incremental auth

>> isn't really viable.

>>

>> Regarding security: don't do this for non-confidential clients =
where you

>> can't verify the identity of the app by the redirect (e.g. a =
localhost

>> redirect to an installed app).

>>

>> On Mon, Jan 18, 2016 at 4:44 AM, Sergey Beryozkin <sberyozkin@gmail.com

>> <mailto:sberyozkin@gmail.com>> wrote:

>>

>>     Hi Justin, thanks for the advice,

>>

>>     Cheers, Sergey

>>

>>     On 18/01/16 11:47, Justin Richer wrote:

>>

>>         Yes, this is common practice. =
Give the user the option to

>>         remember the

>>         decision. This is known as =
"trust on first use", or tofu. Our

>>         server,

>>         MITREid Connect, implements =
this as do many others.

>>

>>

>>

>>         -- Justin

>>

>>         / Sent from my phone /

>>

>>

>>         -------- Original message =
--------

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

>>         <mailto:sberyozkin@gmail.com>>

>>         Date: 1/18/2016 5:59 AM =
(GMT-05:00)

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

>>         Subject: [OAUTH-WG] Can the =
repeated authorization of scopes be

>>         avoided ?

>>

>>         Hi All

>>

>>         The question relates to the =
process of showing the authorization

>>         code/implicit flow consent =
screen to a user.

>>

>>

>>         I'm discussing with my =
colleagues the possibility of avoiding

>>         asking the

>>         same user whose session has =
expired and who is re-authenticating

>>         with AS

>>         which scopes should be =
approved.

>>

>>         For example, suppose the =
OAuth2 client redirects a user with the

>>         requested scope 'a'. The user =
signs in to AS and is shown a

>> consent

>>         screen asking to approve the =
'a' scope. The user approves 'a'

>>         and the

>>         flow continues.

>>

>>         Some time later, when the =
user's session has expired, the user is

>>         redirected to AS with the same =
'a' scope.

>>

>>         Would it be a good idea, at =
this point, not to show the user the

>>         consent

>>         screen asking to approve the =
'a' scope again ? For example, AS

>> can

>>         persist the fact that a given =
user has already approved 'a' for

>>         a given

>>         client earlier, so when the =
user re-authenticates, AS will use

>>         this info

>>         and will avoid showing the =
consent screen.

>>

>>         That seems to make sense, but =
I'm wondering, can there be some

>>         security

>>         implications associated with =
it, any recommendations/advices

>>         will be welcome

>>

>>         Sergey

>>

>>        =
 _______________________________________________

>>         OAuth mailing list

>>         OAuth@ietf.org <mailto:OAuth@ietf.org>

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

>>

>>

>>    =
 _______________________________________________

>>     OAuth mailing list

>>     OAuth@ietf.org <mailto: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=_B5AE43CA-7CAC-4D8E-8847-C74576C802AA--


From nobody Tue Jan 26 17:31:45 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581B11B2D44 for ; Tue, 26 Jan 2016 17:31:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bvqtaHDhd0Q for ; Tue, 26 Jan 2016 17:31:35 -0800 (PST)
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 B9CB11B2D35 for ; Tue, 26 Jan 2016 17:31:34 -0800 (PST)
Received: by mail-qk0-x22e.google.com with SMTP id s5so71392592qkd.0 for ; Tue, 26 Jan 2016 17:31:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=mnr1v4UfABR+c2bGqjAlx8rczG9gI4/9/rVhQk7u/KY=; b=GVzfd0UeB76mvwgZxQoSuIMYMMxuXDigBWPnlCDylLbeEOVoS9+5WoStWEiD84BiN7 F7G+JeTRAS239FgUtTgJATYJqGZw/GfN2BSVIYak84/Dlgv2AxCzcN8KOU638HGX1HrJ 06u+EtP8Ou+Jz1Z14bNpdpAakdQvnPm3zrvMo/EII+UswQbe8stnehXr6Oiz9Z1ytwMT 4M385ly9VtiMx930FsT5l31GYN14LVv49+oiF2QyzU+0VHeaOZOWB3VQG2U9pO6631HA IUd+/oL3qHiSrUdHDnaxbEK2Bhqnug1GJ6Q+yjPTXtlz99LL9jvabFvc2dHH9NQob1+t aHXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=mnr1v4UfABR+c2bGqjAlx8rczG9gI4/9/rVhQk7u/KY=; b=TkoCEf3tcT649oqUwkJ/7VwNr78fuT6aEBIDmJKkz/KTR7mQ34Jq/WqdJnXT5nB0FH HTsHqMUsDvGcNXw1Le7DPltBv0ysiMh5AnC3zxLf2ZL9FG5whMrTYVUmtaPD74BFqyt0 c3u/BBoDVbsfMRTIInhm8nLV8cBMaad2lad9413bypRXPgobw2HLpaie0kih/ymvtsbp qsL2COVQWJ44UE62V/IjmKZ3HQMoLzKbVNpRGpVoL79LbC3wO/sL1Y3JmVmJS+h7Fq2P kNe72CWiCXiZq1vlYX3PGt9j7b6uFjbC5aRIsW9NM6jnqYQn1gsHZakwJmQy/wq0b52p 8RfA==
X-Gm-Message-State: AG10YOQD2i61wO6ukwx8Pua15/wi37dWdkQMQNmOpL11UXk+7Aw+WwPEKCS8R8ZOXI4OmvPS+RGdnGLE8nggVw==
X-Received: by 10.55.31.151 with SMTP id n23mr6456853qkh.50.1453858293840; Tue, 26 Jan 2016 17:31:33 -0800 (PST)
MIME-Version: 1.0
References: <569E2076.2090405@gmx.net>             <56A78EEF.4090706@aol.com>  <56A7C3E8.8080601@aol.com> 
In-Reply-To: 
From: Nat Sakimura 
Date: Wed, 27 Jan 2016 01:31:23 +0000
Message-ID: 
To: Brian Campbell , George Fletcher 
Content-Type: multipart/alternative; boundary=001a1147b5582882f5052a46c327
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 01:31:43 -0000

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

So, is there a lot of cases that the authority section of the Good AS's
Authorization Endpoint and the Token Endpoints are different?
If not, then requiring that they are the same seems to virtually remove the
attack surface for the mix-up related attacks. It does not introduce new
parameter nor discovery. If it can be done, it probably is not worth adding
a new wire protocol element to mitigate the mix-up variants.



2016=E5=B9=B41=E6=9C=8827=E6=97=A5(=E6=B0=B4) 4:44 Brian Campbell :

> I understand what you're saying but disagree with the premise.
>
> On Tue, Jan 26, 2016 at 12:07 PM, George Fletcher 
> wrote:
>
>> So I'm fine with not requiring discovery in the simple case of an RS
>> supporting a single AS. However, once the RS moves to supporting multipl=
e
>> authorization servers then I believe that discovery based on the 'iss'
>> string is required. The discovery results can be cached so a discovery
>> lookup per transaction is not required.
>>
>> Thanks,
>> George
>>
>> On 1/26/16 1:58 PM, Brian Campbell wrote:
>>
> I'm staying that it's sufficiently unlikely that it shouldn't be part of
>> the threat model and that a discovery lookup on iss isn't necessary.
>>
>>
>> On Tue, Jan 26, 2016 at 8:21 AM, George Fletcher 
>> wrote:
>>
>> While it's a different way of getting the endpoints mixed up, I don't
>>> think that makes it invalid. If we are going to address the attack vect=
or I
>>> believe we should solve it for "all" cases not just the ones that seem =
most
>>> likely.
>>>
>>> Thanks,
>>> George
>>>
>>> On 1/26/16 8:37 AM, Brian Campbell wrote:
>>>
>> I'm not sure what's described in the blog post is actually a variant of
>>> an attack that anyone is really concerned about? A client developer wou=
ld
>>> have to change a production system to use an unfamiliar value for the t=
oken
>>> endpoint based solely on a an email without even looking at service
>>> documentation or metadata.
>>>
>>> On Fri, Jan 22, 2016 at 6:29 PM, Nat Sakimura < 
>>> sakimura@gmail.com> wrote:
>>>
>>> I wrote a blog on why the current mix-up draft approach does not solve
>>>> the issue.
>>>>
>>>>
>>>> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-r=
fc6749/
>>>>
>>>> Hopefully, the point I am making is clearer by this.
>>>>
>>>> Best,
>>>>
>>>> Nat
>>>>
>>>> 2016=E5=B9=B41=E6=9C=8823=E6=97=A5(=E5=9C=9F) 8:32 Mike Jones :
>>>>
>>> I like the =E2=80=9Cfrom which the authorization server's configuration
>>>>> information location can be derived=E2=80=9D language.  Thanks.  I=E2=
=80=99ll plan to
>>>>> incorporate that the next time the draft is revised.
>>>>>
>>>>>
>>>>>
>>>>>                                                                 -- Mi=
ke
>>>>>
>>>>>
>>>>>
>>>>> *From:* Brian Campbell [mailto: 
>>>>> bcampbell@pingidentity.com]
>>>>> *Sent:* Friday, January 22, 2016 3:26 PM
>>>>> *To:* Nat Sakimura < sakimura@gmail.com>
>>>>> *Cc:* Mike Jones < 
>>>>> Michael.Jones@microsoft.com>; Justin Richer < 
>>>>> jricher@mit.edu>;  
>>>>>
>>>>>
>>>>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>>>>
>>>>
>>>>>
>>>>> I agree that the language describing OAuth issuer could and should be
>>>>> improved. The text now reads like it is the exact and full URL where =
the
>>>>> metadata/discovery document is located. Perhaps something more like "=
the
>>>>> URL from which the authorization server's configuration information
>>>>> location can be derived" and explain that adding the .well-known bits=
 to
>>>>> the issuer is where the configuration information can actually be fou=
nd.
>>>>>
>>>>> On Thu, Jan 21, 2016 at 7:07 PM, Nat Sakimura < 
>>>>> sakimura@gmail.com> wrote:
>>>>>
>>>> Re: iss. I discussed this a bit with Nov in more details. It probably
>>>>> is a sloppy language of the specs that is making it difficult to read=
 what
>>>>> you wanted to achieve.
>>>>>
>>>>>
>>>>>
>>>>> In mix-up-mitigation draft, OAuth issuer is "the URL of the
>>>>> authorization server's configuration information location". In OAuth
>>>>> discovery draft, there is something called "OAuth 2.0 Configuration
>>>>> Information Location URL", which is equal to "OpenID Connect Issuer".
>>>>>
>>>>> When I wrote the statement, I thought you were pointing to the URL
>>>>> that you can actually pull the configuration information by "the URL =
of the
>>>>> authorizaiton server's configuration information location" since othe=
rwise
>>>>> you would have used the term "OAuth 2.0 Configuration Information Loc=
ation
>>>>> URL". But after all, you probably meant these two are the same. Then =
I
>>>>> would strongly recommend to fix the language.
>>>>>
>>>>> Now, even If that is the case, the relationship like
>>>>>
>>>>> =C2=B7         iss + .well-know/openid-configuration =3D Connect OP c=
onfig
>>>>> endoint
>>>>>
>>>>> =C2=B7         OAuth config endpoint - .well-known/openid-configurati=
on =3D
>>>>> OAuth iss
>>>>>
>>>>> is very confusing.
>>>>>
>>>>>
>>>>>
>>>>> You also claim that your approach is simpler, but to me, your approac=
h
>>>>> seem to be overly complex. It requires discovery and the check for th=
e
>>>>> value of the discovered config information to work as the mitigation.
>>>>> (Right. Draft -01 does not have it, so it does not solve the mix-up i=
ssue.)
>>>>> With oauth-meta, you do not need it.
>>>>>
>>>>>
>>>>>
>>>>> Finally, your point that HATEOAS reminds you of WSDL, it is not. If
>>>>> you want to have something similar to WSDL in REST API area, it is Sw=
agger.
>>>>> (Actually, it is gaining a lot of momentum recently, but that's besid=
e the
>>>>> fact ;-). And the point here is not the format but the fact that we n=
eed to
>>>>> have a way to associate metadata to the data. The root cause of this =
mix-up
>>>>> attack is that the metadata and data is not associated properly. We h=
ave a
>>>>> standard way of associating the data and metadata with link-rel such =
as
>>>>> RFC5988 so why not use it? Link-rel-href pattern is used a lot now. M=
ost
>>>>> modern web pages actually have it. Using a proper way to associate me=
tadata
>>>>> with data will save you from a lot of other attacks in the future. In=
stead
>>>>> of doing patch works, we should solve it architecturally.
>>>>>
>>>>>
>>>>>
>>>>> Nat
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 10:34 Mike Jones < 
>>>>> Michael.Jones@microsoft.com>:
>>>>>
>>>>> Nat, I=E2=80=99m confused by this statement in the message you refere=
nce =E2=80=9CUnfortunately,
>>>>> this does not match the value of OAuth issuer defined in Section 2
>>>>> of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as
>>>>> specified in 3.1. As such, validation as specified in bullet 1 of Sec=
tion 4
>>>>> fails in Google's case -- OR it means that the document is internally
>>>>> inconsistent.=E2=80=9D.  The issuer definition in draft-jones-oauth-d=
iscovery
>>>>> is 100% compatible with the one in OpenID Connect Discovery, by desig=
n.  In
>>>>> the Google example, both the OpenID issuer and the OAuth issuer value=
s
>>>>> would be the string =E2=80=9C 
>>>>> https://accounts.google.com=E2=80=9D.  What is the inconsistency that=
 you
>>>>> perceive?
>>>>>
>>>>>
>>>>>
>>>>> The discussion of the duplication problem happened in the private
>>>>> meetings in Yokohama.
>>>>>
>>>>>
>>>>>
>>>>> I will admit, in Yokohama, I didn=E2=80=99t speak up in the public me=
etings to
>>>>> point out that a simpler alternative to oauth-meta was already being
>>>>> discussed there in private, because then I would have had to talk abo=
ut the
>>>>> security issues, which we=E2=80=99d decided not to publicly do at tha=
t point.  So I
>>>>> stayed silent during the poll, out of politeness.  Perhaps I should h=
ave
>>>>> found a way to say something then anyway, but that=E2=80=99s water un=
der the bridge
>>>>> now.
>>>>>
>>>>>
>>>>>
>>>>> Finally, for what it=E2=80=99s worth, the HATEOAS stuff reminds me fa=
r too
>>>>> much of Web Services Description Language (WSDL) =E2=80=93 part of th=
e complexity
>>>>> baggage that helped sink Web Services.  The use of =E2=80=9Clink rel=
=E2=80=9D to define an
>>>>> interaction vocabulary and publish endpoints for that vocabulary seem=
s
>>>>> pretty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=
=80=93 another cute =E2=80=9CWebby=E2=80=9D
>>>>> innovation that never caught on.  The industry has pretty much voted =
with
>>>>> its feet and is using JSON for publishing discovery data structures =
=E2=80=93 not
>>>>> =E2=80=9Clink rel=E2=80=9D.  I am against us reverting to the =E2=80=
=9Clink rel=E2=80=9D proposal from 2008
>>>>> that never caught on when JSON is simpler and does a better job.
>>>>>
>>>>>
>>>>>
>>>>>                                                                 -- Mi=
ke
>>>>>
>>>>>
>>>>>
>>>>> *From:* Nat Sakimura [mailto: sakimura@gmail.com]
>>>>> *Sent:* Thursday, January 21, 2016 6:24 AM
>>>>> *To:* Justin Richer < jricher@mit.edu>; Mike Jones <
>>>>> Michael.Jones@microsoft.com>
>>>>> *Cc:* William Denniss < wdenniss@google.com>; <
>>>>> oauth@ietf.org> < oauth@ietf.org>
>>>>>
>>>>>
>>>>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>>>>
>>>>>
>>>>>
>>>>> Mike,
>>>>>
>>>>>
>>>>>
>>>>> You just criticize my draft. That's ok, but I would really like to ge=
t
>>>>> some response to my questions stated in
>>>>> 
>>>>> https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html .
>>>>> To me, it just does not seem to work, and the combination of the oaut=
h-meta
>>>>> and PKCE seems to be much more elegan, nicer, and much simpler to
>>>>> implement. If you just give up the dynamic response at the authorizat=
ion
>>>>> endpoint, then you even do not have to touch the code but just change=
 a
>>>>> config file.
>>>>>
>>>>>
>>>>>
>>>>> Please convince me by answering to my questions.
>>>>>
>>>>>
>>>>>
>>>>> For the record of Yokohama, I do not recall much about duplication in
>>>>> OAuth session. The poll in the room was 19 for / zero against / 4
>>>>> persons need more information. Indeed, it is not duplicating much. An=
d if
>>>>> you move to a new model without pre-configured discovery, it is not
>>>>> duplicating any but the resource endpoint URI, which is optional and =
is for
>>>>> the cases where the client did not know the concrete resource endpoin=
t to
>>>>> start with.
>>>>>
>>>>>
>>>>>
>>>>> I understand your usecases always start from a concrete endpoint
>>>>> location. Mine do not. In a four party model, it is likely not. The u=
ser
>>>>> just want to have the service to fetch his data from some resource
>>>>> endpoint. He just hits the service. He does not hit the resource endp=
oint
>>>>> directly. For example, in the case of a consumer using a personal fin=
ance
>>>>> platform (PFP)to manage his pension fund, he hits the PFP and not the
>>>>> Pension fund. Assuming that the pension fund has delegated the
>>>>> authorization control to the authorization server, then, the authoriz=
ation
>>>>> server should return both the access token and the endpoint of the pe=
nsion
>>>>> fund so that the PFP can pull the data using them. A similar model ho=
lds
>>>>> for personal health service and health care providers.
>>>>>
>>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>>
>>>>>
>>>>> Nat
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 21:18 Justin Richer < <=
jricher@mit.edu>jricher@mit.edu>:
>>>>>
>>>>> Convergence is exactly what I=E2=80=99m arguing for, though. These th=
ings
>>>>> ought to work together.
>>>>>
>>>>>
>>>>>
>>>>>  =E2=80=94 Justin
>>>>>
>>>>> On Jan 21, 2016, at 2:55 AM, Mike Jones <
>>>>> Michael.Jones@microsoft.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> My memory of the discussions of the oauth-meta draft in Yokohama were
>>>>> that many people felt that it was unnecessarily dynamically duplicati=
ng a
>>>>> lot of information that the client already had.  Most of us that were=
 aware
>>>>> of the attacks then were in favor of a more targeted, minimal approac=
h.
>>>>> You were listened to in Yokohama, but that didn=E2=80=99t necessarily=
 mean that
>>>>> people agreed with the approach.  Participants were already aware of =
the
>>>>> oauth-meta proposal in Darmstadt but no one spoke up in favor of it t=
hat I
>>>>> can recall.  Rather, I think people were thinking that =E2=80=9Cless =
is more=E2=80=9D.
>>>>>
>>>>>
>>>>>
>>>>> There have also been discussions in the last day about how dynamicall=
y
>>>>> returning a resource URL, which oauth-meta does, is both unnecessary =
(since
>>>>> the client initiated the resource authorization already knowing what
>>>>> resource it wants to access) and often problematic, since many
>>>>> authorization servers can authorize access to multiple resources.  If
>>>>> anything, the client should be telling the authorization server what
>>>>> resource it wants to access =E2=80=93 not the other way around.
>>>>>
>>>>>
>>>>>
>>>>> I=E2=80=99m not saying that there aren=E2=80=99t some good ideas in t=
he oauth-meta
>>>>> draft =E2=80=93 I=E2=80=99m sure there are, just as there are in the =
approach designed by
>>>>> the participants in Darmstadt.  While I volunteered to write the firs=
t
>>>>> draft of the mix-up-mitigation approach, it really reflects something=
 a lot
>>>>> of people have already bought into =E2=80=93 as evidenced in the pass=
ion in the
>>>>> high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D thre=
ad, and not just my
>>>>> personal project.
>>>>>
>>>>>
>>>>>
>>>>> If you think there are things missing or wrong in the
>>>>> mix-up-mitigation draft, please say what they are.  That will help us
>>>>> quickly converge on a solution that will work for everyone.
>>>>>
>>>>>
>>>>>
>>>>>                                                           Sincerely,
>>>>>
>>>>>                                                           -- Mike
>>>>>
>>>>>
>>>>>
>>>>> *From:* Nat Sakimura [ mailto:sakimura@gmail.com
>>>>> ]
>>>>> *Sent:* Wednesday, January 20, 2016 11:17 PM
>>>>> *To:* Mike Jones < 
>>>>> Michael.Jones@microsoft.com>; William Denniss < 
>>>>> wdenniss@google.com>; Justin Richer < jricher@mit.ed=
u
>>>>> >
>>>>> *Cc:* oauth@ietf.org
>>>>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>>>>
>>>>>
>>>>>
>>>>> Hi Mike.
>>>>>
>>>>>
>>>>>
>>>>> Conversely, I would like to ask why this approach does not work for
>>>>> Mix-up attack. As Nov stated, we in fact have discussed the approach =
in
>>>>> quite a length back in Yokohama. I really would like to know why it d=
oes
>>>>> not work.
>>>>>
>>>>>
>>>>>
>>>>> Besides, for oauth-meta approach, mix-up attack is only one of the
>>>>> thing it solves.
>>>>>
>>>>>
>>>>>
>>>>> Nat Sakimura
>>>>>
>>>>>
>>>>>
>>>>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones < 
>>>>> Michael.Jones@microsoft.com>:
>>>>>
>>>>> Not to be negative, but I disagree with adopting
>>>>> draft-sakimura-oauth-meta.  We should define and promote one mitigati=
on
>>>>> approach to the mix-up attacks.  Having two would confuse implementer=
s and
>>>>> cause compatibility problems =E2=80=93 reducing overall security.
>>>>>
>>>>>
>>>>>
>>>>> The approach defined in draft-jones-oauth-mix-up-mitigation was
>>>>> created in collaboration with the security researchers who identified=
 the
>>>>> problems in the first place, was vigorously discussed in the security
>>>>> meeting Hannes and Torsten held in Darmstadt, and has been since refi=
ned
>>>>> based on substantial input from the working group.  And at least thre=
e
>>>>> implementers have already stated that they=E2=80=99ve implemented it.=
  I=E2=80=99m not
>>>>> saying that it=E2=80=99s, but if there are things missing or things t=
hat need to be
>>>>> improved in our approach, we should do it there, rather introducing a
>>>>> competing approach.
>>>>>
>>>>>
>>>>>
>>>>> Also, standard OAuth deployments register the client and then use the
>>>>> information gathered at registration time for subsequent protocol
>>>>> interactions.  They do not need all the configuration information for=
 the
>>>>> authorization server to be retransmitted at runtime.  The oauth-meta =
draft
>>>>> goes too far in that direction, at least as I see it.  Returning thin=
gs two
>>>>> ways creates its own problems, as discussed in the Duplicate Informat=
ion
>>>>> Attacks security considerations section (7.2) of the mix-up-mitigatio=
n
>>>>> draft.
>>>>>
>>>>>
>>>>>
>>>>> I=E2=80=99ll note that the mix-up-mitigation approach is compatible w=
ith
>>>>> existing practice in both static and dynamic metadata discovery.  Rep=
lying
>>>>> to Justin=E2=80=99s comment that =E2=80=9CIt's the pre-configured dis=
covery document
>>>>> that's at the root of the mix-up attack in the first place=E2=80=9D =
=E2=80=93 this is
>>>>> not the case.  The attacks can be performed without either discovery =
or
>>>>> dynamic registration.
>>>>>
>>>>>
>>>>>
>>>>> I would be interested in hearing a technical discussion on whether
>>>>> there are aspects of the oauth-meta approach that mitigate aspects of=
 the
>>>>> attacks that the mix-up-mitigation approach does not.  That could hel=
p
>>>>> inform whether there are additional things we should add to or change=
 in
>>>>> the mix-up draft.
>>>>>
>>>>>
>>>>>
>>>>>                                                           -- Mike
>>>>>
>>>>>
>>>>>
>>>>> *From:* OAuth [mailto: oauth-bounces@ietf.org=
]
>>>>> *On Behalf Of *William Denniss
>>>>> *Sent:* Wednesday, January 20, 2016 10:37 PM
>>>>> *To:* Justin Richer < jricher@mit.edu>
>>>>> *Cc:* oauth@ietf.org
>>>>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>>>>
>>>>> +1 to adopt this, and I agree with Justin's comments.
>>>>>
>>>>> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer < 
>>>>> jricher@mit.edu> wrote:
>>>>>
>>>>> +1
>>>>>
>>>>> Inline discovery and pre-configured discovery (ie, .well-known) shoul=
d
>>>>> at the very least be compatible and developed together. It's the
>>>>> pre-configured discovery document that's at the root of the mix-up at=
tack
>>>>> in the first place.
>>>>>
>>>>>  -- Justin
>>>>>
>>>>>
>>>>>
>>>>> On 1/19/2016 10:30 PM, Nat Sakimura wrote:
>>>>>
>>>>> Just to give more context, at IETF 94, I have done a presentation on
>>>>> discovery.
>>>>>
>>>>>
>>>>>
>>>>> According to the minutes,
>>>>>
>>>>>
>>>>>
>>>>>     (f) Discovery (Nat)
>>>>>
>>>>>
>>>>>
>>>>>              Nat explains his document as an example of the work that=
 has to be done
>>>>>
>>>>>              in the area of discovery, which is a topic that has been=
 identified
>>>>>
>>>>>              as necessary for interoperability since many years but s=
o far there
>>>>>
>>>>>              was not time to work on it. Mike, John and Nat are worki=
ng on a new
>>>>>
>>>>>              document that describes additional discovery-relevant co=
mponents.
>>>>>
>>>>>
>>>>>
>>>>>              Poll: 19 for / zero against / 4 persons need more inform=
ation.
>>>>>
>>>>>
>>>>>
>>>>> The document discussed there was
>>>>> 
>>>>> 
>>>>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
>>>>> simple (only 1-page!) but a very powerful document that nudges toward=
s
>>>>> HATEOAS which is at the core of RESTful-ness. It also mitigates the M=
ix-up
>>>>> attack without introducing the concept of issuer which is not in RFC6=
749.
>>>>> It is also good for selecting different endpoints depending on the us=
er
>>>>> authentication and authorization results and more privacy sensitive t=
han
>>>>> pre-announced Discovery document. It also allows you to find to which
>>>>> protected resource endpoint you can use the access token against.
>>>>>
>>>>>
>>>>>
>>>>> In the last sentence of the minutes, it talks about "a new document
>>>>> that describes additional discovery-relevant components". This is
>>>>> 
>>>>> https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went
>>>>> for the call for adoption. However, it is only a half of the story. I
>>>>> believe  
>>>>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was
>>>>> discussed at IETF 94 and had support there should be adopted as well.
>>>>>
>>>>>
>>>>>
>>>>> Nat Sakimura
>>>>>
>>>>>
>>>>>
>>>>>

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


So, is there a lot of cases that the authority section of =
the Good AS's Authorization Endpoint and the Token Endpoints are differ=
ent?=C2=A0
If not, then requiring that they are the same seems to virtu=
ally remove the attack surface for the mix-up related attacks. It does not =
introduce new parameter nor discovery. If it can be done, it probably is no=
t worth adding a new wire protocol element to mitigate the mix-up variants.=
=C2=A0



2016=E5=B9=B41=E6=9C=8827=E6=97=A5(=E6=B0=B4) 4:44 Bri=
an Campbell <bcampbell@pin=
gidentity.com>:
I understand what you're saying but disagree with the premise.=C2=
=A0 

On Tue, Jan =
26, 2016 at 12:07 PM, George Fletcher <gffletch@aol.com> wrot=
e:

    So I'm fine with not
      requiring discovery in the simple case of an RS supporting a
      single AS. However, once the RS moves to supporting multiple
      authorization servers then I believe that discovery based on the
      'iss' string is required. The discovery results can be cached=
 so a
      discovery lookup per transaction is not required.

      

      Thanks,

      George

    

    
On 1/26/16 1:58 PM, Brian Campbell
      wrote:

    

    

      
I'm staying that it's sufficiently unlikely =
that it
        shouldn't be part of the threat model and that a discovery
        lookup on iss isn't necessary. 

        

        

      

      
On Tue, Jan 26, 2016 at 8:21 AM, George
          Fletcher <gffletch@aol.com>
          wrote:

          
 While it's a
                different way of getting the endpoints mixed up, I don'=
t
                think that makes it invalid. If we are going to address
                the attack vector I believe we should solve it for "al=
l"
                cases not just the ones that seem most likely.

                

                Thanks,

                George

              

              
On 1/26/16 8:37 AM, Brian Campbell wrote:

              

              

                
I'm not sure what's described in t=
he blog
                  post is actually a variant of an attack that anyone is
                  really concerned about? A client developer would have
                  to change a production system to use an unfamiliar
                  value for the token endpoint based solely on a an
                  email without even looking at service documentation or
                  metadata. 

                  


                  

                

                
On Fri, Jan 22, 2016 at 6:29
                    PM, Nat Sakimura <sakimura@gmail.com>
                    wrote:

                    
=


                      
I wrote a blog on why the current
                        mix-up draft approach does not solve the issue.=C2=
=A0
                        


                        

                        
                        


                        

                        
Hopefully, the point I am making is clearer
                          by this.=C2=A0

                        


                        

                        
Best,=C2=A0

                        


                        

                        
Nat

                      

                      

                      
=


                        
2016=E5=B9=B41=E6=9C=8823=E6=97=A5=
(=E5=9C=9F) 8:32 Mike Jones
                          <Michael.Jones@microsoft.com>:

                        

                        
<=
/blockquote>
<=
div class=3D"gmail_extra">

                                

                                  
I
                                      like the =E2=80=9Cfrom which t=
he
                                    authorization server's configuratio=
n
                                    information location can be derived=E2=80=9D
                                      language.=C2=A0 Thanks.=C2=A0 I=E2=80=
=99ll plan to
                                      incorporate that the next time the
                                      draft is revised.

                                  
=C2=
=A0

                                  
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

                                      -- Mike

                                  
=C2=
=A0

                                  
From:
                                      Brian Campbell [mailto:bcampbell@pingidentity.com]
                                      

                                      Sent: Friday, January 22,
                                      2016 3:26 PM

                                      To: Nat Sakimura <sakimura@gmail.com>

                                      Cc: Mike Jones <Michael.Jones@microsoft.com=
>;

                                      Justin Richer <jricher@mit.edu>;

                                      <oauth@ietf.org>

                                      <oauth@ietf.org>

                                

                              

                              

                                

                                  


                                      Subject: Re: [OAUTH-WG]
                                      Call for Adoption

                                

                              

                              
<=
/div>
<=
/blockquote>

                                  
=C2=A0

                                  

                                    
I
                                      agree that the language describing
                                      OAuth issuer could and should be
                                      improved. The text now reads like
                                      it is the exact and full URL where
                                      the metadata/discovery document is
                                      located. Perhaps something more
                                      like "the URL from which the
                                      authorization server's
                                      configuration information location
                                      can be derived" and explain that
                                      adding the .well-known bits to the
                                      issuer is where the configuration
                                      information can actually be found.
                                      

                                    

                                  

                                  

                                      
On Thu, Jan
                                        21, 2016 at 7:07 PM, Nat
                                        Sakimura <sakimura@gmail.com>

                                        wrote:

                                      
=

=

=


                                        

                                          
Re: iss.
                                            I discussed this a bit with
                                            Nov in more details. It
                                            probably is a sloppy
                                            language of the specs that
                                            is making it difficult to
                                            read what you wanted to
                                            achieve.=C2=A0

                                          

                                            
=C2=A0
                                          

                                          

                                            
In

                                                mix-up-mitigation draft,
                                                OAuth issuer is "the U=
RL
                                                of the authorization
                                                server's configuration
                                                information location".
                                                In OAuth discovery
                                                draft, there is
                                                something called "OAut=
h
                                                2.0 Configuration
                                                Information Location
                                                URL", which is equal t=
o
                                                "OpenID Connect
                                                Issuer".=C2=A0<=
/p>
                                            
When

                                                I wrote the statement, I
                                                thought you were
                                                pointing to the URL that
                                                you can actually pull
                                                the configuration
                                                information by "the UR=
L
                                                of the authorizaiton
                                                server's configuration
                                                information location"
                                                since otherwise you
                                                would have used the term
                                                "OAuth 2.0 Configurati=
on
                                                Information Location
                                                URL". But after all, y=
ou
                                                probably meant these two
                                                are the same. Then I
                                                would strongly recommend
                                                to fix the language.=C2=A0<=
/span>

                                            
Now,

                                                even If that is the
                                                case, the relationship
                                                like=C2=A0

                                            

                                              =C2=B7=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

                                                  iss

                                                +
                                                .well-know/openid-configura=
tion
                                                =3D Connect OP config
                                                endoint

                                            

                                              =C2=B7=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

                                                  OAuth

                                                config endpoint -
                                                .well-known/openid-configur=
ation
                                                =3D OAuth iss

                                            

                                              
is

                                                  very confusing.=C2=A0

                                            

                                          

                                          

                                            
=C2=A0
                                          

                                          

                                            
You

                                                also claim that your
                                                approach is simpler, but
                                                to me, your approach
                                                seem to be overly
                                                complex. It requires
                                                discovery and the check
                                                for the value of the
                                                discovered config
                                                information to work as
                                                the mitigation. (Right.
                                                Draft -01 does not have
                                                it, so it does not solve
                                                the mix-up issue.) With
                                                oauth-meta, you do not
                                                need it.=C2=A0

                                          

                                          

                                            
=C2=A0
                                          

                                          

                                            
Finally,

                                                your point that HATEOAS
                                                reminds you of WSDL, it
                                                is not. If you want to
                                                have something similar
                                                to WSDL in REST API
                                                area, it is Swagger.
                                                (Actually, it is gaining
                                                a lot of momentum
                                                recently, but that's
                                                beside the fact ;-). And
                                                the point here is not
                                                the format but the fact
                                                that we need to have a
                                                way to associate
                                                metadata to the data.
                                                The root cause of this
                                                mix-up attack is that
                                                the metadata and data is
                                                not associated properly.
                                                We have a standard way
                                                of associating the data
                                                and metadata with
                                                link-rel such as RFC5988
                                                so why not use it?
                                                Link-rel-href pattern is
                                                used a lot now. Most
                                                modern web pages
                                                actually have it. Using
                                                a proper way to
                                                associate metadata with
                                                data will save you from
                                                a lot of other attacks
                                                in the future. Instead
                                                of doing patch works, we
                                                should solve
                                                it=C2=A0architecturally.=C2=
=A0

                                          

                                          

                                            
=C2=A0
                                          

                                          

                                            
Nat

                                          

                                          

                                            
=C2=A0
                                          

                                          

                                            
=C2=A0
                                          

                                        

                                        
=C2=A0

                                        
<=
div class=3D"gmail_extra">

                                          

                                            
2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=
=87=91)
                                              10:34 Mike Jones <Michael.Jones@microsoft=
.com>:

                                          

                                          
=


                                                

                                                  

                                                    
=
Nat,

                                                        I=E2=80=99m confuse=
d by
                                                        this statement
                                                        in the message
                                                        you reference =E2=
=80=9CUnfortunately, th=
is does not match
                                                        the value of
                                                        OAuth issuer
                                                        defined in
                                                        Section 2
                                                        of=C2=A0draft-jones=
-oauth-mix-up-mitigation-01
                                                        nor the 'iss=
9;
                                                        returned as
                                                        specified in
                                                        3.1.=C2=A0As such,
                                                        validation as
                                                        specified in
                                                        bullet 1 of
                                                        Section 4 fails
                                                        in Google's cas=
e
                                                        -- OR it means
                                                        that the
                                                        document is
                                                        internally
                                                        inconsistent.=E2=80=9D.=C2=A0

                                                        The issuer
                                                        definition in
                                                        draft-jones-oauth-d=
iscovery
                                                        is 100%
                                                        compatible with
                                                        the one in
                                                        OpenID Connect
                                                        Discovery, by
                                                        design.=C2=A0 In th=
e
                                                        Google example,
                                                        both the OpenID
                                                        issuer and the
                                                        OAuth issuer
                                                        values would be
                                                        the string =E2=80=
=9Chttps://accounts.google.com=
=E2=80=9D.=C2=A0

                                                        What is the
                                                        inconsistency
                                                        that you
                                                        perceive?
                                                    
=
=C2=A0

                                                    
=
The

                                                        discussion of
                                                        the duplication
                                                        problem happened
                                                        in the private
                                                        meetings in
                                                        Yokohama.
                                                    
=
=C2=A0

                                                    
=
I
                                                        will admit, in
                                                        Yokohama, I
                                                        didn=E2=80=99t spea=
k up
                                                        in the public
                                                        meetings to
                                                        point out that a
                                                        simpler
                                                        alternative to
                                                        oauth-meta was
                                                        already being
                                                        discussed there
                                                        in private,
                                                        because then I
                                                        would have had
                                                        to talk about
                                                        the security
                                                        issues, which
                                                        we=E2=80=99d decide=
d not
                                                        to publicly do
                                                        at that point.=C2=
=A0
                                                        So I stayed
                                                        silent during
                                                        the poll, out of
                                                        politeness.=C2=A0
                                                        Perhaps I should
                                                        have found a way
                                                        to say something
                                                        then anyway, but
                                                        that=E2=80=99s wate=
r
                                                        under the bridge
                                                        now.

                                                    
=
=C2=A0

                                                    
=
Finally,

                                                        for what it=E2=80=
=99s
                                                        worth, the
                                                        HATEOAS stuff
                                                        reminds me far
                                                        too much of Web
                                                        Services
                                                        Description
                                                        Language (WSDL)
                                                        =E2=80=93 part of t=
he
                                                        complexity
                                                        baggage that
                                                        helped sink Web
                                                        Services.=C2=A0 The
                                                        use of =E2=80=9Clin=
k
                                                        rel=E2=80=9D to def=
ine
                                                        an interaction
                                                        vocabulary and
                                                        publish
                                                        endpoints for
                                                        that vocabulary
                                                        seems pretty
                                                        baroque and
                                                        reminiscent of
                                                        =E2=80=9Cmicroforma=
ts=E2=80=9D =E2=80=93
                                                        another cute
                                                        =E2=80=9CWebby=E2=
=80=9D
                                                        innovation that
                                                        never caught
                                                        on.=C2=A0 The
                                                        industry has
                                                        pretty much
                                                        voted with its
                                                        feet and is
                                                        using JSON for
                                                        publishing
                                                        discovery data
                                                        structures =E2=80=
=93 not
                                                        =E2=80=9Clink rel=
=E2=80=9D.=C2=A0 I
                                                        am against us
                                                        reverting to the
                                                        =E2=80=9Clink rel=
=E2=80=9D
                                                        proposal from
                                                        2008 that never
                                                        caught on when
                                                        JSON is simpler
                                                        and does a
                                                        better job.<=
/p>
                                                    
=
=C2=A0

                                                    
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0

                                                        -- Mike

                                                    
=
=C2=A0

                                                    
=
From: Nat
                                                        Sakimura
                                                        [mailto:sakimura@gmail.com]
                                                        

                                                        Sent:
                                                        Thursday,
                                                        January 21, 2016
                                                        6:24 AM

                                                        To:
                                                        Justin Richer
                                                        <jricher@mit.edu>;
                                                        Mike Jones <Michael.Jones@micros=
oft.com>

                                                        Cc:
                                                        William Denniss
                                                        <wdenniss@google.com>;

                                                        <oauth@ietf.org> <oauth@ietf.org>

                                                  

                                                

                                                

                                                  

                                                    
=


                                                        Subject:
                                                        Re: [OAUTH-WG]
                                                        Call for
                                                        Adoption

                                                  

                                                

                                                

                                                    
=
=C2=A0

                                                    

                                                      
Mike,=C2=A0

                                                      

                                                        
=C2=A0

                                                      

                                                      

                                                        
You

                                                          just criticize
                                                          my draft.
                                                          That's ok, bu=
t
                                                          I would really
                                                          like to get
                                                          some response
                                                          to my
                                                          questions
                                                          stated in=C2=A0https://www.ietf.org/mail-archi=
ve/web/oauth/current/msg15483.html=C2=A0.


                                                          To me, it just
                                                          does not seem
                                                          to work, and
                                                          the
                                                          combination of
                                                          the oauth-meta
                                                          and PKCE seems
                                                          to be much
                                                          more elegan,
                                                          nicer, and
                                                          much simpler
                                                          to implement.
                                                          If you just
                                                          give up the
                                                          dynamic
                                                          response at
                                                          the
                                                          authorization
                                                          endpoint, then
                                                          you even do
                                                          not have to
                                                          touch the code
                                                          but just
                                                          change a
                                                          config file.=C2=
=A0

                                                      

                                                      

                                                        
=C2=A0

                                                      

                                                      

                                                        
Please

                                                          convince me by
                                                          answering to
                                                          my questions.=C2=
=A0

                                                      

                                                      

                                                        
=C2=A0

                                                      

                                                      

                                                        
For

                                                          the record of
                                                          Yokohama, I do
                                                          not recall
                                                          much about
                                                          duplication in
                                                          OAuth session.
                                                          The poll in
                                                          the room was=C2=
=A019 for / zero against / 4 pe=
rsons
                                                          need more
                                                          information.
                                                          Indeed, it is
                                                          not
                                                          duplicating
                                                          much. And if
                                                          you move to a
                                                          new model
                                                          without
                                                          pre-configured
                                                          discovery, it
                                                          is not
                                                          duplicating
                                                          any but the
                                                          resource
                                                          endpoint URI,
                                                          which is
                                                          optional and
                                                          is for the
                                                          cases where
                                                          the client did
                                                          not know the
                                                          concrete
                                                          resource
                                                          endpoint to
                                                          start with.=C2=A0=


                                                      

                                                      

                                                        
=C2=A0

                                                      

                                                      

                                                        
I understand your usecases =
always
                                                          start from a
                                                          concrete
                                                          endpoint
                                                          location. Mine
                                                          do not. In a
                                                          four party
                                                          model, it is
                                                          likely not.
                                                          The user just
                                                          want to have
                                                          the service to
                                                          fetch his data
                                                          from some
                                                          resource
                                                          endpoint. He
                                                          just hits the
                                                          service. He
                                                          does not hit
                                                          the resource
                                                          endpoint
                                                          directly. For
                                                          example, in
                                                          the case of a
                                                          consumer using
                                                          a personal
                                                          finance
                                                          platform
                                                          (PFP)to manage
                                                          his pension
                                                          fund, he hits
                                                          the PFP and
                                                          not the
                                                          Pension fund.
                                                          Assuming that
                                                          the pension
                                                          fund has
                                                          delegated the
                                                          authorization
                                                          control to the
                                                          authorization
                                                          server, then,
                                                          the
                                                          authorization
                                                          server should
                                                          return both
                                                          the access
                                                          token and the
                                                          endpoint of
                                                          the pension
                                                          fund so that
                                                          the PFP can
                                                          pull the data
                                                          using them. A
                                                          similar model
                                                          holds for
                                                          personal
                                                          health service
                                                          and health
                                                          care
                                                          providers.=C2=A0<=
/span>

                                                      

                                                      

                                                        
=C2=A0

                                                      

                                                      

                                                        
Best,=C2=A0

                                                      

                                                      

                                                        
=C2=A0

                                                      

                                                      

                                                        
Nat

                                                      

                                                      

                                                        
=C2=A0

                                                      

                                                    

                                                    
=
=C2=A0

                                                    

                                                      

                                                        
2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
                                                          21:18 Justin
                                                          Richer <jricher@mit.edu>:

                                                      

                                                      
=


                                                        

                                                          
Convergence

                                                          is exactly
                                                          what I=E2=80=99m
                                                          arguing for,
                                                          though. These
                                                          things ought
                                                          to work
                                                          together.

                                                        

                                                        

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
=C2=A0=E2=80=94

                                                          Justin

                                                          

                                                        

                                                        
=

<=
/div>
<=
/div>
<=
div class=3D"gmail_extra">
<=
div>

                                                          

                                                          
On

                                                          Jan 21, 2016,
                                                          at 2:55 AM,
                                                          Mike Jones
                                                          <Michael.Jones@microsoft.com>

                                                          wrote:

                                                          

                                                          
=C2=A0

                                                          

                                                          
My

                                                          memory of the
                                                          discussions of
                                                          the oauth-meta
                                                          draft in
                                                          Yokohama were
                                                          that many
                                                          people felt
                                                          that it was
                                                          unnecessarily
                                                          dynamically
                                                          duplicating a
                                                          lot of
                                                          information
                                                          that the
                                                          client already
                                                          had.=C2=A0 Most o=
f
                                                          us that were
                                                          aware of the
                                                          attacks then
                                                          were in favor
                                                          of a more
                                                          targeted,
                                                          minimal
                                                          approach.=C2=A0 Y=
ou
                                                          were listened
                                                          to in
                                                          Yokohama, but
                                                          that didn=E2=80=
=99t
                                                          necessarily
                                                          mean that
                                                          people agreed
                                                          with the
                                                          approach.=C2=A0
                                                          Participants
                                                          were already
                                                          aware of the
                                                          oauth-meta
                                                          proposal in
                                                          Darmstadt but
                                                          no one spoke
                                                          up in favor of
                                                          it that I can
                                                          recall.=C2=A0
                                                          Rather, I
                                                          think people
                                                          were thinking
                                                          that =E2=80=9Cles=
s is
                                                          more=E2=80=9D.

                                                          
=C2=A0

                                                          
There

                                                          have also been
                                                          discussions in
                                                          the last day
                                                          about how
                                                          dynamically
                                                          returning a
                                                          resource URL,
                                                          which
                                                          oauth-meta
                                                          does, is both
                                                          unnecessary
                                                          (since the
                                                          client
                                                          initiated the
                                                          resource
                                                          authorization
                                                          already
                                                          knowing what
                                                          resource it
                                                          wants to
                                                          access) and
                                                          often
                                                          problematic,
                                                          since many
                                                          authorization
                                                          servers can
                                                          authorize
                                                          access to
                                                          multiple
                                                          resources.=C2=A0 =
If
                                                          anything, the
                                                          client should
                                                          be telling the
                                                          authorization
                                                          server what
                                                          resource it
                                                          wants to
                                                          access =E2=80=93 =
not
                                                          the other way
                                                          around.
                                                          
=C2=A0

                                                          
I=E2=80=99m

                                                          not saying
                                                          that there
                                                          aren=E2=80=99t so=
me
                                                          good ideas in
                                                          the oauth-meta
                                                          draft =E2=80=93 I=
=E2=80=99m
                                                          sure there
                                                          are, just as
                                                          there are in
                                                          the approach
                                                          designed by
                                                          the
                                                          participants
                                                          in Darmstadt.=C2=
=A0
                                                          While I
                                                          volunteered to
                                                          write the
                                                          first draft of
                                                          the
                                                          mix-up-mitigation
                                                          approach, it
                                                          really
                                                          reflects
                                                          something a
                                                          lot of people
                                                          have already
                                                          bought into =E2=
=80=93
                                                          as evidenced
                                                          in the passion
                                                          in the
                                                          high-volume
                                                          =E2=80=9CMix-Up A=
bout
                                                          The Mix-Up
                                                          Mitigation=E2=80=
=9D
                                                          thread, and
                                                          not just my
                                                          personal
                                                          project.
                                                          
=C2=A0

                                                          
If

                                                          you think
                                                          there are
                                                          things missing
                                                          or wrong in
                                                          the
                                                          mix-up-mitigation
                                                          draft, please
                                                          say what they
                                                          are.=C2=A0 That
                                                          will help us
                                                          quickly
                                                          converge on a
                                                          solution that
                                                          will work for
                                                          everyone.<=
/p>
                                                          
=C2=A0

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

                                                          Sincerely,=


                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

                                                          -- Mike
                                                          
=C2=A0

                                                          
From: Nat
                                                          Sakimura [mailto:sakimura@gmail.com]
                                                          

                                                          Sent:
                                                          Wednesday,
                                                          January 20,
                                                          2016 11:17 PM

                                                          To:
                                                          Mike Jones
                                                          <Michael.Jones@microsoft.com>;

                                                          William
                                                          Denniss <wdenniss@google.com>;

                                                          Justin Richer
                                                          <jricher@mit.edu>

                                                          Cc: oauth@ietf.org

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          Call for
                                                          Adoption
                                                          
=C2=A0

                                                          

                                                          
Hi

                                                          Mike.=C2=A0

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Conversely,

                                                          I would like
                                                          to ask why
                                                          this approach
                                                          does not work
                                                          for Mix-up
                                                          attack.=C2=A0As N=
ov
                                                          stated, we in
                                                          fact have
                                                          discussed the
                                                          approach in
                                                          quite a length
                                                          back in
                                                          Yokohama. I
                                                          really would
                                                          like to know
                                                          why it does
                                                          not work.=C2=A0
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Besides,

                                                          for oauth-meta
                                                          approach,
                                                          mix-up attack
                                                          is only one of
                                                          the thing it
                                                          solves.=C2=A0

                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Nat

                                                          Sakimura

                                                          

                                                          

                                                          
=C2=A0

                                                          
=

=


                                                          

                                                          
2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
                                                          16:02 Mike
                                                          Jones <Michael.Jones@microsoft=
.com>:

                                                          

                                                          
=

=

=


                                                          

                                                          

                                                          
Not

                                                          to be
                                                          negative, but
                                                          I disagree
                                                          with adopting
                                                          draft-sakimura-oa=
uth-meta.=C2=A0

                                                          We should
                                                          define and
                                                          promote one
                                                          mitigation
                                                          approach to
                                                          the mix-up
                                                          attacks.=C2=A0
                                                          Having two
                                                          would confuse
                                                          implementers
                                                          and cause
                                                          compatibility
                                                          problems =E2=80=
=93
                                                          reducing
                                                          overall
                                                          security.<=
/p>
                                                          
=C2=A0

                                                          
The

                                                          approach
                                                          defined in
                                                          draft-jones-oauth=
-mix-up-mitigation
                                                          was created in
                                                          collaboration
                                                          with the
                                                          security
                                                          researchers
                                                          who identified
                                                          the problems
                                                          in the first
                                                          place, was
                                                          vigorously
                                                          discussed in
                                                          the security
                                                          meeting Hannes
                                                          and Torsten
                                                          held in
                                                          Darmstadt, and
                                                          has been since
                                                          refined based
                                                          on substantial
                                                          input from the
                                                          working
                                                          group.=C2=A0 And =
at
                                                          least three
                                                          implementers
                                                          have already
                                                          stated that
                                                          they=E2=80=99ve
                                                          implemented
                                                          it.=C2=A0 I=E2=80=
=99m not
                                                          saying that
                                                          it=E2=80=99s, but=
 if
                                                          there are
                                                          things missing
                                                          or things that
                                                          need to be
                                                          improved in
                                                          our approach,
                                                          we should do
                                                          it there,
                                                          rather
                                                          introducing a
                                                          competing
                                                          approach.<=
/p>
                                                          
=C2=A0

                                                          
Also,

                                                          standard OAuth
                                                          deployments
                                                          register the
                                                          client and
                                                          then use the
                                                          information
                                                          gathered at
                                                          registration
                                                          time for
                                                          subsequent
                                                          protocol
                                                          interactions.=C2=
=A0
                                                          They do not
                                                          need all the
                                                          configuration
                                                          information
                                                          for the
                                                          authorization
                                                          server to be
                                                          retransmitted
                                                          at runtime.=C2=A0
                                                          The oauth-meta
                                                          draft goes too
                                                          far in that
                                                          direction, at
                                                          least as I see
                                                          it.=C2=A0 Returni=
ng
                                                          things two
                                                          ways creates
                                                          its own
                                                          problems, as
                                                          discussed in
                                                          the Duplicate
                                                          Information
                                                          Attacks
                                                          security
                                                          considerations
                                                          section (7.2)
                                                          of the
                                                          mix-up-mitigation
                                                          draft.

                                                          
=C2=A0

                                                          
I=E2=80=99ll

                                                          note that the
                                                          mix-up-mitigation

                                                          approach is
                                                          compatible
                                                          with existing
                                                          practice in
                                                          both static
                                                          and dynamic
                                                          metadata
                                                          discovery.=C2=A0
                                                          Replying to
                                                          Justin=E2=80=99s
                                                          comment that =E2=
=80=9CIt's

                                                          the
                                                          pre-configured
                                                          discovery
                                                          document
                                                          that's at the
                                                          root of the
                                                          mix-up attack
                                                          in the first
                                                          place=E2=80=9D
                                                          =E2=80=93 this is=
 not
                                                          the case.=C2=A0 T=
he
                                                          attacks can be
                                                          performed
                                                          without either
                                                          discovery or
                                                          dynamic
                                                          registration.

                                                          
=C2=A0

                                                          
I
                                                          would be
                                                          interested in
                                                          hearing a
                                                          technical
                                                          discussion on
                                                          whether there
                                                          are aspects of
                                                          the oauth-meta
                                                          approach that
                                                          mitigate
                                                          aspects of the
                                                          attacks that
                                                          the
                                                          mix-up-mitigation
                                                          approach does
                                                          not.=C2=A0 That
                                                          could help
                                                          inform whether
                                                          there are
                                                          additional
                                                          things we
                                                          should add to
                                                          or change in
                                                          the mix-up
                                                          draft.

                                                          
=C2=A0

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

                                                          -- Mike
                                                          
=C2=A0

                                                          
From:
                                                          OAuth [mailto:oauth-bounces@ietf.org]
                                                          On Behalf
                                                          Of William

                                                          Denniss

                                                          Sent:
                                                          Wednesday,
                                                          January 20,
                                                          2016 10:37 PM

                                                          To:
                                                          Justin Richer
                                                          <jricher@mit.edu>

                                                          Cc: oauth@ietf.org

                                                          Subject:
                                                          Re: [OAUTH-WG]
                                                          Call for
                                                          Adoption
                                                          

                                                          

                                                          
=

=

=


                                                          
+1

                                                          to adopt this,
                                                          and I agree
                                                          with Justin's
                                                          comments.

                                                          
=

<=
/blockquote>=

<=
div>

                                                          
On

                                                          Wed, Jan 20,
                                                          2016 at 9:53
                                                          PM, Justin
                                                          Richer <jricher@mit.edu>

                                                          wrote:

                                                          
=

<=
/div>
<=
/blockquote>
=


                                                          
+1

                                                          

                                                          Inline
                                                          discovery and
                                                          pre-configured
                                                          discovery (ie,
                                                          .well-known)
                                                          should at the
                                                          very least be
                                                          compatible and
                                                          developed
                                                          together. It'=
s
                                                          the
                                                          pre-configured
                                                          discovery
                                                          document
                                                          that's at the
                                                          root of the
                                                          mix-up attack
                                                          in the first
                                                          place.

                                                          

                                                          =C2=A0-- Justin

                                                          
=

<=
/div><=
/blockquote>

                                                          
=C2=A0

                                                          

                                                          
On

                                                          1/19/2016
                                                          10:30 PM, Nat
                                                          Sakimura
                                                          wrote:

                                                          

                                                          
=

<=
/div>
<=
/div>
=


                                                          
Just

                                                          to give more
                                                          context, at
                                                          IETF 94, I
                                                          have done a
                                                          presentation
                                                          on discovery.=C2=
=A0
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
According

                                                          to the
                                                          minutes,=C2=A0
                                                          

                                                          

                                                          
=C2=A0

                                                          

                                                          
=

<=
/div>
<=
/div>
<=
div class=3D"gmail_extra">
<=
div>

                                                          
=C2=A0=C2=A0=C2=A0 (f) Discovery (Nat)
=

<=
blockquote type=3D"cite">
=


                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0Nat explains his document as an example of the work=
 that has to be done

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 in the area of discovery, which is a topic that has been=
 identified

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 as necessary for interoperability since many years but s=
o far there

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 was not time to work on it. Mike, John and Nat are worki=
ng on a new

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 document that describes additional discovery-relevant co=
mponents.

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 

                                                          
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0Poll: 19 for / zero against / 4 persons need more i=
nformation.

                                                          
=C2=A0

                                                          
The

                                                          document
                                                          discussed
                                                          there was 
                                                          <=
/a>https://tools.ietf.org/html/draft-sakimura-oauth-meta-05=
.
                                                          This is a
                                                          simple (only
                                                          1-page!) but a
                                                          very powerful
                                                          document that
                                                          nudges towards
                                                          HATEOAS which
                                                          is at the core
                                                          of
                                                          RESTful-ness.
                                                          It also
                                                          mitigates the
                                                          Mix-up attack
                                                          without
                                                          introducing
                                                          the concept of
                                                          issuer which
                                                          is not in
                                                          RFC6749. It is
                                                          also good for
                                                          selecting
                                                          different
                                                          endpoints
                                                          depending on
                                                          the user
                                                          authentication
                                                          and
                                                          authorization
                                                          results and
                                                          more privacy
                                                          sensitive than
                                                          pre-announced
                                                          Discovery
                                                          document. It
                                                          also allows
                                                          you to find to
                                                          which
                                                          protected
                                                          resource
                                                          endpoint you
                                                          can use the
                                                          access token
                                                          against.=C2=A0
                                                          
=

<=
/div>
<=
/div>
<=
blockquote style=3D"border:none;border-left:solid #cccccc 1.0pt;padding:0in=
 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">

                                                          

                                                          
=C2=A0

                                                          

                                                          
In

                                                          the last
                                                          sentence of
                                                          the minutes,
                                                          it talks about
                                                          "a new
                                                          document that
                                                          describes
                                                          additional
                                                          discovery-relevan=
t
                                                          components".
                                                          This is=C2=A0https://tools.ietf.org/html/draft-jones-oauth=
-discovery-00.=C2=A0


                                                          It went for
                                                          the call for
                                                          adoption.
                                                          However, it is
                                                          only a half of
                                                          the story. I
                                                          believe=C2=A0https://tools.ietf.org/html/draft-sakimura-oauth-me=
ta-05=C2=A0that

                                                          was discussed
                                                          at IETF 94 and
                                                          had support
                                                          there=C2=A0should
                                                          be adopted as
                                                          well.=C2=A0 

                                                          

                                                          
=C2=A0

                                                          

                                                          

                                                          
Nat

                                                          Sakimura

                                                          

                                                          
=C2=A0

                                                          

                                 
=

<=
/div>
<=
/div>

--001a1147b5582882f5052a46c327--


From nobody Tue Jan 26 17:58:25 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F641B334B for ; Tue, 26 Jan 2016 17:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqs4RSbBEyHJ for ; Tue, 26 Jan 2016 17:58:20 -0800 (PST)
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 DDB031B2DC6 for ; Tue, 26 Jan 2016 17:58:19 -0800 (PST)
Received: by mail-qk0-x233.google.com with SMTP id o6so71740663qkc.2 for ; Tue, 26 Jan 2016 17:58:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=4GBBVqd1HFfZRI8a5SCBjId/iwo5wdGgMdmj71zx/rc=; b=DpbbVfpbHkbj55x/aLh5vdkEUX9HJWVaxGy8/hFt/pv9iLm4Y3Qv2+Q0X8N8mC1pn7 j/KqdGz5ClsWuuuVggat1IDvBymiuyLXs0lpQH/hWF0fUJJnE+CnGQIWnX0BHF9+oQv+ s67wQy1DwkGcbC5qcnjjCRUEtBV/W1RNWSYLlOT+DPK4wnTLPICeUEwlBUMSROuBryyr Jbv9Mmt/MlGoenvncuzyssxv2T1iCqSNvEwRvwItcK2glxhKCKFcJkbI4KbylmsZ9v0+ OQ9vsE3n46tjsDhqUYYgI34OYuK3Xqvtu8lTs81JKfFnC6EhUHtbEOo8vtbUGt4VU4bg ulLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=4GBBVqd1HFfZRI8a5SCBjId/iwo5wdGgMdmj71zx/rc=; b=Xr6KAGz2rLgq7iRSWAZo4I3fem63qFScbLzs6NVzIs0Qe7yM9nTG39N5brWX+gL9ka D4MvgRkuD4nHUzyl7ZrPzdoq4C2rgDoLFSmJIRke8LxzugdxdlkeIx3S8UYod84oADUP Ct9G32dxOAUacci8NYUxQMKPQtTtaEWMs0dTJ6ZWkJ/PvgOi/WBEmGNt4D6pgZEGyaN5 RIdZ8343N/vpMsxXRZetSpuSRw2BQZHNjwPC7Y8cy7n866yqwXqTE+fbTUIQBSbP1Y3W zYsnQVA/kROmML4G/t2QAEtzpChh3GnjSOvXGGCPcBiFSfmeLgD2RmJirFkTeDIx2Hph yYhA==
X-Gm-Message-State: AG10YOSQQtvRyJzjT2jbg1xR0LEnAoJjZ1/XRV8opdJtsA+B00GOt1uI2YiDC9NAjccw/uSjo+dD1N5Dm67cGQ==
X-Received: by 10.55.209.69 with SMTP id s66mr15184540qki.55.1453859898923; Tue, 26 Jan 2016 17:58:18 -0800 (PST)
MIME-Version: 1.0
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com>  <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com> <73E18F37-C765-4F62-A690-102D0C794C52@oracle.com> <845FCC92-E0A5-413F-BA4E-53E0D4C4DBD4@gmail.com> <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com> <63914724-175F-47EA-BC48-5FB9E6C5FE87@ve7jtb.com>
In-Reply-To: <63914724-175F-47EA-BC48-5FB9E6C5FE87@ve7jtb.com>
From: Nat Sakimura 
Date: Wed, 27 Jan 2016 01:58:08 +0000
Message-ID: 
To: John Bradley , "Phil Hunt (IDM)" 
Content-Type: multipart/alternative; boundary=001a1147a3c4d42373052a472210
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 01:58:24 -0000

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

John,

Nov is not talking about the redirection endpoint. I just noticed that
3.1.2.1 of RFC 6749 is just asking TLS by "SHOULD" and I think it needs to
be changed to "MUST" but that is not what he is talking about.

Instead, he is talking about before starting the RFC 6749 flow.

In many cases, a non TLS protected sites have "Login with HIdP" button
linked to a URI that initiates the RFC 6749 flow. This portion is not
within  RFC 6749 and this endpoint has no name or no requirement to be TLS
protected. Right, it is very stupid, but there are many sites like that.
As a result, the attacker can insert itself as a proxy, say by providing a
free wifi hotspot, and either re-write the button or the request so that
the RP receives "Login with AIdP" instead of "Login with HIdP".

I have add a note explaining this to
http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/

I also have added a bit of risk analysis on it and considered other risk
control measures as well.

It does not seem to be worthwhile to introduce a new wire-protocol element
to deal with this particular attack. (I regard code cut-and-paste attack a
separate attack.) I am inclining to think that just to TLS protect the
pre-RFC6749 flow portion and add a check to disallow the ASs that has
different authority section for the Auhtz EP and Token EP would be
adequate.

Nat

2016=E5=B9=B41=E6=9C=8827=E6=97=A5(=E6=B0=B4) 2:18 John Bradley :

> Nov,
>
> Are you referring to Sec 3.1.2.1 of RFC 6749.
>
> Stating that the the redirection endpoint SHOULD require TLS, and that th=
e
> AS should warn the user if the redirect URI is not over TLS (Something I
> have never seen done in the real world)
>
> Not using TLS is reasonable when the redirect URI is using a custom schem=
e
> for native apps.
>
> It might almost be reasonable for the token flow where the JS page itself
> is not loaded over TLS so the callback to extract the fragment would not =
be
> as well.
> Note that the token itself is never passed over a non https connection in
> tis case.
> I would argue now that it is irresponsible to have a non TLS protected
> site, but not everyone is going to go along with that.
>
> Using a http scheme URI for the redirect is allowed but is really stupid.
>   We did have a large debate about this when profiling OAuth for Connect.
> We did tighten connect to say that if you are using the code flow then a
> http scheme redirect URI is only allowed if the client is confidential.
>
> John B.
>
> On Jan 26, 2016, at 1:14 AM, Phil Hunt (IDM)  wrote=
:
>
> Still don't see it. Though i think the diagram is wrong (the rp should
> redirct to the ua and not call the authz direct), the IDP should either
> return an error or redirect the RP to TLS.
>
> I don't see this as proper oauth protocol since the RP is MITM the UA
> rather than acting as a client.
>
> Phil
>
> On Jan 25, 2016, at 19:57, nov matake  wrote:
>
> In this flow, AuthZ endpoint is forced to be TLS-protected.
> http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mixup.png
>
> However, RP=E2=80=99s redirect response which causes following AuthZ requ=
est is
> still not TLS-protected, and modified on the attacker=E2=80=99s proxy.
>
> Section 3.2 of this report also describes the same flow.
> http://arxiv.org/pdf/1601.01229v2.pdf
>
> On Jan 26, 2016, at 12:37, Phil Hunt (IDM)  wrote:
>
> Also the authz endpoint is required to force tls. So if the client doesn'=
t
> do it the authz should reject (eg by upgrading to tls).
>
> Phil
>
> On Jan 25, 2016, at 19:29, Phil Hunt (IDM)  wrote:
>
> When the RP acting as the client issues a authorize redirect to the UA it
> has to make it with TLS
>
> Phil
>
> On Jan 25, 2016, at 17:53, Nov Matake  wrote:
>
> It doen't say anything about the first request which initiate the login
> flow.
> It is still a reasonable assumption that RP puts a "login with FB" button
> on a non TLS-protected page.
>
> nov
>
> On Jan 26, 2016, at 10:45, Phil Hunt  wrote:
>
> I would find it hard to believe that is true.
>
> From 6749 Sec 3.1
>
>    Since requests to the authorization endpoint result in user
>    authentication and the transmission of clear-text credentials (in the
>    HTTP response), the authorization server MUST require the use of TLS
>    as described in Section 1.6  when sending requests to the
>    authorization endpoint.
>
>
> Sec 3.1.2.1
>
>    The redirection endpoint SHOULD require the use of TLS as described
>    in Section 1.6  when =
the requested response type is "code" or "token",
>    or when the redirection request will result in the transmission of
>    sensitive credentials over an open network.  This specification does
>    not mandate the use of TLS because at the time of this writing,
>    requiring clients to deploy TLS is a significant hurdle for many
>    client developers.  If TLS is not available, the authorization server
>    SHOULD warn the resource owner about the insecure endpoint prior to
>    redirection (e.g., display a message during the authorization
>    request).
>
>    Lack of transport-layer security can have a severe impact on the
>    security of the client and the protected resources it is authorized
>    to access.  The use of transport-layer security is particularly
>    critical when the authorization process is used as a form of
>    delegated end-user authentication by the client (e.g., third-party
>    sign-in service).
>
>
> Section 10.5 talks about transmission of authorization codes in connectio=
n
> with redirects.
>
> Also see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz
> codes.
>
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On Jan 25, 2016, at 4:52 PM, nov matake  wrote:
>
> The first assumption is coming from the original security report at
> http://arxiv.org/abs/1601.01229.
> RFC 6749 requires TLS between RS and AS, and also between UA and AS, but
> not between UA and RS.
>
> The blog post is based on my Japanese post, and it describes multi-AS cas=
e.
> Nat's another post describes the case which can affect single-AS case too=
.
>
> http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oauth-2-0-rfc6=
749/
>
> nov
>
> On Jan 26, 2016, at 08:22, Phil Hunt  wrote:
>
> Sorry, meant to reply-all.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> Begin forwarded message:
>
> *From: *Phil Hunt 
> *Subject: **Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation=
*
> *Date: *January 25, 2016 at 3:20:19 PM PST
> *To: *Nat Sakimura 
>
> I am having trouble with the very first assumption. The user-agent sets u=
p
> a non TLS protected connection to the RP? That=E2=80=99s a fundamental vi=
olation of
> 6749.
>
> Also, the second statement says the RP (assuming it acts as OAuth client)
> is talking to two IDPs.  That=E2=80=99s still a multi-AS case is it not?
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On Jan 25, 2016, at 2:58 PM, Nat Sakimura  wrote:
>
> Hi Phil,
>
> Since I was not in Darmstadt, I really do not know what was discussed
> there, but with the compromised developer documentation described in
> http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-rfc6749/,
> all RFC6749 clients with a naive implementer will be affected. The client
> does not need to be talking to multiple IdPs.
>
> Nat
>
> 2016=E5=B9=B41=E6=9C=8826=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) :
>
>> I recall making this point in Germany. 99% of existing use is fine. OIDC
>> is probably the largest community that *might* have an issue.
>>
>> I recall proposing a new security document that covers oauth security fo=
r
>> dynamic scenarios. "Dynamic" being broadly defined to mean:
>> * clients who have configured at runtime or install time (including
>> clients that do discovery)
>> * clients that communicate with more than one endpoint
>> * clients that are deployed in large volume and may update frequently
>> (more discussion of "public" cases)
>> * clients that are script based (loaded into browser on the fly)
>> * others?
>>
>> Phil
>>
>> > On Jan 25, 2016, at 10:39, George Fletcher  wrote:
>> >
>> > would
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


John,=C2=A0

Nov is not talking about th=
e redirection endpoint. I just noticed that 3.1.2.1 of RFC 6749 is just ask=
ing TLS by "SHOULD" and I think it needs to be changed to "M=
UST" but that is not what he is talking about.=C2=A0

Instead, he is talking about before starting the RFC 6749 flow.=C2=
=A0

In many cases, a non TLS protected sites have =
"Login with HIdP" button linked to a URI that initiates the RFC 6=
749 flow. This portion is not within =C2=A0RFC 6749 and this endpoint has n=
o name or no requirement to be TLS protected. Right, it is very stupid, but=
 there are many sites like that.=C2=A0
As a result, the attacker =
can insert itself as a proxy, say by providing a free wifi hotspot, and eit=
her re-write the button or the request so that the RP receives "Login =
with AIdP" instead of "Login with HIdP".=C2=A0
I also have added a bit of risk analysis on it and considered o=
ther risk control measures as well.=C2=A0

It does =
not seem to be worthwhile to introduce a new wire-protocol element to deal =
with this particular attack. (I regard code cut-and-paste attack a separate=
 attack.) I am inclining to think that just to TLS protect the pre-RFC6749 =
flow portion and add a check to disallow the ASs that has different authori=
ty section for the Auhtz EP and Token EP would be adequate.=C2=A0

Nat

2016=E5=B9=B41=E6=9C=8827=E6=97=A5(=E6=B0=B4) 2:18 John Bradley <ve7jtb@ve7jtb.com>:
Nov,

=

Are you referring to Sec 3.1.2.1 of RFC 6749.

Stating that the the redirection endpoint SHOULD require TLS, and th=
at the AS should warn the user if the redirect URI is not over TLS (Somethi=
ng I have never seen done in the real world)

Not u=
sing TLS is reasonable when the redirect URI is using a custom scheme for n=
ative apps.

It might almost be reasonable for the =
token flow where the JS page itself is not loaded over TLS so the callback =
to extract the fragment would not be as well.=C2=A0
Note that the=
 token itself is never passed over a non https connection in tis case.
I would argue now that it is irresponsible to have a non TLS protecte=
d site, but not everyone is going to go along with that. =C2=A0
<=
br>
Using a http scheme URI for the redirect is allowed but is re=
ally stupid. =C2=A0 We did have a large debate about this when profiling OA=
uth for Connect.
We did tighten connect to say that if you are us=
ing the code flow then a http scheme redirect URI is only allowed if the cl=
ient is confidential.=C2=A0

John B.
O=
n Jan 26, 2016, at 1:14 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:
Still don't see it. Though i think the dia=
gram is wrong (the rp should redirct to the ua and not call the authz direc=
t), the IDP should either return an error or redirect the RP to TLS.=C2=A0<=
/div>

I don't see this as proper oauth protocol sinc=
e the RP is MITM the UA rather than acting as a client.=C2=A0

Phil

On Jan 25, 2016, at 19:57, nov matake <matake@gmail.com> wrote:

 In this flow, AuthZ endpoint is forced =
to be TLS-protected.

However, RP=E2=80=99s redirect response which causes following AuthZ reque=
st is still not TLS-protected, and modified on the attacker=E2=80=99s proxy=
.

Section 3.2 of this report also describes the sa=
me flow.

On Jan 26, 2016, at 12:37, Phil Hunt (IDM) <=
;phil.hunt@oracle=
.com> wrote:

Also the authz end=
point is required to force tls. So if the client doesn't do it the auth=
z should reject (eg by upgrading to tls).=C2=A0

Phil

O=
n Jan 25, 2016, at 19:29, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

When the RP acting as the client iss=
ues a authorize redirect to the UA it has to make it with TLS

Phil

On Jan 25, 2016, at 17:53, Nov Matake <matake@gmail.com> wrote:

It doen't say anything about th=
e first request which initiate the login flow.
It is still a reasonabl=
e assumption that RP puts a "login with FB" button on a non TLS-p=
rotected page.

nov

On Jan 26, 2016, a=
t 10:45, Phil Hunt <phil.hunt@oracle.com> wrote:

I would find it hard to believe that is true.

From 6749 Sec 3.1=C2=A0
   Since requests to the authorization endpoint resu=
lt in user
   authentication and the transmission of clear-text credentials (in the
   HTTP response), the authorization server MUST require the use of TLS
   as described in Section 1.6 when sending requests to the
   authorization endpoint.


Sec 3.1.2.1=C2=A0
   The redirection endpoint SHOUL=
D require the use of TLS as described
   in Section 1.6 when the requested response type is "code&quo=
t; or "token",
   or when the redirection request will result in the transmission of
   sensitive credentials over an open network.  This specification does
   not mandate the use of TLS because at the time of this writing,
   requiring clients to deploy TLS is a significant hurdle for many
   client developers.  If TLS is not available, the authorization server
   SHOULD warn the resource owner about the insecure endpoint prior to
   redirection (e.g., display a message during the authorization
   request).

   Lack of transport-layer security can have a severe impact on the
   security of the client and the protected resources it is authorized
   to access.  The use of transport-layer security is particularly
   critical when the authorization process is used as a form of
   delegated end-user authentication by the client (e.g., third-party
   sign-in service).


Section 10.5 talks about transmission of au=
thorization codes in connection with redirects.

Al=
so see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz codes.=





<=
span style=3D"border-collapse:separate;line-height:normal;border-spacing:0p=
x">








On Jan 25, 2016, at 4:52 PM, nov ma=
take <matake@gmail=
.com> wrote:

The f=
irst assumption is coming from the original security report at=C2=A0http://arxiv.org/abs=
/1601.01229.
RFC 6749 requires TLS between RS and AS, and also betw=
een UA and AS, but not between UA and RS.

The blog=
 post is based on my Japanese post, and it describes multi-AS case.
Nat's another post describes the case which can affect single-AS cas=
e too.

nov

On Jan 26=
, 2016, at 08:22, Phil Hunt <phil.hunt@oracle.com> wrote:

Sorry, meant to reply-all.



<=
span style=3D"border-collapse:separate;line-height:normal;border-spacing:0p=
x">









Begin forwarded message:

<=
div style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:=
0px">From: Phil Hunt <phil.hunt@oracle.com=
>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
=

Date: January =
25, 2016 at 3:20:19 PM PST
To: =
Nat Sakimura <sakimura@gmail.com>

I am having trouble with the very first assu=
mption. The user-agent sets up a non TLS protected connection to the RP? Th=
at=E2=80=99s a fundamental violation of 6749.

Also, the =
second statement says the RP (assuming it acts as OAuth client) is talking =
to two IDPs.=C2=A0 That=E2=80=99s still a multi-AS case is it not?



<=
span style=3D"border-collapse:separate;line-height:normal;border-spacing:0p=
x">








On Jan 25, 2016, at 2:58 PM, Nat Sa=
kimura <sakimura=
@gmail.com> wrote:

Hi Phil,=C2=A0
Since I was not in Darmstadt, I really do not know what was=
 discussed there, but with the compromised developer documentation describe=
d in=C2=A0http://nat.sakimura.org/2016/01/15/idp-=
mix-up-attack-on-oauth-rfc6749/, all RFC6749 clients with a naive imple=
menter will be affected. The client does not need to be talking to multiple=
 IdPs.=C2=A0

Nat

2016=E5=B9=B41=E6=9C=8826=E6=97=A5(=E7=
=81=AB) 3:58 Phil Hunt (IDM) <phil.hunt@oracle.com>:
I recall making this point in Germany. 99% of existing use is fi=
ne. OIDC is probably the largest community that *might* have an issue.



I recall proposing a new security document that covers oauth security for d=
ynamic scenarios. "Dynamic" being broadly defined to mean:

* clients who have configured at runtime or install time (including clients=
 that do discovery)

* clients that communicate with more than one endpoint

* clients that are deployed in large volume and may update frequently (more=
 discussion of "public" cases)

* clients that are script based (loaded into browser on the fly)

* others?



Phil



> On Jan 25, 2016, at 10:39, George Fletcher <gffletch@aol.com> wrote:

>

> would



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






_______________________________________________
OAuth mailing lis=
t
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/oa=
uth

_______________________=
________________________

OAuth mailing list

OAuth@ietf.org

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



--001a1147a3c4d42373052a472210--


From nobody Tue Jan 26 18:11:32 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902441B339F for ; Tue, 26 Jan 2016 18:11:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPB7k92vWdCG for ; Tue, 26 Jan 2016 18:11:29 -0800 (PST)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD851A00B0 for ; Tue, 26 Jan 2016 18:11:29 -0800 (PST)
Received: by mail-qg0-x229.google.com with SMTP id 6so154355243qgy.1 for ; Tue, 26 Jan 2016 18:11:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=SC5h7GRd82rc8K7oAWVVdrJ/DnKKN/Orcj9RzdPn4aE=; b=cHCL2IqD5ZlXBTMVuX1+MacrziyAKjnGJF5uvODLwbC7jzdmiYckUZ5OgdtUwGgpii sTf09/OQ/F0U2xIMywXxjP0qMvtk1sl0Q5uGSOG0wOe86GrT1XbudJVTnHbZp+P/kcfb VYx4/+5Y/aZsW02BHDxgfF6kp/UwgOvLePDWHAlbGt46dmU4EN59vevpzwAvhQ+5400O ldkYd6qm0vc/V1cw+aPGbFR8hhMSXMeL6IEL+ZHDefLyHKiKy0y7ORX1gFycmI9/sV56 eQ9s+c0c/ssURN7IoCB5JGuI5YQrY6wOC8xCuzLeXvyx4M5lVotocGsGvpj5DeIUavbS wQiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=SC5h7GRd82rc8K7oAWVVdrJ/DnKKN/Orcj9RzdPn4aE=; b=hqpIZSDJD/YQ0aBg1//GPnaSsl6gT7tsF5uhUdow1g9Uvw2A5leLpogSWo/MphIoS5 Bc/cF6vqYO8JqB02H8ZoX5MoH6in1naGXXmCdDvvO+BKK88h6JPRONwkbHKDHoT04x6C Rufvk7LdwOZv/lNxqy+fcVSLl2ny8MzL1UmN4fx6MwynI/8rUbE7uOuUpfU4qKOypqBB 2sSq/Cssy433MY6Zkf7hl88vfz1PdXyi+e2QUznsRPu4/vdDDjdyiAJO2p7XOWUkdTUz HNjKlSZTfZT+JljdcYxuIPKxGsU6i6Gs51clUVOndWP2Tf4hLliY3/NMg740BPJ17i7j d7Vg==
X-Gm-Message-State: AG10YOSzPO6YdWYcj87i27waprOsI7x5IkHUS/oqbHLXVfDJoXDoPHQYU+IJbqWuiaVVXnXbEFF1xoWiohbjIg==
X-Received: by 10.140.101.201 with SMTP id u67mr32659209qge.33.1453860688721;  Tue, 26 Jan 2016 18:11:28 -0800 (PST)
MIME-Version: 1.0
References:  <8A68406E-0C0F-4CDB-A510-3C139CEE3AF4@ve7jtb.com>
In-Reply-To: <8A68406E-0C0F-4CDB-A510-3C139CEE3AF4@ve7jtb.com>
From: Nat Sakimura 
Date: Wed, 27 Jan 2016 02:11:19 +0000
Message-ID: 
To: John Bradley , Dominick Baier 
Content-Type: multipart/alternative; boundary=001a11c16e6ae77b60052a4751b4
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] PKCE & Hybrid Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 02:11:31 -0000

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

To the end, perhaps amending RFC6749 so that the response type is treated
as a space separated value would be a better way to go?

2016=E5=B9=B41=E6=9C=8827=E6=97=A5(=E6=B0=B4) 5:20 John Bradley :

> Yes it also applies to the =E2=80=9Ccode id_token=E2=80=9D response_type.=
   It would also
> apply to =E2=80=9Ccode token=E2=80=9D , =E2=80=9Ccode token id_token=E2=
=80=9D response types as well though
> I can=E2=80=99t think of why a native app would use those.
>
> We can look at a errata to clarify.  It is a artifact of resonse_type
> being treated as a single string as opposed to being space separated valu=
es
> as most people would expect.
>
> John B.
>
> On Jan 26, 2016, at 5:11 PM, Dominick Baier 
> wrote:
>
> Hi,
>
> PKCE only mentions OAuth 2.0 code flow - but wouldn=E2=80=99t that also a=
pply to
> OIDC hybrid flow e.g. code id_token?
>
> =E2=80=94
> cheers
> Dominick Baier
>
> _______________________________________________
> 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
>

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


To the end, perhaps amending RFC6749 so that the response =
type is treated as a space separated value would be a better way to go?=C2=
=A0

2016=E5=B9=B41=E6=
=9C=8827=E6=97=A5(=E6=B0=B4) 5:20 John Bradley <ve7jtb@ve7jtb.com>:
Yes it also applies to the =E2=80=
=9Ccode id_token=E2=80=9D response_type. =C2=A0 It would also apply to =E2=
=80=9Ccode token=E2=80=9D , =E2=80=9Ccode token id_token=E2=80=9D response =
types as well though I can=E2=80=99t think of why a native app would use th=
ose.

We can look at a errata to clarify.=C2=A0 It is a a=
rtifact of resonse_type being treated as a single string as opposed to bein=
g space separated values as most people would expect.

<=
div>John B.

On Jan 26, 2016, at 5:11 PM, Dominick Baier &l=
t;dbaier@lea=
stprivilege.com> wrote:

Hi,=C2=A0

PKCE only mentions OAuth 2.0 code flow - but=
 wouldn=E2=80=99t that also apply to OIDC hybrid flow e.g. code id_token?
=E2=80=94=C2=
=A0
cheers
Dominick Baier

_=
______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<=
/div>

___________________________________=
____________

OAuth mailing list

OAuth@ietf.org

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




--001a11c16e6ae77b60052a4751b4--


From nobody Tue Jan 26 23:10:36 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428E81B2C45 for ; Tue, 26 Jan 2016 23:10:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUdRxax2yKr5 for ; Tue, 26 Jan 2016 23:10:33 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 C79A41B2C3C for ; Tue, 26 Jan 2016 23:10:32 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id 17so21238lfz.1 for ; Tue, 26 Jan 2016 23:10:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leastprivilege-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=Yvvrmr4aBP8FchzTqyU8gbXzisTm7m6jmUC9f4vh9wo=; b=swe/Uk6jfG/3IoDSbKwatGhJpJ/rIjasXT6Sjs1XtiZsD49WUcC9SacgsXlnOSQqT4 Z4nh6xsK+15FaFT06HuVn/2H8TtFXiFmpT58KrTv0RZHym80fkDy8/P0wviBIXiu8uDr xOFOS/0yh9l9Re0Fij9IS5IGwcRQf0OAVIh1ml/kvYPVBTpMHaGHs7KJFjry6HNN1qWc jEsML00CRzDk9ypFpXcUvhoe+yfx8Ei0ZajeWm2+j1+IVPZZNAu5UKrYcW0fPqbA18F/ clsfLF1Qu/Ba6vYp/OSh5dnR8ynDLa7iKShCf58O3QIJRsrnOh21l1f6dgMe2xFHLyZh sITw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type; bh=Yvvrmr4aBP8FchzTqyU8gbXzisTm7m6jmUC9f4vh9wo=; b=hdxUuq69Qf/LvLSPzg0WO4zikXrRmmu3w9XJMevfryDSjFHI5IF/4EWFk0OG2NQTsr kwiqWj3Eg7bd8wYK5sAcDSBGn9bqXbbbf6NcOvDgyCHWHlftPz2n1R3XCPsf6fYlJHvd PtO5fXaIVtTfx+3k2TDle3kFEENeAfCnFCuXVc603okWxyldQLdvhLa4bsM0wPdPvez7 Yhe/YNXSMafAtn06xZG42843qvDVBpJFtUEOC5SEENWYfuvAjcuX7hh5OVnxusjaUWM6 S0ThDtR8TO1f1++15xdNFSK5tRidH5OCZtyEUcSMx8BeSXPms1W0ozbfslDQ+EEsZE19 awTg==
X-Gm-Message-State: AG10YOSKltiEVgIPf7KlTbl7F192EaYOi5sg51NrEtovCAOXTOPNujqr+VIlQVvOT8R8Qw==
X-Received: by 10.25.4.214 with SMTP id 205mr8073047lfe.90.1453878630867; Tue, 26 Jan 2016 23:10:30 -0800 (PST)
Received: from dombp.local ([80.232.78.190]) by smtp.gmail.com with ESMTPSA id i192sm630310lfb.14.2016.01.26.23.10.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jan 2016 23:10:29 -0800 (PST)
Date: Wed, 27 Jan 2016 08:10:28 +0100
From: Dominick Baier 
To: Nat Sakimura , John Bradley 
Message-ID: 
In-Reply-To: 
References:  <8A68406E-0C0F-4CDB-A510-3C139CEE3AF4@ve7jtb.com> 
X-Mailer: Airmail (351)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="56a86d65_7bb00ece_289"
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] PKCE & Hybrid Flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 27 Jan 2016 07:10:35 -0000

--56a86d65_7bb00ece_289
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Thanks=21

we are almost done implementing PKCE in identity server.

And yea - a comment that PKCE applies to whenever a code is involved woul=
d be probably helpful for other implementers. Even if that makes total se=
nse, it is not obvious.

=E2=80=94=C2=A0
cheers
Dominick Baier


On 27 January 2016 at 03:11:28, Nat Sakimura (sakimura=40gmail.com) wrote=
:

To the end, perhaps amending R=46C6749 so that the response type is treat=
ed as a space separated value would be a better way to go=3F=C2=A0

2016=E5=B9=B41=E6=9C=8827=E6=97=A5(=E6=B0=B4) 5:20 John Bradley :
Yes it also applies to the =E2=80=9Ccode id=5Ftoken=E2=80=9D response=5Ft=
ype. =C2=A0 It would also apply to =E2=80=9Ccode token=E2=80=9D , =E2=80=9C=
code token id=5Ftoken=E2=80=9D response types as well though I can=E2=80=99=
t think of why a native app would use those.

We can look at a errata to clarify.=C2=A0 It is a artifact of resonse=5Ft=
ype being treated as a single string as opposed to being space separated =
values as most people would expect.

John B.

On Jan 26, 2016, at 5:11 PM, Dominick Baier =
 wrote:

Hi,=C2=A0

PKCE only mentions OAuth 2.0 code flow - but wouldn=E2=80=99t that also a=
pply to OIDC hybrid flow e.g. code id=5Ftoken=3F

=E2=80=94=C2=A0
cheers
Dominick Baier

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
OAuth=40ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
OAuth mailing list
OAuth=40ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--56a86d65_7bb00ece_289
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


The OAut=
h-Meta draft <draft-sakimura-oauth-meta-05> returns the token endpoin=
t (in a "turi" query parameter) when redirecting a user from the =
authorization endpoint back to an app. The app presumably then POSTs the &q=
uot;code" (also in the redirect) to "turi" to get an access =
token. However, apps typically send their client_secret to the token endpoi=
nt to authenticate. Sending a client_secret to a URI that came from a user =
is insecure.
 
A RESTful OAuth would be a great improvement, but it doesn&#=
8217;t look like providing the token endpoint (nor discovery endpoint) in a=
 redirect is the right approach.
&n=
bsp;
--
James Manger
 
=

--_000_255B9BB34FB7D647A506DC292726F6E13BB6E3B8E0WSMSG3153Vsrv_--


From nobody Wed Jan 27 20:02:14 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442951B323E for ; Wed, 27 Jan 2016 20:02:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.909
X-Spam-Level: ***
X-Spam-Status: No, score=3.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vr68b_gajqZB for ; Wed, 27 Jan 2016 20:02:11 -0800 (PST)
Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EADF1B323F for ; Wed, 27 Jan 2016 20:02:10 -0800 (PST)
Received: from nriea03.index.or.jp (unknown [172.19.246.38]) by nrifs04.index.or.jp (Postfix) with SMTP id A4F90472EE0; Thu, 28 Jan 2016 13:02:09 +0900 (JST)
Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea03.index.or.jp (unknown) with ESMTP id u0S429oN029023; Thu, 28 Jan 2016 13:02:09 +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 u0S429SF033086; Thu, 28 Jan 2016 13:02:09 +0900
Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u0S42995033085; Thu, 28 Jan 2016 13:02:09 +0900
X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf13.index.or.jp ([172.100.25.22]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u0S4298H033082; Thu, 28 Jan 2016 13:02:09 +0900
From: "Nat Sakimura" 
To: "'Manger, James'" , 
References: <255B9BB34FB7D647A506DC292726F6E13BB6E3B8E0@WSMSG3153V.srv.dir.telstra.com>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BB6E3B8E0@WSMSG3153V.srv.dir.telstra.com>
Date: Thu, 28 Jan 2016 13:02:10 +0900
Message-ID: <056601d15980$a996bfd0$fcc43f70$@nri.co.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0567_01D159CC.1980FFE0"
X-Mailer: Microsoft Outlook 15.0
X-MailAdviser: 20141126
Thread-Index: AQI8p81KlwM1SsaMd83m7w23juHIdp45pfZA
Content-Language: ja
Archived-At: 
Subject: Re: [OAUTH-WG] oauth-meta: turi allows user to mislead app
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 04:02:14 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0567_01D159CC.1980FFE0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi James, 

 

Right. I thought of the man-in-the-browser case and was originally thinking
of sending them in signed JWT(state,c_hash,a_hash,turi,ruri,duri,.) or
sending HMAC(sha256, state+code+turi+ruri, client_secret) together but
subsequently dropped the idea as anything is broken in the
man-in-the-browser case. The bad user case did not occur to me then. I
should not have dropped the idea. Incidentally, this probably fixes the
cut-n-paste attack as well. For OpenID Connect, it amounts to returning
these parameters in ID Token in the front channel. As you can expect, this
is my preferred way. 

 

If we do not want any crypto, then there has to be additional checks. 

In case of duri, mandating the client to check that the duri = issuer +
.well-known/openid-configuration. 

For turi, it has to match one of the entry listed in the discovery document
or or pre-set configuration. The same applies for ruri. 

We probably want to have a cut-n-paste attack control in place as well. 

 

For the token endpoint response that does not go through user browser, it
should be ok to accept it as true. 

 

--

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 Manger, James
Sent: Thursday, January 28, 2016 11:38 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] oauth-meta: turi allows user to mislead app

 

The OAuth-Meta draft  returns the token
endpoint (in a "turi" query parameter) when redirecting a user from the
authorization endpoint back to an app. The app presumably then POSTs the
"code" (also in the redirect) to "turi" to get an access token. However,
apps typically send their client_secret to the token endpoint to
authenticate. Sending a client_secret to a URI that came from a user is
insecure.

 

A RESTful OAuth would be a great improvement, but it doesn't look like
providing the token endpoint (nor discovery endpoint) in a redirect is the
right approach.

 

--

James Manger

 


------=_NextPart_000_0567_01D159CC.1980FFE0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi James, 
 
Right. I thought of the man-in-the-browser case =
and was originally thinking of sending them in signed =
JWT(state,c_hash,a_hash,turi,ruri,duri,…) or sending HMAC(sha256, =
state+code+turi+ruri, client_secret) together but subsequently dropped =
the idea as anything is broken in the man-in-the-browser case. The bad =
user case did not occur to me then. I should not have dropped the idea. =
Incidentally, this probably fixes the cut-n-paste attack as well. For =
OpenID Connect, it amounts to returning these parameters in ID Token in =
the front channel. As you can expect, this is my preferred way. =

 
If we do not want any crypto, then there has to =
be additional checks. 
In case of duri, mandating the client to check =
that the duri =3D issuer + .well-known/openid-configuration. =

For turi, it has to match one of the entry listed =
in the discovery document or or pre-set configuration. The same applies =
for ruri. 
We probably want to have a cut-n-paste attack =
control in place as well. 
 
For the token endpoint response that does not go =
through user browser, it should be ok to accept it as true. =

 
--
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 Manger, James
Sent: Thursday, January 28, =
2016 11:38 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] =
oauth-meta: turi allows user to mislead =
app
 
The OAuth-Meta draft <draft-sakimura-oauth-meta-05> =
returns the token endpoint (in a "turi" query parameter) when =
redirecting a user from the authorization endpoint back to an app. The =
app presumably then POSTs the "code" (also in the redirect) to =
"turi" to get an access token. However, apps typically send =
their client_secret to the token endpoint to authenticate. Sending a =
client_secret to a URI that came from a user is =
insecure.
 
A RESTful OAuth would be a great improvement, but it =
doesn’t look like providing the token endpoint (nor discovery =
endpoint) in a redirect is the right approach.
 
--
James =
Manger
 

------=_NextPart_000_0567_01D159CC.1980FFE0--


From nobody Wed Jan 27 20:34:51 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134641B32DF for ; Wed, 27 Jan 2016 20:34:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.609
X-Spam-Level: 
X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5psccuHPEdd for ; Wed, 27 Jan 2016 20:34:48 -0800 (PST)
Received: from nrifs04.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id B202B1B32DB for ; Wed, 27 Jan 2016 20:34:47 -0800 (PST)
Received: from nriea04.index.or.jp (unknown [172.19.246.39]) by nrifs04.index.or.jp (Postfix) with SMTP id F1A58472EE0; Thu, 28 Jan 2016 13:34:46 +0900 (JST)
Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea04.index.or.jp (unknown) with ESMTP id u0S4Ykg8011634; Thu, 28 Jan 2016 13:34:46 +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 u0S4Ykh6024319; Thu, 28 Jan 2016 13:34:46 +0900
Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id u0S4Yk2Z024318; Thu, 28 Jan 2016 13:34:46 +0900
X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f
Received: from nrizmf15.index.or.jp ([172.100.25.24]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id u0S4YkjI024315; Thu, 28 Jan 2016 13:34:46 +0900
From: "Nat Sakimura" 
To: "'John Bradley'" , "'Justin Richer'" 
References: <569E2076.2090405@gmx.net>           <56A78EEF.4090706@aol.com>  <56A7C3E8.8080601@aol.com>   <56A8794C.2040 304@pingidentity.com>       <1955C44F-BE12-4F1E-899F-546C65ACB657@mit.edu> <7C86947F-7583-4733-B95F-527D17D66F95@ve7jtb.com>
In-Reply-To: <7C86947F-7583-4733-B95F-527D17D66F95@ve7jtb.com>
Date: Thu, 28 Jan 2016 13:34:47 +0900
Message-ID: <057501d15985$380a3310$a81e9930$@nri.co.jp>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0576_01D159D0.A7FB50F0"
X-Mailer: Microsoft Outlook 15.0
X-MailAdviser: 20141126
Thread-Index: AQDygR+GAx+owWfbpcNFYfQApa2pSAH4vDuKAjPINHMCGjiawgKjDK5CArzSwDoCKBG5LwIpfeeNAc+vE7cCbvy07QJjEGRvAhDp1dUCxTEwIAI6q+xjAjYBz1ICoZQpUgIbnZqlAXbznk4CeOFtxgHNWliMArqibkYBmbGFigGGfBAPATp5XA4BLIoKJJ85GLQA
Content-Language: ja
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 04:34:51 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0576_01D159D0.A7FB50F0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

OK. I=E2=80=99m sold.=20

There is no way out without some kind of discovery in the multi-AS case. =


=20

Do I have to worry for the cases that the client is storing the client =
secret with the issuer authority (e.g.,   =
https://example.com/) as the key and sends the client secret to the bad =
issuer   https://example.com/foo/ ? Hope not.=20

=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 John Bradley
Sent: Thursday, January 28, 2016 11:06 AM
To: Justin Richer
Cc: 
Subject: Re: [OAUTH-WG] Call for Adoption

=20

I agree, common origin mapping for OAuth would be a horrible road to go =
down.    Pattern matching redirect URI has been a thorn in =
Facebook=E2=80=99s side that has never worked. =20

=20

At best it would be security theatre, and cripple many legitimate use =
cases.

=20

John B.

=20

On Jan 27, 2016, at 11:02 PM, Justin Richer  > wrote:

=20

Definitely the latter. I don=E2=80=99t think the requirement actually =
helps secure things in practice and artificially limits things =
otherwise.

=20

 =E2=80=94 Justin

=20

On Jan 27, 2016, at 7:19 PM, Nat Sakimura  > wrote:

=20

You mean the string comparison on authority section would allow =
execution of some code? Or are you suggesting that not checking the path =
portion would allow the attacker to plant something on the other paths =
on the host?=20

Yes, the later is possible especially when there are user generated =
content on the same host, and if we are worried on it, we would have to =
do the discovery.=20

Nat=20

=20

2016=E5=B9=B41=E6=9C=8828=E6=97=A5(=E6=9C=A8) 5:45 Justin Richer =
 >:

Unless I=E2=80=99m missing something, requiring the authority section to =
match discounts attackers being able to deploy executable code on a =
path. This kind of hole was exploited in a number of Facebook hacks. Yes =
I=E2=80=99m aware that those were dealing with redirect URIs but =
we=E2=80=99re talking about the same kind of sub-component URI matching =
here, and I can only see it getting us into trouble.

=20

 =E2=80=94 Justin

=20

=20

On Jan 27, 2016, at 1:15 PM, Nat Sakimura  > wrote:

=20

yeah.=20

=20

But for Google, Microsoft, etc., every RP can whitelist, cannot they? =
;-)

=20

Otherwise, for a code phishing attack, you need to implement discovery =
of some sort. My thinking before reading your email was:=20

=20

if( authority(authz_ep)=3D=3Dauthority(token_ep) ) {

   get_token(token_ep, code, client_credential);

} else {

    get_token(token_ep_from_discovery(), code, client_credential);

}=20

=20

where token_ep_from_discovery() either returns the value of the =
toke_endpoint member from .well-known/openid-configuration OR the value =
of turi parameter in the query.=20

=20

2016=E5=B9=B41=E6=9C=8828=E6=97=A5(=E6=9C=A8) 2:03 Brian Campbell =
 >:

There's at least one smallish deployment that has a different authority =
for the Authorization Endpoint and the Token Endpoint.

from https://accounts.google.com/.well-known/openid-configuration :

=20

{
 "issuer": "https://accounts.google.com  =
",
 "authorization_endpoint": =
"https://accounts.google.com/o/oauth2/v2/auth",
 "token_endpoint": "https://www.googleapis.com/oauth2/v4/token",
 "userinfo_endpoint": "https://www.googleapis.com/oauth2/v3/userinfo",
 "revocation_endpoint": "https://accounts.google.com/o/oauth2/revoke",
 "jwks_uri": "https://www.googleapis.com/oauth2/v3/certs",
 ...
}

=20

=20

On Wed, Jan 27, 2016 at 6:30 AM, John Bradley  > wrote:

It think requiring a common authority segment for the authorization =
endpoint and the token endpoint might work in common cases, but there =
are legitimate cases where the URI of the Authorization endpoint might =
be a alias in the case of multi tenants, all using a common token =
endpoint.

The larger problem would be the RS, it is not uncommon to have the AS =
and RS in different domains,  so with bearer tokens unless you make the =
same authority restriction for RS then you are not really stoping the =
attacker.   They can get the AT by impersonating the RS.

I think trying to enforce a common origin policy over OAuth would be a =
bad direction to go.

I understand that it seems like a easy fix on the surface, and it works =
for most of the things people are using OAuth for today, but would be =
quite limiting over the long term.

John B.

> On Jan 27, 2016, at 7:31 AM, sakimura@gmail.com =
  wrote:
>
> Hi Hans,
>
> Sorry, I mixed up the IdP mix-up attack and the code phishing attack.
>
> Mandating the Authorization and Token Endpoint being in the same
> authority would solve the later without changing the wire protocol.
>
> For AS mix-up attack, mandating the client to change the redirection =
endpoint
> per AS would solve the problem without change the wire protocol.
>
> If these are not possible, then we would have to look at changing the
> wire protocol. The solution that solves the both cases must
> provide the token endpoint URI authoritatively, which means
> you have to mandate some variation of discovery mandatory.
>
> Nat
>
>
> At 2016-01-27 17:01  Hans Zandbelt wrote:
>> I don't see how that can deal with the specific form of the attack
>> where the Client would have sent the authorization request to the
>> legitimate authorization endpoint of a compromised AS and believes it
>> gets the response from that, where in fact it was redirected away to
>> the good AS.
>> IOW, I don't think this is so much about mixing up endpoints where to
>> send stuff to, but mixing up the entity/endpoint from which the =
Client
>> believes the response was received. That may just be terminology
>> though.
>> Bottom line as far as I see is that a wire protocol element in the
>> response is needed to tell the Client who issued it, regardless of =
how
>> the Client deals with configuration of the AS information.
>> Hans.
>> On 1/27/16 1:31 AM, Nat Sakimura wrote:
>>> So, is there a lot of cases that the authority section of the Good =
AS's
>>> Authorization Endpoint and the Token Endpoints are different?
>>> If not, then requiring that they are the same seems to virtually =
remove
>>> the attack surface for the mix-up related attacks. It does not =
introduce
>>> new parameter nor discovery. If it can be done, it probably is not =
worth
>>> adding a new wire protocol element to mitigate the mix-up variants.
>
>

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


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

=20

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

=20

=20

=20


------=_NextPart_000_0576_01D159D0.A7FB50F0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


O=
K. I=E2=80=99m sold. 
T=
here is no way out without some kind of discovery in the multi-AS case. =

<=
o:p> 
D=
o I have to worry for the cases that the client is storing the client =
secret with the issuer authority (e.g., https://example=
.com/)=
 as the key and sends the client secret to the bad issuer https://example=
.com/foo/ =
? Hope not. 
<=
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=C2=A0 and delete this e-mail.
<=
o:p> 
From:<=
/b> OAuth =
[mailto:oauth-bounces@ietf.org] On Behalf Of John =
Bradley
Sent: Thursday, January 28, 2016 11:06 =
AM
To: Justin Richer
Cc: =
<oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for =
Adoption
 
I agree, common origin mapping for OAuth would be a =
horrible road to go down.    Pattern matching redirect URI has =
been a thorn in Facebook=E2=80=99s side that has never worked. =
 
 
At best it would be security =
theatre, and cripple many legitimate use =
cases.
 
John =
B.
 
On Jan 27, 2016, at 11:02 PM, =
Justin Richer <jricher@mit.edu> =
wrote:
 
Definitely the latter. I =
don=E2=80=99t think the requirement actually helps secure things in =
practice and artificially limits things =
otherwise.
 
 =E2=80=94 =
Justin
 
On Jan 27, 2016, at 7:19 PM, Nat =
Sakimura <sakimura@gmail.com> =
wrote:
 
You mean the string comparison on =
authority section would allow execution of some code? Or are you =
suggesting that not checking the path portion would allow the attacker =
to plant something on the other paths on the host? 

Yes, the =
later is possible especially when there are user generated content on =
the same host, and if we are worried on it, we would have to do the =
discovery. 

Nat 
 
2016=E5=B9=B41=E6=9C=8828=E6=97=A5(=E6=9C=A8) 5:45 Justin Richer =
<jricher@mit.edu>:
Unless I=E2=80=99m missing =
something, requiring the authority section to match discounts attackers =
being able to deploy executable code on a path. This kind of hole was =
exploited in a number of Facebook hacks. Yes I=E2=80=99m aware that =
those were dealing with redirect URIs but we=E2=80=99re talking about =
the same kind of sub-component URI matching here, and I can only see it =
getting us into trouble.
 
 =E2=80=94 =
Justin
 
 
On Jan 27, 2016, at 1:15 PM, Nat =
Sakimura <sakimura@gmail.com> =
wrote:
 
yeah. 
 
But for Google, Microsoft, etc., =
every RP can whitelist, cannot they? =
;-)
 
Otherwise, for a code phishing =
attack, you need to implement discovery of some sort. My thinking before =
reading your email was: 
 
if( =
authority(authz_ep)=3D=3Dauthority(token_ep) ) =
{
   get_token(token_ep, code, =
client_credential);
} else =
{
    get_token(token_ep_from_discovery(), code, =
client_credential);
} 
 
where token_ep_from_discovery() =
either returns the value of the toke_endpoint member from =
.well-known/openid-configuration OR the value of turi parameter in the =
query. 
 
2016=E5=B9=B41=E6=9C=8828=E6=97=A5(=E6=9C=A8) 2:03 Brian Campbell =
<bcampbell@pingidentity.com>:
There's at least one =
smallish deployment that has a different authority for the Authorization =
Endpoint and the Token Endpoint.
from https://accounts.google.com/.well-known/openid-configur=
ation :
 
{
 =
"issuer": "https://accounts.google.com",
 "authorization_endpoint": =
"https://accounts.google.com/o/oauth2/v2/auth",=

 =
"token_endpoint": "https://www.googleapis.com/oauth2/v4/token",
 =
"userinfo_endpoint": "https://www.googleapis.com/oauth2/v3/userinfo"=
,
 =
"revocation_endpoint": "https://accounts.google.com/o/oauth2/revoke",<=
o:p>
 "jwks_uri": =
"https://www.googleapis.com/oauth2/v3/certs",
 =
...
}
 
 
On Wed, Jan 27, 2016 at 6:30 AM, =
John Bradley <ve7jtb@ve7jtb.com> =
wrote:
It think requiring a common authority segment for the =
authorization endpoint and the token endpoint might work in common =
cases, but there are legitimate cases where the URI of the Authorization =
endpoint might be a alias in the case of multi tenants, all using a =
common token endpoint.

The larger problem would be the RS, it is =
not uncommon to have the AS and RS in different domains,  so with =
bearer tokens unless you make the same authority restriction for RS then =
you are not really stoping the attacker.   They can get the AT =
by impersonating the RS.

I think trying to enforce a common =
origin policy over OAuth would be a bad direction to go.

I =
understand that it seems like a easy fix on the surface, and it works =
for most of the things people are using OAuth for today, but would be =
quite limiting over the long term.

John =
B.
> On Jan 27, 2016, at 7:31 AM, sakimura@gmail.com wrote:
>
> Hi =
Hans,
>
> Sorry, I mixed up the IdP mix-up attack and the =
code phishing attack.
>
> Mandating the Authorization and =
Token Endpoint being in the same
> authority would solve the later =
without changing the wire protocol.
>
> For AS mix-up =
attack, mandating the client to change the redirection endpoint
> =
per AS would solve the problem without change the wire =
protocol.
>
> If these are not possible, then we would have =
to look at changing the
> wire protocol. The solution that solves =
the both cases must
> provide the token endpoint URI =
authoritatively, which means
> you have to mandate some variation =
of discovery mandatory.
>
> Nat
>
>
> At =
2016-01-27 17:01  Hans Zandbelt wrote:
>> I don't see how =
that can deal with the specific form of the attack
>> where the =
Client would have sent the authorization request to the
>> =
legitimate authorization endpoint of a compromised AS and believes =
it
>> gets the response from that, where in fact it was =
redirected away to
>> the good AS.
>> IOW, I don't =
think this is so much about mixing up endpoints where to
>> =
send stuff to, but mixing up the entity/endpoint from which the =
Client
>> believes the response was received. That may just be =
terminology
>> though.
>> Bottom line as far as I see =
is that a wire protocol element in the
>> response is needed to =
tell the Client who issued it, regardless of how
>> the Client =
deals with configuration of the AS information.
>> =
Hans.
>> On 1/27/16 1:31 AM, Nat Sakimura =
wrote:
>>> So, is there a lot of cases that the authority =
section of the Good AS's
>>> Authorization Endpoint and the =
Token Endpoints are different?
>>> If not, then requiring =
that they are the same seems to virtually remove
>>> the =
attack surface for the mix-up related attacks. It does not =
introduce
>>> new parameter nor discovery. If it can be =
done, it probably is not worth
>>> adding a new wire =
protocol element to mitigate the mix-up =
variants.
>
>
> =
_______________________________________________
> 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
 
<=
/div>
_______________________________________________
OAuth =
mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
 
<=
/div>
 
<=
/div>
 

------=_NextPart_000_0576_01D159D0.A7FB50F0--


From nobody Wed Jan 27 22:16:51 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44811B3AC1 for ; Wed, 27 Jan 2016 22:16:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.301
X-Spam-Level: 
X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oD2zFowpVGCZ for ; Wed, 27 Jan 2016 22:16:47 -0800 (PST)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3681B3ABF for ; Wed, 27 Jan 2016 22:16:46 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.22,357,1449493200"; d="scan'208,217"; a="55320219"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 28 Jan 2016 17:16:44 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8057"; a="69506049"
Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcavi.tcif.telstra.com.au with ESMTP; 28 Jan 2016 17:16:43 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3702.srv.dir.telstra.com ([fe80::5c01:5192:426d:fe2f%16]) with mapi; Thu, 28 Jan 2016 17:16:43 +1100
From: "Manger, James" 
To: Nat Sakimura , "oauth@ietf.org" 
Date: Thu, 28 Jan 2016 17:16:42 +1100
Thread-Topic: [OAUTH-WG] oauth-meta: turi allows user to mislead app
Thread-Index: AQI8p81KlwM1SsaMd83m7w23juHIdp45pfZAgAAZIYA=
Message-ID: <255B9BB34FB7D647A506DC292726F6E13BB6E3BD12@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E13BB6E3B8E0@WSMSG3153V.srv.dir.telstra.com> <056601d15980$a996bfd0$fcc43f70$@nri.co.jp>
In-Reply-To: <056601d15980$a996bfd0$fcc43f70$@nri.co.jp>
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_255B9BB34FB7D647A506DC292726F6E13BB6E3BD12WSMSG3153Vsrv_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [OAUTH-WG] oauth-meta: turi allows user to mislead app
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 06:16:50 -0000

--_000_255B9BB34FB7D647A506DC292726F6E13BB6E3BD12WSMSG3153Vsrv_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Even if theoretically secure, I don't think it is a good idea to send turi =
and require the client app to confirm it matches (or send duri and match is=
suer+well-known...). It will be too tempting to client apps to just use the=
 turi/duri value.

draft-jones-oauth-mix-up-mitigation-01 is slightly better in sending an "is=
s" id to match, instead of a web address to follow. However, "iss" is actua=
lly a URI and is defined as the basis for discovery. If an app did discover=
y based on "iss" from the redirect it would be insecure. So I think apps us=
ing different redirect URIs for different ASs is a better idea (which happe=
ns to be the fix suggested in the paper on the "IdP Mix-Up" attack).

If we have to send something that another party should match, but not other=
wise use, it might be better to send a hash instead of the actual value. Th=
at feel much harder for apps or servers to accidentally misuse insecurely.

--
James Manger


From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]
Sent: Thursday, 28 January 2016 3:02 PM
To: Manger, James ; oauth@ietf.org
Subject: RE: [OAUTH-WG] oauth-meta: turi allows user to mislead app

Hi James,

Right. I thought of the man-in-the-browser case and was originally thinking=
 of sending them in signed JWT(state,c_hash,a_hash,turi,ruri,duri,...) or s=
ending HMAC(sha256, state+code+turi+ruri, client_secret) together but subse=
quently dropped the idea as anything is broken in the man-in-the-browser ca=
se. The bad user case did not occur to me then. I should not have dropped t=
he idea. Incidentally, this probably fixes the cut-n-paste attack as well. =
For OpenID Connect, it amounts to returning these parameters in ID Token in=
 the front channel. As you can expect, this is my preferred way.

If we do not want any crypto, then there has to be additional checks.
In case of duri, mandating the client to check that the duri =3D issuer + .=
well-known/openid-configuration.
For turi, it has to match one of the entry listed in the discovery document=
 or or pre-set configuration. The same applies for ruri.
We probably want to have a cut-n-paste attack control in place as well.

For the token endpoint response that does not go through user browser, it s=
hould be ok to accept it as true.

--
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 Manger, James
Sent: Thursday, January 28, 2016 11:38 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] oauth-meta: turi allows user to mislead app

The OAuth-Meta draft  returns the token endpo=
int (in a "turi" query parameter) when redirecting a user from the authoriz=
ation endpoint back to an app. The app presumably then POSTs the "code" (al=
so in the redirect) to "turi" to get an access token. However, apps typical=
ly send their client_secret to the token endpoint to authenticate. Sending =
a client_secret to a URI that came from a user is insecure.

A RESTful OAuth would be a great improvement, but it doesn't look like prov=
iding the token endpoint (nor discovery endpoint) in a redirect is the righ=
t approach.

--
James Manger


--_000_255B9BB34FB7D647A506DC292726F6E13BB6E3BD12WSMSG3153Vsrv_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Even if theoretically secure, I don’t think it =
is a good idea to send turi and require the client app to confirm it matche=
s (or send duri and match issuer+well-known…). It will be too temptin=
g to client apps to just use the turi/duri value.
 
=

draft-jones-oauth-mix-up=
-mitigation-01 is slightly better in sending an "iss" id to match=
, instead of a web address to follow. However, "iss" is actually =
a URI and is defined as the basis for discovery. If an app did discovery ba=
sed on "iss" from the redirect it would be insecure. So I think a=
pps using different redirect URIs for different ASs is a better idea (which=
 happens to be the fix suggested in the paper on the “IdP Mix-Up̶=
1; attack).
 
If we have to send something that another party should match, =
but not otherwise use, it might be better to send a hash instead of the act=
ual value. That feel much harder for apps or servers to accidentally misuse=
 insecurely.
 
--
James Manger
 
 
=
From: Na=
t Sakimura [mailto:n-sakimura@nri.co.jp] 
Sent: Thursday, 28 Janu=
ary 2016 3:02 PM
To: Manger, James <James.H.Manger@team.telstr=
a.com>; oauth@ietf.org
Subject: RE: [OAUTH-WG] oauth-meta: tur=
i allows user to mislead app
 
Hi James, 
 
Right. I thought of th=
e man-in-the-browser case and was originally thinking of sending them in si=
gned JWT(state,c_hash,a_hash,turi,ruri,duri,…) or sending HMAC(sha256=
, state+code+turi+ruri, client_secret) together but subsequently dropped th=
e idea as anything is broken in the man-in-the-browser case. The bad user c=
ase did not occur to me then. I should not have dropped the idea. Incidenta=
lly, this probably fixes the cut-n-paste attack as well. For OpenID Connect=
, it amounts to returning these parameters in ID Token in the front channel=
. As you can expect, this is my preferred way. 
 
If we =
do not want any crypto, then there has to be additional checks. =

In =
case of duri, mandating the client to check that the duri =3D issuer + .wel=
l-known/openid-configuration. 
For turi, it has to match one of the =
entry listed in the discovery document or or pre-set configuration. The sam=
e applies for ruri. 
We probably want to have a cut-n-paste attack=
 control in place as well. 
 
For the token endpoint res=
ponse that does not go through user browser, it should be ok to accept it a=
s true. 
 
--
PLEASE READ :This e-mail is confidential and=
 intended for the
named recipient only. If you are not an intended recipien=
t,
please notify the sender  and delete this e-mail.=

 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Manger, Jam=
es
Sent: Thursday, January 28, 2016 11:38 AM
To: oauth@ietf.org
Subject: [OAUTH-WG=
] oauth-meta: turi allows user to mislead app
 
The OAuth-Meta draft <draft-sakimura-oauth-meta-05>=
 returns the token endpoint (in a "turi" query parameter) when re=
directing a user from the authorization endpoint back to an app. The app pr=
esumably then POSTs the "code" (also in the redirect) to "tu=
ri" to get an access token. However, apps typically send their client_=
secret to the token endpoint to authenticate. Sending a client_secret to a =
URI that came from a user is insecure.
<=
o:p> 
A RESTful OAuth would be a great i=
mprovement, but it doesn’t look like providing the token endpoint (no=
r discovery endpoint) in a redirect is the right approach.
 
--
<=
span style=3D'mso-fareast-language:EN-AU'>James Manger
 
=

--_000_255B9BB34FB7D647A506DC292726F6E13BB6E3BD12WSMSG3153Vsrv_--


From nobody Thu Jan 28 01:41:10 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DCB1B2EBD for ; Thu, 28 Jan 2016 01:41:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 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_REPLY=1, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJdWh7QJA9ea for ; Thu, 28 Jan 2016 01:41:06 -0800 (PST)
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 42D941B2E9D for ; Thu, 28 Jan 2016 01:41:06 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id l66so17122377wml.0 for ; Thu, 28 Jan 2016 01:41:06 -0800 (PST)
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-type:content-transfer-encoding; bh=k83cTECkoku8hl4geJG6GT8HxRSivSt6w3cQ6s+u0ms=; b=zBKQr+yb47NDvVKfDTwWqFUO2jatKTW/9wXm7chgRf5QP3qMBV6aDDhLLEWndR155G SFJheOUabq6iklgozONYLIMdGYZCOW5Dih6hEvgwT9d9vZQXlyvL17cRkGLUMJKKKxiZ gA5iuWDjOqbEQVbdnVHQTo+IgjSK2c7ZVtXZtYzI+u+dek7/hx410kIh6bcVd2Gwbhgt DBVkIw0DVTxBQJm+eVp/V5DBGqjCWox11ckD9eR7/RgGbFwJiO+rdNGVfQTFyWDCo0J9 O2V8fuwsXovwiiEpKMdgCW8lPi/XVblY4ukfGLIGRgQjZxwKd/OLmJCzPMCLW2BqR/rw vNEw==
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-type :content-transfer-encoding; bh=k83cTECkoku8hl4geJG6GT8HxRSivSt6w3cQ6s+u0ms=; b=aCB9qDFHZIsQhETXOTOBG204zjxsA+F0Y8GXW3ubHt0+Tz1OfFdi6x0mJadPWhGwTO 3VYelCkb+1WlRIiB7NTt5yZ/vV4yTcE3O2AKusUCGibNTlvJ04WVA/+KUkpOp/9ygVKu hjA4jVpSxU2lW4jHMamwtuVtpwIj0PoycwAS89fb7tivmfkiJiUsm2GryZWAXwUDWunC kWfzFbi5XjYqO7iZZ9vRblbCPnpJLs6LIOrjuEHj5vUgLP80MstH3deo9jyZrELHnfdp qlLTJi0zeTdjBqpLB+CMGtSnc8mdy3rqNqwsYerQsBlGslOW8ZHm6ewIaNHEaeKXgyUH yG8g==
X-Gm-Message-State: AG10YOReM7AcxtZ3o7Gu5tiLRg/8Gm/sDvO0TBlPIAFu+mx8Tj5OFeEPPLdyyqNbFxx/EA==
X-Received: by 10.28.3.131 with SMTP id 125mr2163710wmd.14.1453974064738; Thu, 28 Jan 2016 01:41:04 -0800 (PST)
Received: from [10.36.226.98] ([80.169.137.63]) by smtp.googlemail.com with ESMTPSA id kb5sm10190192wjc.22.2016.01.28.01.41.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jan 2016 01:41:03 -0800 (PST)
To: William Denniss 
References: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> <569CDE25.90908@gmail.com>  <569E08F6.4040600@gmail.com> <56A7B52C.2040302@gmail.com>  <7E08DFCA-ADBC-481A-896A-2725E1F79EFA@mit.edu> <56A8A762.9080004@gmail.com>  <56A8B542.5060208@gmail.com> <56A8BE1B.2080404@aol.com>  <56A8F3A5.8060002@aol.com> <56A8F612.7040208@aol.com> <56A8FA46.60807@gmail.com> 
From: Sergey Beryozkin 
Message-ID: <56A9E223.90207@gmail.com>
Date: Thu, 28 Jan 2016 09:40:51 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 09:41:09 -0000

Hi

On 27/01/16 17:47, William Denniss wrote:
> In our implementation we mostly record grants as per-user,
> per-client_id. However, we treat public clients whose identity we can't
> verify as ineligible for incremental auth. The reason is if a client is
> counterfeiting another client, we don't want to return previous
> authorizations (the user should at least have to grant permissions in
> the context of this other counterfeiting application).  For a public
> client where the return path can be guaranteed by the OS (e.g. Universal
> Links on iOS), this rule can be relaxed, so it's more about public
> clients whose identity cannot be verified (e.g. custom URI scheme, or
> localhost redirect).
>
> I have an idea for how to solve those unverifiable clients too, where
> the client would prove its previous authorization grant by providing the
> current access token on the new "incremental" authorization request.
>
> For verifiable clients, we have an option to "snowball" tokens and
> include previous grants (with the exception of some scopes that need
> per-device approval), using the non-standard param
> include_granted_scopes
> .
> Such a request results in a new token being issued with potentially
> increased scope, we don't automatically increase the scope of previously
> issued tokens.
>
> Perhaps this group could consider standardizing Incremental OAuth. There
> are valuable lessons & techniques that several people here have learnt
> and implemented over the years, as shown by this thread. I might be
> willing to put together a draft.

IMHO it would be very useful, +1

Thanks, Sergey

>
>
>
> On Wed, Jan 27, 2016 at 9:11 AM, Sergey Beryozkin  > wrote:
>
>     Hi George
>
>     Thanks. I think I'll need to spend more time on thinking about the
>     way it has to be implemented, but I guess one thing I realize is
>     that using only access tokens as records for this purpose is not
>     ideal/generic.
>
>     That said, it is not clear to me that a per-instance level consent
>     makes sense only when the dynamic registration is used.
>
>     Suppose we have a statically registered client, with the client id
>     shared between 100 devices or even confidential clients. I'm
>     actually not sure how realistic it is that the same user works with
>     more than one device sharing the same id, but assuming it is
>     possible sometimes, and further, with incremental authentication in
>     place,
>
>     we can have a situation where while working on device1 a user has
>     approved 'a' while on device2 - scope "b", with both devices sharing
>     the same client id.
>
>     May be I'm making it too complex :-)
>
>     Thanks, Sergey
>
>     On 27/01/16 16:53, George Fletcher wrote:
>
>         My recommendation, like the others, is to store consent by
>         client_id:user and then try and leverage dynamic client
>         registration if
>         instance level consent is needed.
>
>         On 1/27/16 11:43 AM, George Fletcher wrote:
>
>             Yes, I was thinking mostly of "native apps"... though you
>             bring up a
>             good point. It would be great if "installable" web apps could do
>             dynamic client registration:)  I suppose for a "public"
>             client that is
>             loaded onto a device, the "installation" process could
>             obtain a new
>             client_id for that instance. Cookies might work, or have the app
>             generate a unique identifier and use that in conjunction
>             with the
>             client_id?
>
>             Thanks,
>             George
>
>             On 1/27/16 11:07 AM, Thomas Broyer wrote:
>
>
>
>                 On Wed, Jan 27, 2016 at 1:54 PM George Fletcher
>                 
>                 >> wrote:
>
>                      The difference might be whether you want to store
>                 the scope
>                      consent by client "instance" vs client_id
>                 application "class".
>
>
>                 Correct me if I'm wrong but this only makes sense for
>                 "native apps",
>                 not for web apps, right?
>                 (of course, now with "installable web apps" –e.g.
>                 progressive web
>                 apps–, lines get blurry; any suggestion how you'd do it
>                 then? cookies?)
>
>
>
>             _______________________________________________
>             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 Jan 28 04:17:33 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BD21B3C95 for ; Thu, 28 Jan 2016 04:17:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCGs9bNGqHjq for ; Thu, 28 Jan 2016 04:17:29 -0800 (PST)
Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 3DC8C1A21C3 for ; Thu, 28 Jan 2016 04:17:29 -0800 (PST)
Received: by mail-qg0-x232.google.com with SMTP id 6so35087450qgy.1 for ; Thu, 28 Jan 2016 04:17:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ntgS1yPO3TrD0/0CYbKMpQitBhWbab5bq1U7DkmCHro=; b=tQU24C7jwMWwe0rYqofCiGciHULBCf0ylDtG63wCuFZ8PFwFhEhXg7yHeobjFnsD8o YsqoOz0IJjW13f42DQtv5li+8DYxzPuvpCQqkng/Buj52YCev4AOxmD8/rLqMsCoAkLu hJDmE9FPpnQXl94mXy6r2EM5hAVgFoGx3BDL9M3yMkZfaTEKBDEswMwPLhZWlqPKAhxq 1B1E2h08PFsSmxiXb7RfiiWvGyDu3+8gVc9YbWq6tXc+7VcjGyMl+SNIfL9V85PsdyS8 XxVy2lQHo0xMgKtxLG7LQjQnsbsa2uiWLqqEOg5KB41gCwYzZo3fZCfTiOK1yqd8y/iX 2x5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ntgS1yPO3TrD0/0CYbKMpQitBhWbab5bq1U7DkmCHro=; b=CxiYuuSHuIU9fb9HOIEZt8CTzFuehmvxNK7lJMRLc89+4wXD4eFpaHvPG162P9pm68 tPtNFoRnTk8fGb50HqMPyXF73i24ZXG6V7AeBp+wz51fNmZ/qtKjuVRbhtJ4NsEmrHRi 82Fvgg1ETlRLBgSzyPX5gMoT4/AcK0lJS6bPNGLKk6X1TZuCNKulaXfAqEgf7gBKIsqM FBwMBtqbxCMioIsBHBbLu/yN/aIB54FlAyR4JmyECH+8JNj5zxY7DFvfmgjv2rJ9EHFx 6Iy2Ll1wRr+mxbyJQuQhHzuQmR9HzGvqCvSXgKxi8wB5kpKhJ6X7gFUZ/irxmIi7Ezev 1uEg==
X-Gm-Message-State: AG10YOTtZuUs8bvYDmLPZgmOf7jqhD5Ypjiw3/ewGwZDY6gshGfYLWxcxXjTYEW7X7ScRA==
X-Received: by 10.140.98.53 with SMTP id n50mr3121003qge.9.1453983448298; Thu, 28 Jan 2016 04:17:28 -0800 (PST)
Received: from [192.168.1.35] ([191.115.49.204]) by smtp.gmail.com with ESMTPSA id m11sm3477930qkl.47.2016.01.28.04.17.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Jan 2016 04:17:27 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_8FAEE555-2A74-4BEA-8D9E-E5320E8AD814"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <56A8FA46.60807@gmail.com>
Date: Thu, 28 Jan 2016 09:17:23 -0300
Message-Id: <68C4E8AC-7C1F-411D-83B9-7C8A0A82FB94@ve7jtb.com>
References: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> <569CDE25.90908@gmail.com>  <569E08F6.4040600@gmail.com> <56A7B52C.2040302@gmail.com>  <7E08DFCA-ADBC-481A-896A-2725E1F79EFA@mit.edu> <56A8A762.9080004@gmail.com>  <56A8B542.5060208@gmail.com> <56A8BE1B.2080404@aol.com>  <56A8F3A5.8060002@aol.com> <56A8F612.7040208@aol.com> <56A8FA46.60807@gmail.com>
To: Sergey Beryozkin 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 12:17:31 -0000

--Apple-Mail=_8FAEE555-2A74-4BEA-8D9E-E5320E8AD814
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Some people want exactly that behaviour.  If the user approves scope A =
on device a and scope B on device b, they want both to have scopes A & =
B.

Given that many AS are custom built for a specific service this can work =
for them.   It really depends on the API/Service what policy you want. =20=


When doing a generic library if it is not selectable someone will =
complain because they wanted it the other way.

Personally I don=E2=80=99t like that approach but perhaps people like =
twitter etc know better.

John B.

> On Jan 27, 2016, at 2:11 PM, Sergey Beryozkin  =
wrote:
>=20
> Hi George
>=20
> Thanks. I think I'll need to spend more time on thinking about the way =
it has to be implemented, but I guess one thing I realize is that using =
only access tokens as records for this purpose is not ideal/generic.
>=20
> That said, it is not clear to me that a per-instance level consent =
makes sense only when the dynamic registration is used.
>=20
> Suppose we have a statically registered client, with the client id =
shared between 100 devices or even confidential clients. I'm actually =
not sure how realistic it is that the same user works with more than one =
device sharing the same id, but assuming it is possible sometimes, and =
further, with incremental authentication in place,
>=20
> we can have a situation where while working on device1 a user has =
approved 'a' while on device2 - scope "b", with both devices sharing the =
same client id.
>=20
> May be I'm making it too complex :-)
>=20
> Thanks, Sergey
>=20
> On 27/01/16 16:53, George Fletcher wrote:
>> My recommendation, like the others, is to store consent by
>> client_id:user and then try and leverage dynamic client registration =
if
>> instance level consent is needed.
>>=20
>> On 1/27/16 11:43 AM, George Fletcher wrote:
>>> Yes, I was thinking mostly of "native apps"... though you bring up a
>>> good point. It would be great if "installable" web apps could do
>>> dynamic client registration:)  I suppose for a "public" client that =
is
>>> loaded onto a device, the "installation" process could obtain a new
>>> client_id for that instance. Cookies might work, or have the app
>>> generate a unique identifier and use that in conjunction with the
>>> client_id?
>>>=20
>>> Thanks,
>>> George
>>>=20
>>> On 1/27/16 11:07 AM, Thomas Broyer wrote:
>>>>=20
>>>>=20
>>>> On Wed, Jan 27, 2016 at 1:54 PM George Fletcher >>> > wrote:
>>>>=20
>>>>    The difference might be whether you want to store the scope
>>>>    consent by client "instance" vs client_id application "class".
>>>>=20
>>>>=20
>>>> Correct me if I'm wrong but this only makes sense for "native =
apps",
>>>> not for web apps, right?
>>>> (of course, now with "installable web apps" =E2=80=93e.g. =
progressive web
>>>> apps=E2=80=93, lines get blurry; any suggestion how you'd do it =
then? cookies?)
>>>=20
>>>=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


--Apple-Mail=_8FAEE555-2A74-4BEA-8D9E-E5320E8AD814
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjgxMjE3MjRaMCMGCSqGSIb3DQEJBDEWBBRPZs+S8uVEDhn861jmaWet
sLRaIDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBSIvqMyUNBEoBuJ/6UugXmpe6nV8zni9OCNrMHIBlYN/eEGoEZGKf5
I6vxGDgyRcL06dCHQdhL6pU10OY9tm7XarrWTOu4sJB/Z/ww8d6pAIlKGzCrC9nByN14k8/g1vsm
O/FoxR8olfg8DabUM5tdK7l14F/6so5+pjP31DUsvC2OAilde+at8k8EJAUTyfAbnowoRjljbeCU
ZjeqwpF+bwCUpPg6gG67hoPMrcD0IO4mXQBu0BqjKG4vZcq52W10nK9NgxC329oP9vznxGAgMOK4
KWAXjByLrNKX+x7HlvMLHVqo3+QKtC5+zaN6ecBR6Kz21t0p6JWEyycQqg/NAAAAAAAA
--Apple-Mail=_8FAEE555-2A74-4BEA-8D9E-E5320E8AD814--


From nobody Thu Jan 28 04:24:29 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D861B3CB6 for ; Thu, 28 Jan 2016 04:24:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVcLNTKRI91z for ; Thu, 28 Jan 2016 04:24:24 -0800 (PST)
Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::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 0E2951B3CB2 for ; Thu, 28 Jan 2016 04:24:23 -0800 (PST)
Received: by mail-qg0-x22a.google.com with SMTP id 6so35282821qgy.1 for ; Thu, 28 Jan 2016 04:24:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=6rTVJjnG5+JkcZErAWzHO038kywZzW7OKlsrmBHmH3E=; b=mPvD/p363ek8nfpD/sjQpnpjeptqQ0V4IRkMzXCBXULnOlBHRfiVMb+9uYc6GbUtvl lrF13Zk4u/8VvLe13O5R2CZ5I02nqniX8KF/wX/2s1izO4T3Pj/6kzyU/wq+2rEhiFP4 2UBLe7EvYymaNZqu7IE2UhYheRqNcqkPihXkRYVnkMyDXGnbzHpN+ClCFBL3QymsGlbc mGKmflBnYnlUK3iah/yRGM3N3kZfa47aBijOPOrnMjSjIAJJ9fbKAPtov/XMyiusM8l6 z5IKzBB2Erl1B4eOxox9OpNTZUFcw2tL/TiJulVDbMT3qdGqZIc4m/iSStLDqgWqNnjC IHQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=6rTVJjnG5+JkcZErAWzHO038kywZzW7OKlsrmBHmH3E=; b=a8iaNAw6SMzMRtVy5aEHa4BgPzZd+QCxJXlKNtcoZ8ZZ+JwbQRZbCLi4c8gSEBSY5m l3uZmZIK3o8xRgyfFYM6FUcOxBDUaAIArfGFS8WlnODJVOEaQIcKTJVgnRtH5T4F2rAi UXhzRbcdW098Ol5kSxjq3GkeBFzxHqnlF1DIV9LRDvJngyECCpAFo/8UBl0U+q4QrRnj ayexgF0E4puQpNtWSq43NLYy51Fypaf40SyC+CK0p5NpU9JRjyx5CugYpWXvtXVZf49j H1q7/75O7hwn4mcWzRPztcsJCwiJfVfmuYDoviV0QKyMpKNYanUdojbWY0rgDbPaDtXZ tyHQ==
X-Gm-Message-State: AG10YOTpZYi0OSVx95GCXNNjSHlJPRn8reM8AqRgBK+JoiR8YNnFdqp9pn0q6DPZ/pKafQ==
X-Received: by 10.140.146.136 with SMTP id 130mr2524860qhs.92.1453983862981; Thu, 28 Jan 2016 04:24:22 -0800 (PST)
Received: from [192.168.1.35] ([191.115.49.204]) by smtp.gmail.com with ESMTPSA id l129sm1230003qhc.24.2016.01.28.04.24.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Jan 2016 04:24:22 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_AE1824E0-D94E-48AC-B1D2-B7D1A63EEB9B"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 28 Jan 2016 09:24:17 -0300
Message-Id: 
References: <78kleo9cmvytysxs1qv8kep0.1453117674832@email.android.com> <569CDE25.90908@gmail.com>  <569E08F6.4040600@gmail.com> <56A7B52C.2040302@gmail.com>  <7E08DFCA-ADBC-481A-896A-2725E1F79EFA@mit.edu> <56A8A762.9080004@gmail.com>  <56A8B542.5060208@gmail.com> <56A8BE1B.2080404@aol.com> 
To: Thomas Broyer 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 12:24:27 -0000

--Apple-Mail=_AE1824E0-D94E-48AC-B1D2-B7D1A63EEB9B
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_3BCF64EF-9BDA-4DF4-881F-AFBAE0B4CD8D"


--Apple-Mail=_3BCF64EF-9BDA-4DF4-881F-AFBAE0B4CD8D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

No web clients often make use of sticky grants.   Sharing client_id =
amongst multiple instances is a native app thing, but stick grants work =
best with confidential clients.

It is to some extent a UI decision by the AS, to tell the user you have =
already granted A & B , they are asking to add C,  or re-prompt the user =
for A, B and C without giving the context.

The other thing to consider is implicit clients without refresh tokens.  =
=20

If the client is JS in the browser then if you remember the grants the =
JS can do a prompt=3Dnone flow to refresh an expired AT in the =
background as long as the browser has a session with the AS.

If you are using an implicit client and don=E2=80=99t support sticky =
grants, you wind up having to have AT that have a lifetime grater than =
what is optimal.

John B.

> On Jan 27, 2016, at 1:07 PM, Thomas Broyer  wrote:
>=20
>=20
>=20
> On Wed, Jan 27, 2016 at 1:54 PM George Fletcher > wrote:
> The difference might be whether you want to store the scope consent by =
client "instance" vs client_id application "class".
>=20
> Correct me if I'm wrong but this only makes sense for "native apps", =
not for web apps, right?
> (of course, now with "installable web apps" =E2=80=93e.g. progressive =
web apps=E2=80=93, lines get blurry; any suggestion how you'd do it =
then? cookies?)
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_3BCF64EF-9BDA-4DF4-881F-AFBAE0B4CD8D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

No web clients often make use of sticky grants.   =
Sharing client_id amongst multiple instances is a native app thing, but =
stick grants work best with confidential clients.

It is to some extent a UI decision by =
the AS, to tell the user you have already granted A & B , they are =
asking to add C,  or re-prompt the user for A, B and C without =
giving the context.

The other thing to consider is implicit clients without =
refresh tokens.   

If the client is JS in the browser then =
if you remember the grants the JS can do a prompt=3Dnone flow to refresh =
an expired AT in the background as long as the browser has a session =
with the AS.

If =
you are using an implicit client and don=E2=80=99t support sticky =
grants, you wind up having to have AT that have a lifetime grater than =
what is optimal.

John B.

On Jan 27, 2016, at 1:07 PM, Thomas Broyer <t.broyer@gmail.com> =
wrote:



On Wed, Jan 27, 2016 =
at 1:54 PM George Fletcher <gffletch@aol.com> wrote:

 =20
   =20
 =20
  

    The =
difference might be whether
      you want to store the scope consent by client "instance" vs
      client_id application "class".

Correct me if I'm wrong =
but this only makes sense for "native apps", not for web apps, =
right?
(of course, now with "installable web apps" =
=E2=80=93e.g. progressive web apps=E2=80=93, lines get blurry; any =
suggestion how you'd do it then? cookies?)

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

=

--Apple-Mail=_3BCF64EF-9BDA-4DF4-881F-AFBAE0B4CD8D--

--Apple-Mail=_AE1824E0-D94E-48AC-B1D2-B7D1A63EEB9B
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjgxMjI0MTdaMCMGCSqGSIb3DQEJBDEWBBQM2++WQzUx192s/e4Pauwl
45w0+DCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBvr5zXaBnuKkUdutKOEM7Jh9JyzjW6nBe01PHvyGtiDYV7GAIZmkNa
MHIjMaiLtEioK2LTiVm8B913KfE4zJTcW5peHGqS9Y+n8cSvGckTqxCNnCdiYu8CvtasbGQ5Q/n7
yp7PeucvzzlgKifE2AelKVc2nklyZgZ2Mz3Q1Cn9qMDlFO08ciR1hqCn0HgUSvS8x+jbyGjEvXeG
gM3M6ofn45bM/7Ju3GXOMASU8aUP8z0+RUvCfrCnrd1pny0T0pMj9fIZzQ842bygurtnBYiEC7nL
6zakmcsURP5iH4K9Sfz0jOq5wyX48VbEUWgywmzihn/o8rFbfl61HkjKXyShAAAAAAAA
--Apple-Mail=_AE1824E0-D94E-48AC-B1D2-B7D1A63EEB9B--


From nobody Thu Jan 28 09:45:21 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617E91A9005 for ; Thu, 28 Jan 2016 09:45:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCUodkw7qPHk for ; Thu, 28 Jan 2016 09:45:17 -0800 (PST)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD271A8FD6 for ; Thu, 28 Jan 2016 09:45:17 -0800 (PST)
Received: by mail-qg0-x229.google.com with SMTP id 6so45070803qgy.1 for ; Thu, 28 Jan 2016 09:45:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=SKIHeY7V7zBazoWK/PE6oXUwShtQhSlyqOKOcnkD8ro=; b=xH0C+4NkG2Mcg4wzTQl9sF1/TJsP5RnFgu1VOG3n70OtHzZ/gMWUjk1TYjnerf1rvP z1XQvt3yBA4GnDaOfZZMQTADQPTLrYB1ZQ7UNYRkvH43remLQDnPnHKvcKgxomi/aD0i t4EjhUm3Vb8QV9JCQv3K2SzHV+9qb6bCiHkAJmDD9mR+7wTDJTEfjclm0Gzzhj3Jcr71 /tYZnNlhXfW1K3cqzNYEW72LOemcwMIynwIB7SuMmysJtaJAjF01fluQJrmJU4onfYaD xEQvxTanFsBIy8outRoejuvRgXtLUQzxOutO7D2wcQLyu6qsSV+XxECOlzBCLTxHFust p1mA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=SKIHeY7V7zBazoWK/PE6oXUwShtQhSlyqOKOcnkD8ro=; b=YjbC7xm/5+HSN9Z1qjsgU3m45KNLNjaUI2qsxjItOlcOkJxBYk6gCzjqaISuzJutOM tN/AcxFmoLwApKQvgr+PVHz/lwk0kG3v4JUoXgRljbi5cKSbFvVHfSgEG8BkLImRPXfm wDcks6ML0Pc1YJGSBJaoUSSCx2rQ/8fItwPUNAFPVPSLLbEcbNGYz6Lk7+vin0OT6Q8j 868bgK2oKNVXOV1nj165GWNcRMcwoIpSKLk71dJ1BXapcOMIHe9+6f3p2X8PHvd/c1v0 Bw9B/98TTwl1ZpkoOhHfuUtkUqfiTqfx4Shht4y6NHlKUX+hipIOhdW1UQ0juRh05bx3 //Zw==
X-Gm-Message-State: AG10YORi3XRcMZO9+BE7eTRhxgc5caomU8uYJkJ062qFoAuocMkS3tNe7hzgBnX68BW/eQ==
X-Received: by 10.140.239.79 with SMTP id k76mr5586155qhc.87.1454003116415; Thu, 28 Jan 2016 09:45:16 -0800 (PST)
Received: from [192.168.1.35] ([191.115.49.204]) by smtp.gmail.com with ESMTPSA id r2sm4299453qki.17.2016.01.28.09.45.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Jan 2016 09:45:15 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_55032834-A5F4-4CAB-94FE-890CF4FA3B6C"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BB6E3BD12@WSMSG3153V.srv.dir.telstra.com>
Date: Thu, 28 Jan 2016 14:45:09 -0300
Message-Id: 
References: <255B9BB34FB7D647A506DC292726F6E13BB6E3B8E0@WSMSG3153V.srv.dir.telstra.com> <056601d15980$a996bfd0$fcc43f70$@nri.co.jp> <255B9BB34FB7D647A506DC292726F6E13BB6E3BD12@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] oauth-meta: turi allows user to mislead app
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 17:45:20 -0000

--Apple-Mail=_55032834-A5F4-4CAB-94FE-890CF4FA3B6C
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6CC0FEF3-2388-42EF-AFF4-E78B2F538F72"


--Apple-Mail=_6CC0FEF3-2388-42EF-AFF4-E78B2F538F72
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

In Draft draft-jones-oauth-mix-up-mitigation-01 the iss in the response =
is compared to the iss that the request was made to, and if they are =
different it is an error. =20

Discovery is done only during registration. =20

This is a point Mike and I have some disagreement on.   He would like to =
do late binding of the issuer and do discovery on the returned issuer to =
support multi tenant.

I think late binding introduces many issues most importantly enabling =
the easy theft of symmetric client credentials.

The string compared could just be a string like a SAML EntityID, and =
that works as long as clients limit themselves to only one client_id per =
iss string.=20
The reason it has to be only one is that you could have a bad guy =
claiming to have the same iss as another AS.

Without checking the integrity of the Authorization URI and token =
endpoint URI then you leave yourself open to attack with multiple =
client_id with the same iss.

In the discovery step iss x points to Authorization endpoint x and token =
endpoint X if you send a request to auth X  of iss X and it says my iss =
is X then you are sage to send code to the token endpoint of iss X.

A uer tampering with iss just breaks the flow and results in an error.  =
They could change it to another valid iss for the client but then the =
client state sent it to X and got it back from Y would cause a error.

I agree that it is important that clients understand that the endpoint =
configuration step is separate from the authorization flow, and the iss =
in the authorization response is an identifier only.   (Yes one that can =
be validated by discovery separately)=20

Having the client compare the iss and client strings that it used for =
the request with the response and throwing an error if they are =
different still seems like the simplest solution to me.

That unfortunately means limiting the client to one client_id per iss =
without discovery.

John B.

> On Jan 28, 2016, at 3:16 AM, Manger, James =
 wrote:
>=20
> Even if theoretically secure, I don=E2=80=99t think it is a good idea =
to send turi and require the client app to confirm it matches (or send =
duri and match issuer+well-known=E2=80=A6). It will be too tempting to =
client apps to just use the turi/duri value.
> =20
> draft-jones-oauth-mix-up-mitigation-01 is slightly better in sending =
an "iss" id to match, instead of a web address to follow. However, "iss" =
is actually a URI and is defined as the basis for discovery. If an app =
did discovery based on "iss" from the redirect it would be insecure. So =
I think apps using different redirect URIs for different ASs is a better =
idea (which happens to be the fix suggested in the paper on the =E2=80=9CI=
dP Mix-Up=E2=80=9D attack).
> =20
> If we have to send something that another party should match, but not =
otherwise use, it might be better to send a hash instead of the actual =
value. That feel much harder for apps or servers to accidentally misuse =
insecurely.
> =20
> --
> James Manger
> =20
> =20
> From: Nat Sakimura [mailto:n-sakimura@nri.co.jp]=20
> Sent: Thursday, 28 January 2016 3:02 PM
> To: Manger, James ; oauth@ietf.org
> Subject: RE: [OAUTH-WG] oauth-meta: turi allows user to mislead app
> =20
> Hi James,=C2=A0 <>
> =20
> Right. I thought of the man-in-the-browser case and was originally =
thinking of sending them in signed =
JWT(state,c_hash,a_hash,turi,ruri,duri,=E2=80=A6) or sending =
HMAC(sha256, state+code+turi+ruri, client_secret) together but =
subsequently dropped the idea as anything is broken in the =
man-in-the-browser case. The bad user case did not occur to me then. I =
should not have dropped the idea. Incidentally, this probably fixes the =
cut-n-paste attack as well. For OpenID Connect, it amounts to returning =
these parameters in ID Token in the front channel. As you can expect, =
this is my preferred way.=20
> =20
> If we do not want any crypto, then there has to be additional checks.=20=

> In case of duri, mandating the client to check that the duri =3D =
issuer + .well-known/openid-configuration.=20
> For turi, it has to match one of the entry listed in the discovery =
document or or pre-set configuration. The same applies for ruri.=20
> We probably want to have a cut-n-paste attack control in place as =
well.=20
> =20
> For the token endpoint response that does not go through user browser, =
it should be ok to accept it as true.=20
> =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 Manger, James
> Sent: Thursday, January 28, 2016 11:38 AM
> To: oauth@ietf.org 
> Subject: [OAUTH-WG] oauth-meta: turi allows user to mislead app
> =20
> The OAuth-Meta draft  returns the token =
endpoint (in a "turi" query parameter) when redirecting a user from the =
authorization endpoint back to an app. The app presumably then POSTs the =
"code" (also in the redirect) to "turi" to get an access token. However, =
apps typically send their client_secret to the token endpoint to =
authenticate. Sending a client_secret to a URI that came from a user is =
insecure.
> =20
> A RESTful OAuth would be a great improvement, but it doesn=E2=80=99t =
look like providing the token endpoint (nor discovery endpoint) in a =
redirect is the right approach.
> =20
> --
> James Manger
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_6CC0FEF3-2388-42EF-AFF4-E78B2F538F72
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

In Draft draft-jones-oauth-mix-up-mitigation-01 the iss in the =
response is compared to the iss that the request was made to, and if =
they are different it is an error.  

Discovery is done only during registration. =
 

This is a point Mike and I have =
some disagreement on.   He would like to do late binding =
of the issuer and do discovery on the returned issuer to support =
multi tenant.

I think late binding introduces many issues most =
importantly enabling the easy theft =
of symmetric client credentials.

The string compared could just be a string like a SAML =
EntityID, and that works as long as clients limit themselves to only one =
client_id per iss string. 
The reason it has to be only one =
is that you could have a bad guy claiming to have the same iss as =
another AS.

Without checking the integrity of =
the Authorization URI and token endpoint URI then you =
leave yourself open to attack with multiple client_id with the =
same iss.

In the discovery step iss x points =
to Authorization endpoint x and token endpoint X if you send a request =
to auth X  of iss X and it says my iss is X then you are sage to =
send code to the token endpoint of iss X.

A uer tampering with iss just breaks the flow and results in =
an error.  They could change it to another valid iss for the client =
but then the client state sent it to X and got it back from Y would =
cause a error.

I agree that it =
is important that clients understand that the =
endpoint configuration step is separate from the authorization =
flow, and the iss in the authorization response is =
an identifier only.   (Yes one that can be validated by =
discovery separately) 

Having the client compare the iss and client strings that it =
used for the request with the response and throwing an error if they =
are different still seems like the simplest solution to =
me.

That unfortunately means =
limiting the client to one client_id per iss without =
discovery.

John B.

On Jan 28, 2016, at 3:16 AM, =
Manger, James <James.H.Manger@team.telstra.com> wrote:

Even if theoretically secure, I don=E2=80=99t think it =
is a good idea to send turi and require the client app to confirm it =
matches (or send duri and match issuer+well-known=E2=80=A6). It will be =
too tempting to client apps to just use the turi/duri value.
 
draft-jones-oauth-mix-up-mitigation-01 is slightly better in =
sending an "iss" id to match, instead of a web address to follow. =
However, "iss" is actually a URI and is defined as the basis for =
discovery. If an app did discovery based on "iss" from the redirect it =
would be insecure. So I think apps using different redirect URIs for =
different ASs is a better idea (which happens to be the fix suggested in =
the paper on the =E2=80=9CIdP Mix-Up=E2=80=9D attack).
 
If we =
have to send something that another party should match, but not =
otherwise use, it might be better to send a hash instead of the actual =
value. That feel much harder for apps or servers to accidentally misuse =
insecurely.
 
--
James Manger
 
 
From: Nat Sakimura [mailto:n-sakimura@nri.co.jp] 
Sent: Thursday, 28 January 2016 =
3:02 PM
To: Manger, James <James.H.Manger@team.telstra.com>; oauth@ietf.org
Subject: RE: [OAUTH-WG] oauth-meta: =
turi allows user to mislead app
 
 
Right. I thought =
of the man-in-the-browser case and was originally thinking of sending =
them in signed JWT(state,c_hash,a_hash,turi,ruri,duri,=E2=80=A6) or =
sending HMAC(sha256, state+code+turi+ruri, client_secret) together but =
subsequently dropped the idea as anything is broken in the =
man-in-the-browser case. The bad user case did not occur to me then. I =
should not have dropped the idea. Incidentally, this probably fixes the =
cut-n-paste attack as well. For OpenID Connect, it amounts to returning =
these parameters in ID Token in the front channel. As you can expect, =
this is my preferred way. 
 
If we do not =
want any crypto, then there has to be additional checks. 
In case of duri, mandating the =
client to check that the duri =3D issuer + =
.well-known/openid-configuration. 
For turi, it has to match one of =
the entry listed in the discovery document or or pre-set configuration. =
The same applies for ruri. 
We probably want to have a =
cut-n-paste attack control in place as well. 
 
For the token =
endpoint response that does not go through user browser, it should be ok =
to accept it as true. 
 
--
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 Manger, =
James
Sent: Thursday, January 28, 2016 =
11:38 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] oauth-meta: turi =
allows user to mislead app
 
The OAuth-Meta draft <draft-sakimura-oauth-meta-05> =
returns the token endpoint (in a "turi" query parameter) when =
redirecting a user from the authorization endpoint back to an app. The =
app presumably then POSTs the "code" (also in the redirect) to "turi" to =
get an access token. However, apps typically send their client_secret to =
the token endpoint to authenticate. Sending a client_secret to a URI =
that came from a user is insecure.
 
A RESTful OAuth would be a great =
improvement, but it doesn=E2=80=99t look like providing the token =
endpoint (nor discovery endpoint) in a redirect is the right =
approach.
 
--
James Manger
 
_______________________________________________
OAuth mailing =
list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

=

--Apple-Mail=_6CC0FEF3-2388-42EF-AFF4-E78B2F538F72--

--Apple-Mail=_55032834-A5F4-4CAB-94FE-890CF4FA3B6C
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjgxNzQ1MDlaMCMGCSqGSIb3DQEJBDEWBBR8LlUzeod2Vw5RYLpNasZ+
Nj5elzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBe3pcrQgVi45UQ5+82jDe+N7NzO8m/eQkzdGp+rF7R9rPWJUHxTaXU
H27nFzkm5cqqRl6XzddAZV6d7cWw2KLbEKC76EypP25SS8g1pz4SPkrz3JFxqGLkL20K78UHQhNs
fKm9XEtiqFwsTgXRkQUTw85PanFklkL+I08guxGp/uYdDFJt6pnBndf+QDciwlJTefFCg+kM/xCq
UDph1iR8CAlFj3DWvw8lSirUxS8wcvaNbQawLqEBO1jJk7MBj9D9nFA0IoJ/5j7DECmQ4DAdx+fY
kTGIRZqHEjqnjo/Sp2rJPX8fcF8Zuuw8PIvvkmzteabQbnlmgM3l2yAXi3XqAAAAAAAA
--Apple-Mail=_55032834-A5F4-4CAB-94FE-890CF4FA3B6C--


From nobody Thu Jan 28 09:53:56 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D401A9029 for ; Thu, 28 Jan 2016 09:53:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KDeH-LxeheT for ; Thu, 28 Jan 2016 09:53:52 -0800 (PST)
Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8F01A8B84 for ; Thu, 28 Jan 2016 09:53:52 -0800 (PST)
Received: by mail-qg0-x229.google.com with SMTP id b35so45279729qge.0 for ; Thu, 28 Jan 2016 09:53:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Y1AoMu8xa1LtnAjYidVSjyNFCSpDPQHxvDFtfiBYJTw=; b=yBEFAk5yMZ5W+9jWjqWffDkfBawF3JOUBQzJKjixEHpfOsilY1zLmKCgRJZbfpN1q6 WCbXhSVQ1HeFchAfeh+Vq9ojY+eV3ua7BA7sS+VpA/el+HCRZC3c6FtbVvpKwNC3zsOy TpVlXfLy71DcKC3iR4yF8JAiXlToaGA+juVkUT+LWqcikP9Xvhv/bR5TU2V4DLCU/1vB 2lbQUvi39INn6xcIv3J77Igr22eiQbaetAZ8hTJx1JsvOSjdMBCq3AXQPIKNQmXk/kC/ RPxJ51OSst1PDhtd2a/d5QSf2neze7PrCg4HV3a6tGzXJSttKThO5YRc9gmaBr663GOs EJGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Y1AoMu8xa1LtnAjYidVSjyNFCSpDPQHxvDFtfiBYJTw=; b=SjGxNaeNfXbEx6/EFdkeOrp5WeT2WDqxW5GslPTpGxfuMX51wNXXFtDfNX7auYk3dZ XbGe5eLe0EwRlbJe8JR7JHaV+HOKxIRDKZHYE23qeQVufMtcpQXEYGXkQQwES43L/TzV i1hvjRgcSXwMN+4cNsBEQbInupfAlHTF8qRFHxTPkEpjtH1VghilIj+eGw0kXeNNkzii 9cYCUsX8Nr+v7fanlVU4jQiN6whw74Nuz9M/UPN1QoMjc+bwTXt8s7PkzTuEpKT6lpyG CN18EpOEOJ5tZN9uAt6bWF6Fy/+7zVfitu1eWc8C5RC5Xy5THNq4wmJvOwWqHl7vUrRp IWww==
X-Gm-Message-State: AG10YOSdsQNHbyJbtatW1haXd/mUdC/Sc6haAl6Qp36i6TKL9CVILUOMRkJ+8YF+CEHDKg==
X-Received: by 10.140.92.215 with SMTP id b81mr5330348qge.44.1454003630295; Thu, 28 Jan 2016 09:53:50 -0800 (PST)
Received: from [192.168.1.35] ([191.115.49.204]) by smtp.gmail.com with ESMTPSA id d62sm5235317qga.41.2016.01.28.09.53.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 28 Jan 2016 09:53:49 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_BAFC9259-7646-487D-BFEE-BB35D037AA1F"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 28 Jan 2016 14:53:46 -0300
Message-Id: <5DC2FC1D-CBBA-4FB8-9358-0D1A046D8A99@ve7jtb.com>
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com>  <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com> <73E18F37-C765-4F62-A690-102D0C794C52@oracle.com> <845FCC92-E0A5-413F-BA4E-53E0D4C4DBD4@gmail.com> <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com> <63914724-175F-47EA-BC48-5FB9E6C5FE87@ve7jtb.com>  <56A8BB7C.80702@aol.com> <56A8BCC3.6030903@aol.com>   <56A92F08.9050706@pingidentity.com>  <56A962FA.2010004@pingidentity.com> 
To: Nat Sakimura 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 17:53:54 -0000

--Apple-Mail=_BAFC9259-7646-487D-BFEE-BB35D037AA1F
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_07ACE604-F73D-4457-ADBF-43850131EA05"


--Apple-Mail=_07ACE604-F73D-4457-ADBF-43850131EA05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Yes,  I note either mitigation in draft-jones-oauth-mix-up-mitigation-01 =
will stop this attack.

White listing AS seems tempting, but is just sweeping the problem =
partially under the rug. =20
There are probably good policy reasons to whitelist AS but we =
shouldn=E2=80=99t let this AS mixup be one of them.

John B.

> On Jan 27, 2016, at 10:42 PM, Nat Sakimura  wrote:
>=20
> I see. That's like double cut-n-paste.=20
>=20
> I tried to capture this case of used-to-be-good AS turning Compromised =
AS (Log leaking AS) in a sequence diagram: http://j.mp/1QtDeKD =

>=20
> Given this, just relying on not using random AS is not good enough. =
You would probably require AS w/ISMS with the policy of not logging =
un-masked credentials and has strict access control on the log ;-)=20
>=20
> Nat
>=20
> 2016=E5=B9=B41=E6=9C=8828=E6=97=A5(=E6=9C=A8) 9:38 Hans Zandbelt =
>:
> indeed, if the attacker is able to phish the user, he can put up a
> script that first triggers the authorization request to the =
compromised
> AS (i.e. the AS at which he has access to the logs and gathers the =
state
> value from) through the Client, and subsequently trigger the redirect =
to
> the good AS using an auto-refresh of that same phishing page (with the
> stolen state value); no need to control the authorization endpoint of
> the compromised AS itself
>=20
> Hans.
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_07ACE604-F73D-4457-ADBF-43850131EA05
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Yes,  I note either mitigation in draft-jones-oauth-mix-up-mitigation-01 will =
stop this attack.

White listing AS seems tempting, =
but is just sweeping the problem partially under the rug.  
There are =
probably good policy reasons to whitelist AS but =
we shouldn=E2=80=99t let this AS mixup be one of =
them.

John B.

On Jan 27, 2016, at 10:42 PM, Nat Sakimura <sakimura@gmail.com> =
wrote:

I see. That's like double cut-n-paste. 

I tried to capture this =
case of used-to-be-good AS turning Compromised AS (Log leaking AS) in a =
sequence diagram: http://j.mp/1QtDeKD

Given this, just relying on not using =
random AS is not good enough. You would probably require AS w/ISMS with =
the policy of not logging un-masked credentials and has strict access =
control on the log ;-) 

Nat

2016=E5=B9=B41=E6=9C=8828=E6=97=A5(=E6=9C=A8) 9:38 Hans =
Zandbelt <hzandbelt@pingidentity.com>:
indeed, if the =
attacker is able to phish the user, he can put up a

script that first triggers the authorization request to the =
compromised

AS (i.e. the AS at which he has access to the logs and gathers the =
state

value from) through the Client, and subsequently trigger the redirect =
to

the good AS using an auto-refresh of that same phishing page (with =
the

stolen state value); no need to control the authorization endpoint of

the compromised AS itself



Hans.




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

=

--Apple-Mail=_07ACE604-F73D-4457-ADBF-43850131EA05--

--Apple-Mail=_BAFC9259-7646-487D-BFEE-BB35D037AA1F
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjgxNzUzNDdaMCMGCSqGSIb3DQEJBDEWBBQW6WnBwzdMdVF9skq9eCVM
eNKyAjCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBBLrxr3lD0cs3caQ1qyGwdT7J45vKw20Y95qIYKDtiSJCGHeTBs+Pe
TSCoVuYKxTB+CiKOhelyrb9aPMHIe64UxQ3ANqpup3lBP9VhXEusGu5PNy6Rq0HwnI+lPz5eO9xs
BHmaCmrErk8TBmoakY49RQLQpO/P2LW0+5W7SU/Qr6GKNq8tdgxNseABJp6GNB/qd+WZxKOD/Hqp
bgEyzL2WBfbHQiKdJO6FuOKD3Gv00tcrIVuwKMtZKq4Y9MZI4iPGi/JjTwQM+Tf9Mxni5Lrz2mef
NX3mz/ryRb6uuO2gj94df7NgYWxX14WlaWUksAPZWgD6D8v7iJ8ffVQQBUb+AAAAAAAA
--Apple-Mail=_BAFC9259-7646-487D-BFEE-BB35D037AA1F--


From nobody Thu Jan 28 11:27:49 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A701B35B9 for ; Thu, 28 Jan 2016 11:27:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.741
X-Spam-Level: 
X-Spam-Status: No, score=-1.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRbHZZ9YmfIi for ; Thu, 28 Jan 2016 11:27:42 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0740.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::740]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720E91B35B1 for ; Thu, 28 Jan 2016 11:27:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LmZm3gbxZo8nQtHFgO2aX1xRx86bopL+GUf8bgdayv4=; b=b9jGM3yXDAI/P2v6wbG9I3I65bS5jKpZV6HC0jWvtCoSu1bbttJ+5BMkXm7MrYlgEFoexF64L0gHz3ErRHIVNmUzttoSzX9FxsVSTH15SMqOMBNhCs4y9GBpjv6dp1E8FgZZtIgSmkwSkUa55on4PsqK2KOkt4k5yq6mNIFl+B0=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB443.namprd03.prod.outlook.com (10.141.141.152) with Microsoft SMTP Server (TLS) id 15.1.365.19; Thu, 28 Jan 2016 19:27:22 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0365.024; Thu, 28 Jan 2016 19:27:22 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: OAuth Discovery metadata values added for revocation, introspection, and PKCE
Thread-Index: AdFZ+/MJivXRQw+8SrOHcZb7gBYlNw==
Date: Thu, 28 Jan 2016 19:27:22 +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: [64.134.238.4]
x-ms-office365-filtering-correlation-id: e76b98f1-1f99-4205-b52d-08d328190b9a
x-microsoft-exchange-diagnostics: 1; BY2PR03MB443; 5:JzSLF+LSBcq5PpCJfsSQMH2fQ7cP2Rgyfy5lAWfeznLnRQoxY8wJeLW4caXrvDmHTTVDM2Jt2FrKCHpJfw3sR6Mo6RgcvVpWRP7muNaAtFR09OelHA8jrWGo2pQhWsm4SYCm/2+PXiST4EIVoAiM2g==; 24:o4Flf0b2g5YnFvH34LlFstJAPZYzsb4JICCasLcVdD4E6Jh0Fg40Djh4oE7rJG4LuJpTdNDuZQAfeJFYnGdrLQfrwEptX4mPRHYJ4knaBV4=
x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; UriScan:; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB443; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB443; 
x-forefront-prvs: 083526BF8A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(199003)(105586002)(19617315012)(77096005)(106356001)(16236675004)(1730700002)(19625215002)(15975445007)(450100001)(102836003)(86362001)(6116002)(790700001)(122556002)(2906002)(74316001)(97736004)(586003)(229853001)(5008740100001)(19580395003)(2501003)(40100003)(81156007)(10290500002)(2900100001)(19300405004)(5005710100001)(33656002)(3846002)(87936001)(107886002)(10400500002)(76576001)(92566002)(101416001)(50986999)(54356999)(10090500001)(5002640100001)(189998001)(5001960100002)(99286002)(8990500004)(11100500001)(110136002)(5003600100002)(3470700001)(2351001)(3280700002)(86612001)(66066001)(1096002)(5004730100002)(1220700001)(3660700001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB443; H:BY2PR03MB442.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442C39923E8F9D96F5975B0F5DA0BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2016 19:27:22.0697 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB443
Archived-At: 
Subject: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 28 Jan 2016 19:27:47 -0000

--_000_BY2PR03MB442C39923E8F9D96F5975B0F5DA0BY2PR03MB442namprd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The OAuth Discovery specification has been updated to add metadata values f=
or revocation, introspection, and PKCE.  C=
hanges were:

*       Added "revocation_endpoint_auth_methods_supported" and "revocation_=
endpoint_auth_signing_alg_values_supported" for the revocation endpoint.

*       Added "introspection_endpoint_auth_methods_supported" and "introspe=
ction_endpoint_auth_signing_alg_values_supported" for the introspection end=
point.

*       Added "code_challenge_methods_supported" for PKCE.

The specification is available at:

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

An HTML-formatted version is also available at:

*       http://self-issued.info/docs/draft-jones-oauth-discovery-01.html

                                                          -- Mike

P.S.  This note was also published at http://self-issued.info/?p=3D1531 and=
 as @selfissued.


--_000_BY2PR03MB442C39923E8F9D96F5975B0F5DA0BY2PR03MB442namprd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











The OAuth Discovery specification has been updated t=
o add metadata values for
revocation, 
introspection, and PKCE<=
/a>.  Changes were:


·      
Added “revocation_endpoint_auth_methods_supported̶=
1; and “revocatio=
n_endpoint_auth_signing_alg_values_supported” for the revocati=
on endpoint.



·      
Added “introspection_endpoint_auth_methods_supported&#=
8221; and “intros=
pection_endpoint_auth_signing_alg_values_supported” for the in=
trospection
 endpoint. 


·      
Added “code_challenge_methods_supported” for PKC=
E.


 


The specification is available at:


·      
http://tools.ietf.org/html/draft-jo=
nes-oauth-discovery-01


 


An HTML-formatted version is also available at:=



·      
http://self-issued.info/docs=
/draft-jones-oauth-discovery-01.html


 


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


 


P.S.  This note was also published at 
http://self-issued.info/?p=3D1531 and as 
@selfissued.


 






--_000_BY2PR03MB442C39923E8F9D96F5975B0F5DA0BY2PR03MB442namprd_--


From nobody Thu Jan 28 20:54:52 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F1F1B3DB4 for ; Thu, 28 Jan 2016 20:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6pgmWH3NRrC for ; Thu, 28 Jan 2016 20:54:48 -0800 (PST)
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 D1F661B3DB3 for ; Thu, 28 Jan 2016 20:54:47 -0800 (PST)
Received: by mail-qk0-x233.google.com with SMTP id s5so20307010qkd.0 for ; Thu, 28 Jan 2016 20:54:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=C3GZyA/TrrRgcjmmJclK45ZHlToyhIpOzfzea2iOPfU=; b=CE5iCMjJOdHxA7NDEuB/VFzTOM6U2VHG3ZimAMOPJfffzvut8+ofdq8Wn7u3Ead9lr gVGXAkcv7oGKjMuXg3xGB1RUxLRTjryFrB1w18P9ROUjb+zk4l28cYnu1IYrFc/zEYyV wAT8EjZZiAnZQW+gFnruh2oIGLjpnQ1q/h1U1I6/qLrRO9ENKqHLFHkFcV/R5fFtvcPi bLWcrzXXCaBAxy2sn2FDA8MG900PTczMKRzO42sqHDiXHhjxd7kVr+j10Cy8bkuAOtgK pGdkXJdB0W9DznNRv3LtAU8j5LwXYRGLwcqlqcjf7Cej+55wuwQHYqx3jmkfskfO6cXZ m1sQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=C3GZyA/TrrRgcjmmJclK45ZHlToyhIpOzfzea2iOPfU=; b=P/gDXtz3pa5VGKJj/3hTkh408B9yTuw7dP6vrLxo5vOqBk88amBTNpB0cOcBfWbD8I aWvAI5BJENoXpPxfE1iK0kiN8AsXibsWuDdDMWaxTPN/5VnfmU/s0JTRKcvkttyy4Zxi Sba8+Nw07BzWjQkOvBbmNlzr3Ddppa/4KbXlZWFbQyz+Xw6nbK2Gudi0lxCKQ84RJ5mR v1rkZTZXwyZHYX0F0pYcTXpeArktJt1B53Wa+sR7EYwVprewv7CzGd2zdYwQmWeLdxRp BPzyeYaone6ERrtOUV4MF4oJis6k2ZcLQsp1Rm96Va55JH8ogZueFfksfIg0HeBIS/20 lnaA==
X-Gm-Message-State: AG10YOQgGEsQQypGj/HLqZCHZfSCxWQYiTqlB94CYCbNn4RsWZDJP+OmPAKJqAtF97+75FT36b414xOUB+aqOg==
X-Received: by 10.55.78.207 with SMTP id c198mr8221259qkb.34.1454043286895; Thu, 28 Jan 2016 20:54:46 -0800 (PST)
MIME-Version: 1.0
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com>  <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com> <73E18F37-C765-4F62-A690-102D0C794C52@oracle.com> <845FCC92-E0A5-413F-BA4E-53E0D4C4DBD4@gmail.com> <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com> <63914724-175F-47EA-BC48-5FB9E6C5FE87@ve7jtb.com>  <56A8BB7C.80702@aol.com> <56A8BCC3.6030903@aol.com>   <56A92F08.9050706@pingidentity.com>  <56A962FA.2010004@pingidentity.com>  <5DC2FC1D-CBBA-4FB8-9358-0D1A046D8A99@ve7jtb.com>
In-Reply-To: <5DC2FC1D-CBBA-4FB8-9358-0D1A046D8A99@ve7jtb.com>
From: Nat Sakimura 
Date: Fri, 29 Jan 2016 04:54:36 +0000
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=001a114a7c9c9aa69e052a71d5fa
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 04:54:50 -0000

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

My preferred way of dealing with mix-up has been to use separate
redirection URI but your using issuer instead is for the backward
compatibility?

Nat

2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 2:53 John Bradley :

> Yes,  I note either mitigation in draft-jones-oauth-mix-up-mitigation-01
> will stop this attack.
>
> White listing AS seems tempting, but is just sweeping the problem
> partially under the rug.
> There are probably good policy reasons to whitelist AS but
> we shouldn=E2=80=99t let this AS mixup be one of them.
>
> John B.
>
> On Jan 27, 2016, at 10:42 PM, Nat Sakimura  wrote:
>
> I see. That's like double cut-n-paste.
>
> I tried to capture this case of used-to-be-good AS turning Compromised AS
> (Log leaking AS) in a sequence diagram: http://j.mp/1QtDeKD
>
> Given this, just relying on not using random AS is not good enough. You
> would probably require AS w/ISMS with the policy of not logging un-masked
> credentials and has strict access control on the log ;-)
>
> Nat
>
> 2016=E5=B9=B41=E6=9C=8828=E6=97=A5(=E6=9C=A8) 9:38 Hans Zandbelt :
>
>> indeed, if the attacker is able to phish the user, he can put up a
>> script that first triggers the authorization request to the compromised
>> AS (i.e. the AS at which he has access to the logs and gathers the state
>> value from) through the Client, and subsequently trigger the redirect to
>> the good AS using an auto-refresh of that same phishing page (with the
>> stolen state value); no need to control the authorization endpoint of
>> the compromised AS itself
>>
>> Hans.
>>
>> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

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


My preferred way of dealing with mix-up has been to use se=
parate redirection URI but your using issuer instead is for the backward co=
mpatibility?=C2=A0

Nat

2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 2:5=
3 John Bradley <ve7jtb@ve7jtb.com>:
I see. That's like double cut-n-paste.=C2=A0

I t=
ried to capture this case of used-to-be-good AS turning Compromised AS (Log=
 leaking AS) in a sequence diagram:=C2=A0http://j.mp/1QtDeKD

Given this=
, just relying on not using random AS is not good enough. You would probabl=
y require AS w/ISMS with the policy of not logging un-masked credentials an=
d has strict access control on the log ;-)=C2=A0

N=
at

2016=E5=B9=B41=
=E6=9C=8828=E6=97=A5(=E6=9C=A8) 9:38 Hans Zandbelt <hzandbelt@pingidentity.com&=
gt;:
indeed, if the attacker is abl=
e to phish the user, he can put up a

script that first triggers the authorization request to the compromised

AS (i.e. the AS at which he has access to the logs and gathers the state
value from) through the Client, and subsequently trigger the redirect to
the good AS using an auto-refresh of that same phishing page (with the

stolen state value); no need to control the authorization endpoint of

the compromised AS itself



Hans.




_______________________________________________
OAuth mailing list
OAuth@ietf.org


--001a114a7c9c9aa69e052a71d5fa--


From nobody Thu Jan 28 20:55:37 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD0F1B3DB7 for ; Thu, 28 Jan 2016 20:55:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Level: 
X-Spam-Status: No, score=-1.739 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, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF3EAzXNvaMd for ; Thu, 28 Jan 2016 20:55:32 -0800 (PST)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831A81B324F for ; Thu, 28 Jan 2016 20:55:32 -0800 (PST)
Received: by mail-qk0-x229.google.com with SMTP id s68so20219925qkh.3 for ; Thu, 28 Jan 2016 20:55:32 -0800 (PST)
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 :content-type; bh=B58odAXez4vhd9km2BuhnQCXwuvqTNwB9/c6RHexBbY=; b=JhSoAqL+I6MuZid1MidAGrpxxRH4kJuLtcZPWj/ANP5OtHiTmSjH8qYM4suDeXjFLv EPRbBFvX3a34gGdFKxJYrUNuRKW9BnohvP5Th62AOp1lQnCrVMPNXZxxLSC8j4bvXr/b yOkpZXHdVgQiOZ3dyqpc16tUGv6C7B9pLTNkqFtbh+Q4mdQuvSNoYvLH2cCu/GAFB5Dt ToAUVNtIi8r8UFhc1FcEVl1/GoWILZbPdNwWgvP5MEvX0VdcxBCa2KZzeikxaiX0QH+k VQ//6lUe8C7V20vLkoogWbX5LxTpr5kOi6F5C0tF5bjwYddiukIs9k2oIEybQdTr1jOc Xvuw==
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:content-type; bh=B58odAXez4vhd9km2BuhnQCXwuvqTNwB9/c6RHexBbY=; b=gP/dBCyKKydhkM9iwBwNl8usCxXBvYWsfQY40lPEs0F0lVmulivpVo9clOZIaKu2nG LtNx4du0KI11tSE1rolG5WF+9Kz4XNn2MwYiWIfrpWsmv2/W631156gukMY8zZynok6o jT5xbeoXhrXksTbt/yxP3RsDD2nY42XqFHXcwVMOXtcRwEhOMKjwUcsJLcasU7jrJpnS aRKF/m6cV+UChEzmLQ9tzP/kCCQDaGKJG2y5Myx8NVhNEVkJx/tJd7RYyD75FZqL3DUu RjMcAqqd07EOW7sThvze9Bo3CTThqgaMc0VwtHGojTUuKY44ytZneqoQyTO3DRidtlYD so6g==
X-Gm-Message-State: AG10YOR5wPRAoFCR71L70mTQjA+ucvPQayW1G0EIzSAywjRd6+ss1v7PsjEyE0jcYpLeNrzA1zvSDDPUR3t8+Q==
X-Received: by 10.55.71.66 with SMTP id u63mr8177817qka.67.1454043331713; Thu, 28 Jan 2016 20:55:31 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Nat Sakimura 
Date: Fri, 29 Jan 2016 04:55:22 +0000
Message-ID: 
To: Mike Jones , "oauth@ietf.org" 
Content-Type: multipart/alternative; boundary=001a114a797446622f052a71d8e2
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 04:55:36 -0000

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

Thanks!

2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 4:28 Mike Jones :

> The OAuth Discovery specification has been updated to add metadata values
> for revocation , introspection
> , and PKCE
> .  Changes were:
>
> =C2=B7       Added =E2=80=9Crevocation_endpoint_auth_methods_supported=E2=
=80=9D and =E2=80=9C
> revocation_endpoint_auth_signing_alg_values_supported=E2=80=9D for the re=
vocation
> endpoint.
>
> =C2=B7       Added =E2=80=9Cintrospection_endpoint_auth_methods_supported=
=E2=80=9D and =E2=80=9C
> introspection_endpoint_auth_signing_alg_values_supported=E2=80=9D for the
> introspection endpoint.
>
> =C2=B7       Added =E2=80=9Ccode_challenge_methods_supported=E2=80=9D for=
 PKCE.
>
>
>
> The specification is available at:
>
> =C2=B7       http://tools.ietf.org/html/draft-jones-oauth-discovery-01
>
>
>
> An HTML-formatted version is also available at:
>
> =C2=B7       http://self-issued.info/docs/draft-jones-oauth-discovery-01.=
html
>
>
>
>                                                           -- Mike
>
>
>
> P.S.  This note was also published at http://self-issued.info/?p=3D1531 a=
nd
> as @selfissued .
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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


Thanks!

2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 4:28 Mike Jones <Michael.Jones@microsoft.com>=
;:











The OAuth Discovery specification has been updated t=
o add metadata values for
revocation=
, 
introspection, and PKCE.=C2=A0 Changes were:


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Added =E2=80=9Crevocation_endpoint_auth_methods_supported=E2=80=
=9D and =E2=80=9Crevoca=
tion_endpoint_auth_signing_alg_values_supported=E2=80=9D for the rev=
ocation endpoint.



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Added =E2=80=9Cintrospection_endpoint_auth_methods_supported=E2=
=80=9D and =E2=80=9Cint=
rospection_endpoint_auth_signing_alg_values_supported=E2=80=9D for t=
he introspection
 endpoint. 


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Added =E2=80=9Ccode_challenge_methods_supported=E2=80=9D for PK=
CE.


=C2=A0


The specification is available at:


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
http://tools.ietf.or=
g/html/draft-jones-oauth-discovery-01


=C2=A0


An HTML-formatted version is also available at:


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
http://self-i=
ssued.info/docs/draft-jones-oauth-discovery-01.html


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<=
u>


=C2=A0


P.S.=C2=A0 This note was also published at 
http://self-issued.info/?p=3D1531 and as 
@selfissued.


=C2=A0






_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--001a114a797446622f052a71d8e2--


From nobody Thu Jan 28 21:15:02 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61011B3DD8 for ; Thu, 28 Jan 2016 21:14:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jQ3Vh4fi-pK for ; Thu, 28 Jan 2016 21:14:55 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01541B3DD6 for ; Thu, 28 Jan 2016 21:14:55 -0800 (PST)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u0T5Esnb001369 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jan 2016 05:14:54 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u0T5ErES017158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 29 Jan 2016 05:14:53 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u0T5EqQH024841; Fri, 29 Jan 2016 05:14:53 GMT
Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 28 Jan 2016 21:14:52 -0800
Content-Type: multipart/alternative; boundary=Apple-Mail-BC5FE6DD-80C0-4C8F-B28B-C7D27430C922
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" 
X-Mailer: iPhone Mail (13D15)
In-Reply-To: 
Date: Thu, 28 Jan 2016 21:14:50 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <7FC3FCB3-2FFA-4629-A59F-755BAFEA73FA@oracle.com>
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com>  <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com> <73E18F37-C765-4F62-A690-102D0C794C52@oracle.com> <845FCC92-E0A5-413F-BA4E-53E0D4C4DBD4@gmail.com> <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com> <63914724-175F-47EA-BC48-5FB9E6C5FE87@ve7jtb.com>  <56A8BB7C.80702@aol.com> <56A8BCC3.6030903@aol.com>   <56A92F08.9050706@pingidentity.com>  <56A962FA.2010004@pingidentity.com>  <5DC2FC1D-CBBA-4FB8-9358-0D1A046D! 8A99@ve7jtb.com> 
To: Nat Sakimura 
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 05:14:59 -0000

--Apple-Mail-BC5FE6DD-80C0-4C8F-B28B-C7D27430C922
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

We discussed that redirecr helps but we wanted the Token endpoint to also be=
 able to detect assuming many client devs won't implement the check.=20

Phil

> On Jan 28, 2016, at 20:54, Nat Sakimura  wrote:
>=20
> My preferred way of dealing with mix-up has been to use separate redirecti=
on URI but your using issuer instead is for the backward compatibility?=20
>=20
> Nat
>=20
> 2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 2:53 John Bradley :
>> Yes,  I note either mitigation in draft-jones-oauth-mix-up-mitigation-01 w=
ill stop this attack.
>>=20
>> White listing AS seems tempting, but is just sweeping the problem partial=
ly under the rug. =20
>> There are probably good policy reasons to whitelist AS but we shouldn=E2=80=
=99t let this AS mixup be one of them.
>>=20
>> John B.
>>=20
>>=20
>>> On Jan 27, 2016, at 10:42 PM, Nat Sakimura  wrote:
>>>=20
>>=20
>>> I see. That's like double cut-n-paste.=20
>>>=20
>>> I tried to capture this case of used-to-be-good AS turning Compromised A=
S (Log leaking AS) in a sequence diagram: http://j.mp/1QtDeKD
>>>=20
>>> Given this, just relying on not using random AS is not good enough. You w=
ould probably require AS w/ISMS with the policy of not logging un-masked cre=
dentials and has strict access control on the log ;-)=20
>>>=20
>>> Nat
>>>=20
>>> 2016=E5=B9=B41=E6=9C=8828=E6=97=A5(=E6=9C=A8) 9:38 Hans Zandbelt :
>>>> indeed, if the attacker is able to phish the user, he can put up a
>>>> script that first triggers the authorization request to the compromised=

>>>> AS (i.e. the AS at which he has access to the logs and gathers the stat=
e
>>>> value from) through the Client, and subsequently trigger the redirect t=
o
>>>> the good AS using an auto-refresh of that same phishing page (with the
>>>> stolen state value); no need to control the authorization endpoint of
>>>> the compromised AS itself
>>>>=20
>>>> Hans.
>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>=20
>>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-BC5FE6DD-80C0-4C8F-B28B-C7D27430C922
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


We discussed that redirecr helps but w=
e wanted the Token endpoint to also be able to detect assuming many client d=
evs won't implement the check. 

Phil

On Jan 28, 20=
16, at 20:54, Nat Sakimura <sakimur=
a@gmail.com> wrote:


_______________________________________________
OAuth mailing list
OAuth@ietf.org
=



=

--Apple-Mail-BC5FE6DD-80C0-4C8F-B28B-C7D27430C922--


From nobody Thu Jan 28 22:11:50 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE651B3E8D for ; Thu, 28 Jan 2016 22:11:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi07HCszkcff for ; Thu, 28 Jan 2016 22:11:46 -0800 (PST)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 AB5FD1B3E8B for ; Thu, 28 Jan 2016 22:11:45 -0800 (PST)
Received: by mail-qg0-x22f.google.com with SMTP id 6so58174899qgy.1 for ; Thu, 28 Jan 2016 22:11:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=0kIA39+8e2sXOmze1QSCY1Ss8jJkW/IkRqag9Dz9yiU=; b=xJl/SM+gLHiE7hTAqHKm9GCtZsUT8ocvgvyVzBn6clPx8TQ37P2Xro4UyYzbR+BhUE hFYJJ7ysSKKLX0whQsPVaSAmmwY6wTORc6gzyoKVt7EBpX0u3XRBBWVn3xDiuEKz5eK4 M74GtaIAdYoxKLJk13n/x589UCmMxFODvOiHFC5jXKnsA6wuePGhpr7vNlth12WvTp6A Kv54nmE5Rargvr5Hpoftcr7EqdQPZ2q/LJXbHmqJ1oqWnQW9JHfwEzzpAf/MPyy7SIXN 30pE27C0V7SIdvqSB4sHSmvpZPdW6duSX/zWzOsj6yUqB16N8bvGwYA38yIEbjyVfvn7 zLtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=0kIA39+8e2sXOmze1QSCY1Ss8jJkW/IkRqag9Dz9yiU=; b=UaxyWnu2i+EOgkGw3wPbz03n/yt3rGFirdU8q5DSZu376tvFR6QgKb7Oeq3KrY3EgX MO5QnIxjeRuZLLPk2v+T7x+/FbWJcZV1ukFkGPVKFox2XTNnG+13UXCLpydD1lKvo/r3 x1bD0S3Mmip2OqfCDo+cBNAa1ViK2lwzg6KnlkKVuc9oUF7d5KZBWAftfpsuatcsGKJ2 dZw2FZfjWWLP2EDY8jLGi7XK2r3H10svCt5La8+iKOZG6WFqVsBdSVgp9j9t+tkEp4EM q/WqIsdRRDQ13ufgccCV+YFqNbRkoK76aNDHrNRvQKZ4itYSY4Csb4Q/MSlShzDkkA6b H+Ag==
X-Gm-Message-State: AG10YOQmT1wvrDyj5JlJY9cmf5PL07T6kHVQbmQEPiWinAvfbZsX1vsOZp6RzYLfAtgoxymFx8mwe0GFbx/aBA==
X-Received: by 10.140.101.201 with SMTP id u67mr8574859qge.33.1454047904777; Thu, 28 Jan 2016 22:11:44 -0800 (PST)
MIME-Version: 1.0
References: <809D2C8D-F76B-42AD-93D1-E6AF487487AA@oracle.com> <362D654D-BC33-45AE-9F64-0A131A9EBC5E@oracle.com> <7BA5A647-5BBB-4C5E-95C7-0D6F295F96A6@gmail.com> <87971FDB-B51A-48B6-8311-6E55322960FC@oracle.com>  <222CF07B-5AA7-4789-8AC8-7C32377C5AE6@oracle.com> <73E18F37-C765-4F62-A690-102D0C794C52@oracle.com> <845FCC92-E0A5-413F-BA4E-53E0D4C4DBD4@gmail.com> <0178F662-732A-42AA-BE42-E7ECBDEE3353@oracle.com> <63914724-175F-47EA-BC48-5FB9E6C5FE87@ve7jtb.com>  <56A8BB7C.80702@aol.com> <56A8BCC3.6030903@aol.com>   <56A92F08.9050706@pingidentity.com>  <56A962FA.2010004@pingidentity.com>   <7FC3FCB3-2FFA-4629-A59F-755BAFEA73FA@oracle.com>
In-Reply-To: <7FC3FCB3-2FFA-4629-A59F-755BAFEA73FA@oracle.com>
From: Nat Sakimura 
Date: Fri, 29 Jan 2016 06:11:33 +0000
Message-ID: 
To: "Phil Hunt (IDM)" 
Content-Type: multipart/alternative; boundary=001a11c16e6ad9e798052a72e87d
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 06:11:48 -0000

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

But that's cut-n-paste protection using "state" token endpoint parameter,
is it not?

2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 14:14 Phil Hunt (IDM) :

> We discussed that redirecr helps but we wanted the Token endpoint to also
> be able to detect assuming many client devs won't implement the check.
>
>
> Phil
>
> On Jan 28, 2016, at 20:54, Nat Sakimura  wrote:
>
> My preferred way of dealing with mix-up has been to use separate
> redirection URI but your using issuer instead is for the backward
> compatibility?
>
> Nat
>
> 2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 2:53 John Bradley :
>
>> Yes,  I note either mitigation in draft-jones-oauth-mix-up-mitigation-01
>> will stop this attack.
>>
>> White listing AS seems tempting, but is just sweeping the problem
>> partially under the rug.
>> There are probably good policy reasons to whitelist AS but
>> we shouldn=E2=80=99t let this AS mixup be one of them.
>>
>> John B.
>>
>> On Jan 27, 2016, at 10:42 PM, Nat Sakimura  wrote:
>>
>> I see. That's like double cut-n-paste.
>>
>> I tried to capture this case of used-to-be-good AS turning Compromised A=
S
>> (Log leaking AS) in a sequence diagram: http://j.mp/1QtDeKD
>>
>> Given this, just relying on not using random AS is not good enough. You
>> would probably require AS w/ISMS with the policy of not logging un-maske=
d
>> credentials and has strict access control on the log ;-)
>>
>> Nat
>>
>> 2016=E5=B9=B41=E6=9C=8828=E6=97=A5(=E6=9C=A8) 9:38 Hans Zandbelt :
>>
>>> indeed, if the attacker is able to phish the user, he can put up a
>>> script that first triggers the authorization request to the compromised
>>> AS (i.e. the AS at which he has access to the logs and gathers the stat=
e
>>> value from) through the Client, and subsequently trigger the redirect t=
o
>>> the good AS using an auto-refresh of that same phishing page (with the
>>> stolen state value); no need to control the authorization endpoint of
>>> the compromised AS itself
>>>
>>> Hans.
>>>
>>> _______________________________________________
>> 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
>
>

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


But that's cut-n-paste protection using "state&qu=
ot; token endpoint parameter, is it not?=C2=A0

My preferred way of dealing with mix-up has been to use separate r=
edirection URI but your using issuer instead is for the backward compatibili=
ty? 

Nat

<=
div dir=3D"ltr">2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 2:53 John Brad=
ley <ve7jtb@ve7jtb.com>:
<=
/div>
Yes, &=
nbsp;I note either mitigation in draft-jones-oauth-mix-up-mitiga=
tion-01 will stop this attack.

White listing AS seems tempting, but is just sweeping the problem partially under the rug.  
There are=
 probably good policy reasons to whitelist AS but we shouldn=E2=80=99t&=
nbsp;let this AS mixup be one of them.

=
John B.

O=
n Jan 27, 2016, at 10:42 PM, Nat Sakimura <sakimura@gmail.com> wrote:

I see. That's like double cut-n-pa=
ste. 

I tried to capture this case of used-to-be-goo=
d AS turning Compromised AS (Log leaking AS) in a sequence diagram: http://j.mp/1QtDeKD
<=
div>
Given this, just relying on not using random AS is not go=
od enough. You would probably require AS w/ISMS with the policy of not loggi=
ng un-masked credentials and has strict access control on the log ;-) <=
/div>

Nat

2016=E5=B9=B41=E6=9C=8828=E6=97=A5(=E6=9C=A8) 9:38 Hans Zandbelt &=
lt;hzandbelt=
@pingidentity.com>:
indeed, if t=
he attacker is able to phish the user, he can put up a

script that first triggers the authorization request to the compromised

AS (i.e. the AS at which he has access to the logs and gathers the state
=

value from) through the Client, and subsequently trigger the redirect to
=

the good AS using an auto-refresh of that same phishing page (with the

stolen state value); no need to control the authorization endpoint of

the compromised AS itself



Hans.



2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 14:1=
4 Phil Hunt (IDM) <phil.hunt@ora=
cle.com>:
=

We discussed that redirecr helps but we wanted the Token endpoint to a=
lso be able to detect assuming many client devs won't implement the che=
ck.=C2=A0


Phil

On Jan 28, 2016, at 20:54, Nat Sakimura <sakimura@gmail.com> wro=
te:

My preferr=
ed way of dealing with mix-up has been to use separate redirection URI but =
your using issuer instead is for the backward compatibility?=C2=A0

=

Nat

2=
016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 2:53 John Bradley <ve7jtb@ve7jtb.com>:<=
br>
Yes, =C2=A0I note either mitigation in=C2=A0draft-jones-oauth-mix-=
up-mitigation-01 will stop this attack.

White listing AS seems tempting, but is just sweeping the pr=
oblem=C2=A0partially=C2=A0under the rug. =C2=A0
There are probably good policy reasons to whitelist AS but we=C2=A0s=
houldn=E2=80=99t=C2=A0let this AS mixup be one of them.
=


John B.

On Jan 27, 2016, at 10:42 PM, Nat Sakimura <<=
a href=3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com> wrote:

I =
see. That's like double cut-n-paste.=C2=A0

I tried t=
o capture this case of used-to-be-good AS turning Compromised AS (Log leaki=
ng AS) in a sequence diagram:=C2=A0http://j.mp/1QtDeKD

Given this, ju=
st relying on not using random AS is not good enough. You would probably re=
quire AS w/ISMS with the policy of not logging un-masked credentials and ha=
s strict access control on the log ;-)=C2=A0

Nat

2016=E5=B9=B41=E6=
=9C=8828=E6=97=A5(=E6=9C=A8) 9:38 Hans Zandbelt <hzandbelt@pingidentity.com>=
:
indeed, if the attacker is able t=
o phish the user, he can put up a

script that first triggers the authorization request to the compromised

AS (i.e. the AS at which he has access to the logs and gathers the state
value from) through the Client, and subsequently trigger the redirect to
the good AS using an auto-refresh of that same phishing page (with the

stolen state value); no need to control the authorization endpoint of

the compromised AS itself



Hans.




_______________________________________________
OAuth mailing list
OAuth@ietf.org


___________________=
____________________________
OAuth mailing list
<=
span>OAuth@ietf.org=

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


--001a11c16e6ad9e798052a72e87d--


From nobody Fri Jan 29 04:23:43 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851691A8733 for ; Fri, 29 Jan 2016 04:23:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTJzJ_FicHKQ for ; Fri, 29 Jan 2016 04:23:40 -0800 (PST)
Received: from p3plsmtpa06-10.prod.phx3.secureserver.net (p3plsmtpa06-10.prod.phx3.secureserver.net [173.201.192.111]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD29D1A870A for ; Fri, 29 Jan 2016 04:23:40 -0800 (PST)
Received: from [192.168.0.10] ([82.11.82.125]) by p3plsmtpa06-10.prod.phx3.secureserver.net with  id BoPe1s0082iDvnW01oPfVc; Fri, 29 Jan 2016 05:23:40 -0700
To: oauth@ietf.org
References: 
From: Vladimir Dzhuvinov 
X-Enigmail-Draft-Status: N1110
Organization: Connect2id Ltd.
Message-ID: <56AB59CA.5070408@connect2id.com>
Date: Fri, 29 Jan 2016 12:23:38 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060403080701070905050107"
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 12:23:42 -0000

This is a cryptographically signed message in MIME format.

--------------ms060403080701070905050107
Content-Type: multipart/alternative;
 boundary="------------010709080401000600080309"

This is a multi-part message in MIME format.
--------------010709080401000600080309
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Thanks Mike, the updated spec looks good!

I have a question related to PKCE:

The PKCE spec seems to imply that an AS may require public clients to
use a code challenge:

https://tools.ietf.org/html/rfc7636#section-4.4.1

If an AS has such a policy in place, how is this to be advertised? Or is
that supposed to the enforced when the client gets registered (there are
no reg params for that at present)?


On 28/01/16 19:27, Mike Jones wrote:
> The OAuth Discovery specification has been updated to add metadata valu=
es for revocation, introspection, and PKCE.  Changes were:
>
> *       Added "revocation_endpoint_auth_methods_supported" and "revocat=
ion_endpoint_auth_signing_alg_values_supported" for the revocation endpoi=
nt.
>
> *       Added "introspection_endpoint_auth_methods_supported" and "intr=
ospection_endpoint_auth_signing_alg_values_supported" for the introspecti=
on endpoint.
>
> *       Added "code_challenge_methods_supported" for PKCE.
>
> The specification is available at:
>
> *       http://tools.ietf.org/html/draft-jones-oauth-discovery-01
>
> An HTML-formatted version is also available at:
>
> *       http://self-issued.info/docs/draft-jones-oauth-discovery-01.htm=
l
>
>                                                           -- Mike
>
> P.S.  This note was also published at http://self-issued.info/?p=3D1531=
 and as @selfissued.
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--=20
Vladimir Dzhuvinov


--------------010709080401000600080309
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    Thanks Mike, the updated spec looks good!

    

    I have a question related to PKCE:

    

    The PKCE spec seems to imply that an AS may require public clients
    to use a code challenge:

    

    https://tools.ietf.org/html/rfc7636#section-4.4.=
1

    

    If an AS has such a policy in place, how is this to be advertised?
    Or is that supposed to the enforced when the client gets registered
    (there are no reg params for that at present)?

    

    

    
On 28/01/16 19:27, Mike Jones wrote:
    

    

      
The OAuth Discovery specification has been updated t=
o add metadata values for revocation<http://tools.ietf.org/html/=
rfc7009>, introspection<http://tools.ietf.org/html/rfc766=
2>, and PKCE<http://tools.ietf.org/html/rfc7636>. =
 Changes were:

*       Added "revocation_endpoint_auth_methods_supported" and "revocatio=
n_endpoint_auth_signing_alg_values_supported" for the revocation endpoint=
=2E

*       Added "introspection_endpoint_auth_methods_supported" and "intros=
pection_endpoint_auth_signing_alg_values_supported" for the introspection=
 endpoint.

*       Added "code_challenge_methods_supported" for PKCE.

The specification is available at:

*       http://tools.ietf.org/html/draft-jon=
es-oauth-discovery-01

An HTML-formatted version is also available at:

*       http://self-issued.info/docs/=
draft-jones-oauth-discovery-01.html

                                                          -- Mike

P.S.  This note was also published at http://self-issued.info/?p=3D1=
531 and as @selfissued<https://twitter.com/selfissued>.




      

      

      

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


    

    

    
--=20
Vladimir Dzhuvinov

  


--------------010709080401000600080309--

--------------ms060403080701070905050107
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+5swggVFMIIELaADAgECAhAJWTI81U+XNs3vMVNsyOgrMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwMzEyMDAwMDAwWhcNMTYwMzExMjM1OTU5WjAoMSYwJAYJKoZIhvcNAQkB
Fhd2bGFkaW1pckBjb25uZWN0MmlkLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAKOyFE/JGyJPkJxnDLNMCit/gIMcHHimJ4QTbV7YNMReIh7/ccO9FQNwmmF4GCq347yB
/eYy+9FXLh21Zp61RO3fSnCnEVmwNL5TwCF63iCSDLDEtXnx7AznLTV6MlheEljNtA7Cegos
IM/XWE5NrzuO2vmHnj7C59uoGv4FTmcgVCDBJQ23Sdsju0zyNuAETqDyDw6yVwAfRlq+klRg
G/ZZFn1D1iDRHyehgkwIoqc1cDbMPEcgkrS3ulWZhh8fGz/EQNo0JzUlwWe25DGpcSRrf47W
yMHrVcP5HEQWFxEfGwQmZuNdYb/fzhnYThqGP0AjY2VMicAyOdttbbhutCsCAwEAAaOCAfUw
ggHxMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTiAjTIj8gY
Zm3ThRvtNvKtyZoWRjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX
BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0w
OwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5u
ZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9E
T1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsG
AQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01P
RE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsG
AQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wIgYDVR0RBBswGYEXdmxhZGltaXJA
Y29ubmVjdDJpZC5jb20wDQYJKoZIhvcNAQELBQADggEBAC2rpYhJKODFdxGV5tBkuFuqW5/6
cnQ30GrREyk8/cLCWKhyvrMsnPnpK1ItafcQr4QPbR1hQcw0w7wzWBAl7FMjhpEVZIv286hM
j+BStZPW4LTRiAHPo0Z7oEGvXPGuUuG2e6k0vAV65x7XN4S/wBYKQYg6hRatjK9Lhrlqr9K+
+Rg48LvWFdNbZ5F6VlQSHVBjX7bgQ86uUz0hRawCicJuTxE3J5fVWdfy2MULS5joW6js7V1J
Hy86a/qyMZwqscXKPdv1W+UKAePtdGqKJbsZ6TFniBweSqa2pw7traBZ/ko65W2LEPi4tAhS
KA7LaumILDPe82VqFHkHX4zuYC8xggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMCR0IxGzAZ
BgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo
ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAJWTI81U+XNs3vMVNsyOgrMA0GCWCG
SAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0xNjAxMjkxMjIzMzhaMC8GCSqGSIb3DQEJBDEiBCAvDMJ1LBg5GbE5q/LUJd3kAkuci8Ry
ruM+7Dra53nljTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G
CCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzCBwwYLKoZI
hvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNo
ZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEw
PwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy
ZSBFbWFpbCBDQQIQCVkyPNVPlzbN7zFTbMjoKzANBgkqhkiG9w0BAQEFAASCAQAgaclyorNW
j0I4rJMwGPR1j5jj3gD14iAnj8sZwv6rWGAu90WI2q6TCH/xqwwDS09jgNpwfPd/OLU2fUXs
Ys7AQqKe1LysctCmdHmjvllUTxaGI3patBJw0lSKyfv833wWGG/MAhVynKbdTwO3a+1bwrS4
ok0Klhgw+6+JBQQbTceKMjOHQ7XcKlzLYmxlDTHQAp27PZ7fOkG1Ta2g1Y6AqUEYrbXt+ExL
D41WXc7SCpkCoCFPw7x/ULheg1AS+R0WGhb6ogSLz3WWcDdcRT1/iYk6P3z/H5KJ1ELXdGjM
SEPi0+o5EsVODsRA/DZPXcvwaksAvtdbefPAxrGMvquRAAAAAAAA
--------------ms060403080701070905050107--


From nobody Fri Jan 29 05:16:07 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B747D1ACC7F for ; Fri, 29 Jan 2016 05:16:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6EgV4UcFCdb for ; Fri, 29 Jan 2016 05:15:58 -0800 (PST)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 71DCF1ACC72 for ; Fri, 29 Jan 2016 05:15:58 -0800 (PST)
Received: by mail-qg0-x22d.google.com with SMTP id o11so64522746qge.2 for ; Fri, 29 Jan 2016 05:15:58 -0800 (PST)
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 :content-type; bh=wDq/gdGwdgXHjmtpEu6TV5YN6U6M1NTtcTiBetGXNOs=; b=xh3XD/dAZaVAdWxRtGRrSSFCpEQRSOY347i6fydqyZPWH77kf6H0pzFHtrmsOYtuSm B82enQ/3pC0SWMX4kicLY5E1wplyskXMZw5jlWwdHJIjTqCWJa5LPcwnboXnFLI+DqHn Bq5QzOKqOWpKh0d7+iwUtcVI6KmtfBNaqjyYzkpkfAv3IxHVvIvPZbq1131Y/1DThDZN qFeL6wV023qgYsMkzCjN47fPsOLQZO223PPH7HDZH+w2Q12tyStFnWV0DtT8+6nCK5xR bGWUxkBTJ3c/Zx39mxR92t0EFQwYdjzzxZiT5bhrEnGnmAsHDLWAAiaa4sTkGZ0eG92j m/Mg==
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:content-type; bh=wDq/gdGwdgXHjmtpEu6TV5YN6U6M1NTtcTiBetGXNOs=; b=chK9HRzPmktTncKyEHL6WN7CszybqFbda9y5GKGjvBnGjp+ZzlaLfKQGwuIhsxlWkm pgYkJxvnU4tUvLXu1oiauTAo/hNI4PyhTMAHAWv1W+bwjfFHNCZwxmoEDVjyDPTH+TCs /78VIWYVkqB1jkGDO2Nkjk4j918lL9b3nK46/EPqHe/4TTLMffdmRAtVzu3FmBuLhVv7 bULu+LIJhwOeb77MIM407b8o9lOGCMnJAPpjOsBVIGVahXMoDSlRbDED3STvcCwCC/9Y /i86y4/aDKe9IyUbSj7RI/wKmEjnNGr9yczWfTJU+FihPimc/cQ2LiwfbBhRxmXHhT/r mKhA==
X-Gm-Message-State: AG10YOTHwsvlZPWvrLZe6uPeNiLtAKe7UmPFKg8xuG2f/iEQSeNvvDNyJyZKnRPD8UIZlAv788Gpzk2+mu6sTw==
X-Received: by 10.140.250.138 with SMTP id v132mr11143490qhc.0.1454073357646;  Fri, 29 Jan 2016 05:15:57 -0800 (PST)
MIME-Version: 1.0
References:  <56AB59CA.5070408@connect2id.com>
In-Reply-To: <56AB59CA.5070408@connect2id.com>
From: Nat Sakimura 
Date: Fri, 29 Jan 2016 13:15:47 +0000
Message-ID: 
To: Vladimir Dzhuvinov , oauth@ietf.org
Content-Type: multipart/alternative; boundary=001a113a99d0f5c44f052a78d52c
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 13:16:01 -0000

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

Good question.

It's probably a good idea to be able to advertise this policy in the
discovery.

Perhaps in the line of

pkce_required or rfc7636_required?
The value should be Boolean.

Nat from iPhone


2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 21:23 Vladimir Dzhuvinov :

> Thanks Mike, the updated spec looks good!
>
> I have a question related to PKCE:
>
> The PKCE spec seems to imply that an AS may require public clients to use
> a code challenge:
>
> https://tools.ietf.org/html/rfc7636#section-4.4.1
>
> If an AS has such a policy in place, how is this to be advertised? Or is
> that supposed to the enforced when the client gets registered (there are =
no
> reg params for that at present)?
>
>
> On 28/01/16 19:27, Mike Jones wrote:
>
> The OAuth Discovery specification has been updated to add metadata values=
 for revocation , introspection , and PKCE .  Changes were:
>
> *       Added "revocation_endpoint_auth_methods_supported" and "revocatio=
n_endpoint_auth_signing_alg_values_supported" for the revocation endpoint.
>
> *       Added "introspection_endpoint_auth_methods_supported" and "intros=
pection_endpoint_auth_signing_alg_values_supported" for the introspection e=
ndpoint.
>
> *       Added "code_challenge_methods_supported" for PKCE.
>
> The specification is available at:
>
> *       http://tools.ietf.org/html/draft-jones-oauth-discovery-01
>
> An HTML-formatted version is also available at:
>
> *       http://self-issued.info/docs/draft-jones-oauth-discovery-01.html
>
>                                                           -- Mike
>
> P.S.  This note was also published at http://self-issued.info/?p=3D1531 a=
nd 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
>

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

Good question. 

It's probably a good idea to be able to advertis=
e this policy in the discovery. 

Perhaps in the line of 

pkce=
_required or rfc7636_required? 
The value should be Boolean. 

Nat=
 from iPhone


2016=E5=
=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 21:23 Vladimir Dzhuvinov <vladimir@connect2id.com>:

 =20
   =20
 =20
  

    Thanks Mike, the updated spec looks good!

    

    I have a question related to PKCE:

    

    The PKCE spec seems to imply that an AS may require public clients
    to use a code challenge:

    

    https://tools.ietf.org/html/rfc7636#section-4.4.1

    

    If an AS has such a policy in place, how is this to be advertised?
    Or is that supposed to the enforced when the client gets registered
    (there are no reg params for that at present)?

    

    

    
On 28/01/16 19:27, Mike Jones wrote:

    

    

      
The OAuth Discovery specification has been updated to add metada=
ta values for revocation<http://tools.ietf.org/html/rfc7009>, introspection=
<http:/=
/tools.ietf.org/html/rfc7662>, and PKCE<http://tools.ietf.org/html/rfc7636&=
gt;.  Changes were:

*       Added "revocation_endpoint_auth_methods_supported" and &q=
uot;revocation_endpoint_auth_signing_alg_values_supported" for the rev=
ocation endpoint.

*       Added "introspection_endpoint_auth_methods_supported" and=
 "introspection_endpoint_auth_signing_alg_values_supported" for t=
he introspection endpoint.

*       Added "code_challenge_methods_supported" for PKCE.

The specification is available at:

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

An HTML-formatted version is also available at:

*       http://self-issued.info/docs/draft-jones-oauth-=
discovery-01.html

                                                          -- Mike

P.S.  This note was also published at http://self-issued.info/?p=3D1531 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

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




--001a113a99d0f5c44f052a78d52c--


From nobody Fri Jan 29 06:11:27 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88DC81ACDF1 for ; Fri, 29 Jan 2016 06:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYKhZ8Vcs-ax for ; Fri, 29 Jan 2016 06:11:23 -0800 (PST)
Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 D97A61ACDEE for ; Fri, 29 Jan 2016 06:11:21 -0800 (PST)
Received: by mail-qg0-x235.google.com with SMTP id o11so65770305qge.2 for ; Fri, 29 Jan 2016 06:11:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=aRVPRwGOSxVaF9AlMslTYF4Uu/sGNumNl3CbxFRyUl4=; b=S05dqDr2Y00fx7u/jUySNfV2cYTfSI4er7aNVVwNaBvsMOm1JEXlyrGidpQq3ACjaC Fjy1qW8op6YGoXe0NuwBQbg/tGGxVBxHnCs1zS26PVZSVqryEDBD/ubeLWZUImFd0Tup yvNtBPXfCIVeaMsz871qK0TUmZPGVlyWjjPaTDlWovYnIZ/Q8JHuhsJByngXiOpz9iG9 8RnIxTbrqwJqfIibVPw6SskvQp09EmYfva677rD1L/YlQmbVHcBs5x2jb7CSANah69B6 +g0WBzVAsqcvrvSesfEDQUHBR0oCrBdIUkfn6p5NQjxRcNI9u3hdMdK7qyao42bn+t4M GEzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=aRVPRwGOSxVaF9AlMslTYF4Uu/sGNumNl3CbxFRyUl4=; b=B9Vbv3hUa9mDeNpB8RIU/mv5D6c7D2jgkzD22xOz5+oPZ09ALVNOvb/et9A8flno2d 5CEhXcquxi6UOrUUL5u96iF9U4oNiutPgT7/cOUauJt0L3aL0r/iT5gWj7HYdXgAz68K jqLdLWLWS7YCniXOv4sD7Ck9jq/Y54noiW4TAQCdaPjij7B1TRcpmc81EMIJJ92Mw0JO pqTVa77ZzRyqkipKLqV0N9l5pWYnBayJP/R9lzx6nCnNBqGQDaE8jjK8Gg+5KmJ6vYPl LuxZmCWE/kd0SEqW+cj50WHD3W0o+fbWt1jfPL8uVZb990xdxr6Yk+anKrH0KU2WrLrs FFSA==
X-Gm-Message-State: AG10YOSm3p49mPVQ8cG4SP74WQJiq0gUk1mfla1jHN5qWloR6U0MI8bPLOPVMlBLWlT1Rw==
X-Received: by 10.140.157.206 with SMTP id d197mr11658847qhd.3.1454076680791;  Fri, 29 Jan 2016 06:11:20 -0800 (PST)
Received: from [192.168.8.100] ([181.202.241.211]) by smtp.gmail.com with ESMTPSA id j23sm6996421qge.23.2016.01.29.06.11.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 29 Jan 2016 06:11:19 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_8280D163-46A7-4687-9847-02CC6450DDAE"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: John Bradley 
In-Reply-To: 
Date: Fri, 29 Jan 2016 11:11:16 -0300
Message-Id: <5CDF5150-89C7-4EC7-92C8-EE356C30993F@ve7jtb.com>
References:  <56AB59CA.5070408@connect2id.com> 
To: Nat Sakimura 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 14:11:25 -0000

--Apple-Mail=_8280D163-46A7-4687-9847-02CC6450DDAE
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_25364521-61E7-4745-9F00-C76B7C6E5CE6"


--Apple-Mail=_25364521-61E7-4745-9F00-C76B7C6E5CE6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The only problem with that is the client may only require it for some =
types of clients (public) or response types.

It may need to be finer grained than that, or define it as required for =
all public clients using the token endpoint.

John B.


> On Jan 29, 2016, at 10:15 AM, Nat Sakimura  wrote:
>=20
> Good question.=20
>=20
> It's probably a good idea to be able to advertise this policy in the =
discovery.=20
>=20
> Perhaps in the line of=20
>=20
> pkce_required or rfc7636_required?=20
> The value should be Boolean.=20
>=20
> Nat from iPhone
>=20
>=20
> 2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) 21:23 Vladimir Dzhuvinov =
>:
> Thanks Mike, the updated spec looks good!
>=20
> I have a question related to PKCE:
>=20
> The PKCE spec seems to imply that an AS may require public clients to =
use a code challenge:
>=20
> https://tools.ietf.org/html/rfc7636#section-4.4.1 =

>=20
> If an AS has such a policy in place, how is this to be advertised? Or =
is that supposed to the enforced when the client gets registered (there =
are no reg params for that at present)?
>=20
>=20
> On 28/01/16 19:27, Mike Jones wrote:
>> The OAuth Discovery specification has been updated to add metadata =
values for revocation =
, =
introspection =
, and =
PKCE =
.  Changes were:
>>=20
>> *       Added "revocation_endpoint_auth_methods_supported" and =
"revocation_endpoint_auth_signing_alg_values_supported" for the =
revocation endpoint.
>>=20
>> *       Added "introspection_endpoint_auth_methods_supported" and =
"introspection_endpoint_auth_signing_alg_values_supported" for the =
introspection endpoint.
>>=20
>> *       Added "code_challenge_methods_supported" for PKCE.
>>=20
>> The specification is available at:
>>=20
>> *       http://tools.ietf.org/html/draft-jones-oauth-discovery-01 =

>>=20
>> An HTML-formatted version is also available at:
>>=20
>> *       =
http://self-issued.info/docs/draft-jones-oauth-discovery-01.html =

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

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


--Apple-Mail=_25364521-61E7-4745-9F00-C76B7C6E5CE6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

The only problem with that is the client may only require it =
for some types of clients (public) or response types.

It may need to be finer grained than =
that, or define it as required for all public clients using the token =
endpoint.

John =
B.


On =
Jan 29, 2016, at 10:15 AM, Nat Sakimura <sakimura@gmail.com> =
wrote:

Good =
question. 

It's probably a good idea to be =
able to advertise this policy in the discovery. 

Perhaps in the line of 

pkce_required or rfc7636_required? 
The value =
should be Boolean. 

Nat from iPhone


2016=E5=B9=B41=E6=9C=8829=E6=97=A5(=E9=87=91) =
21:23 Vladimir Dzhuvinov <vladimir@connect2id.com>:

 =20
   =20
 =20
  

    Thanks Mike, the updated spec looks good!

    

    I have a question related to PKCE:

    

    The PKCE spec seems to imply that an AS may require public clients
    to use a code challenge:

    

    https://tools.ietf.org/html/rfc7636#section-4.4.1

    

    If an AS has such a policy in place, how is this to be advertised?
    Or is that supposed to the enforced when the client gets registered
    (there are no reg params for that at present)?

    

    

    
On 28/01/16 19:27, Mike Jones wrote:

    

    

      
The OAuth Discovery specification has been updated =
to add metadata values for revocation<http://tools.ietf.org/html/rfc7009>, =
introspection<http://tools.ietf.org/html/rfc7662>, and PKCE<http://tools.ietf.org/html/rfc7636>.  Changes =
were:

*       Added "revocation_endpoint_auth_methods_supported" and =
"revocation_endpoint_auth_signing_alg_values_supported" for the =
revocation endpoint.

*       Added "introspection_endpoint_auth_methods_supported" and =
"introspection_endpoint_auth_signing_alg_values_supported" for the =
introspection endpoint.

*       Added "code_challenge_methods_supported" for PKCE.

The specification is available at:

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

An HTML-formatted version is also available at:

*       http://self-issued.info/docs/draft-jones-oauth-discovery-01.htm=
l

                                                          -- Mike

P.S.  This note was also published at http://self-issued.info/?p=3D1531 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

=

--Apple-Mail=_25364521-61E7-4745-9F00-C76B7C6E5CE6--

--Apple-Mail=_8280D163-46A7-4687-9847-02CC6450DDAE
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNjAxMjkxNDExMTZaMCMGCSqGSIb3DQEJBDEWBBTAuTRbE1vgCHkMLIcBPscz
Bogd/TCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCCR1HATM/4WxmTkuD2jXmwvddkD48pTlcXwS9igk6cSCCn4onqWI6i
J32bD79kqntebyuy9ic0HTrCCXTD8BJNCfR/xN3umMz7yfuzfD3PoCtXen/L2Cq9pglQ5sZh+mwj
DXHKtDxSeatfdimalvz1ybny4N3/sZaWMrs1iw2a62dzc4n0FkXGd2dyulkj71n3lyUYvDItF0S/
V5pWO5Of9cNJVLujqYV8Aa1MP4gb7WQg/7ujiPRN23aK4DAjrDuQ3IjP/PaBk4D3gZThYw8pphHj
TD47ReyOdszNkO7ZdIZI8B6O5t0TaG7ogF7kDu5m0vCAKhXaldAsxhI50NMTAAAAAAAA
--Apple-Mail=_8280D163-46A7-4687-9847-02CC6450DDAE--


From nobody Fri Jan 29 09:54:48 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EFA1A89FF for ; Fri, 29 Jan 2016 09:54:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Level: 
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR82Zva0KuzH for ; Fri, 29 Jan 2016 09:54:45 -0800 (PST)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 B65BA1A89FA for ; Fri, 29 Jan 2016 09:54:45 -0800 (PST)
Received: by mail-oi0-x22f.google.com with SMTP id k206so52111351oia.1 for ; Fri, 29 Jan 2016 09:54:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SIOqwGalHrwOeUcw9sNMd1dcTQc/PDOJkNgCYkg79Do=; b=IJEAFFUBfR4pGmjc6v140Ix8FOhL1wDSCIyojsrZQer/NKTfkzKVk/4SUsgsmIoMVW ObrU0ngj4HnzXyLrGqOnIT8GXAaBKl5a3fSGdBjoz64dhiC4WL5WrZ/Y4c2ob4StStEe 2cJ7Vs62hLGJ3aciWHYcTJjE7mTgLREGVPXvuMxT1XV1+VafCF1IVtlgL3Reg3gcHvCE EVvTqH/bvCCysxkLTuyJ3OrziVTtTW4jI6OzjCq28cCL0PyZsBHdllnMS7CB2YxY3afW VXQcqLjCOi0zj5yVDgbvd0iDLpZGUyLag1s2rkzJLFaTIbHgGyey7oDCVeTkqsuBi17S IrLw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SIOqwGalHrwOeUcw9sNMd1dcTQc/PDOJkNgCYkg79Do=; b=mUzu7LcJfxJqLfp6wuokP9MBfp6QhpI0d3OfN3QmxlOE+XFcp/pHnZqiqwJsRSSnaK ABPrw9J+S5udB/0ZeQYsb8soCb8Xy2e36DG53QMVk/ERDrKR8R5AVPD8yx2gnXAmbm3o S6jqnE6ZIrZLFg2KMiwv+PZ3kWNC6517W7l6UEE/MSunq4jWVq+/fSkpvwpIjlMPTNXC qTczsh2tqV3EF5xYd0ZG1cxw4ebIIcl+MPdvdNcUvf3zQl7Mvk2vj7bIZhw60XbymPSO HPrA8OvMyY8twCrpncD8Z4MOH0j2hSB/ahCOb5q9TbIh3BJ2wSP9Uo0SM2KQDa4PEMJt u3ZQ==
X-Gm-Message-State: AG10YOSha3a9HdZvdKFCUGmjfRtWKs/yjE2lCDgIUN53uY8waYmlz25NdJvDQk4On5dhvkUzXZKIgjukWXSv2lgv
X-Received: by 10.202.105.8 with SMTP id e8mr7250980oic.34.1454090083778; Fri, 29 Jan 2016 09:54:43 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.227.39 with HTTP; Fri, 29 Jan 2016 09:54:24 -0800 (PST)
In-Reply-To: 
References: 
From: William Denniss 
Date: Fri, 29 Jan 2016 09:54:24 -0800
Message-ID: 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=001a114075e4ea8447052a7cba63
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 17:54:47 -0000

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

Thanks for the update Mike.

On Thu, Jan 28, 2016 at 11:27 AM, Mike Jones 
wrote:

> The OAuth Discovery specification has been updated to add metadata values
> for revocation , introspection
> , and PKCE
> .  Changes were:
>
> =C2=B7       Added =E2=80=9Crevocation_endpoint_auth_methods_supported=E2=
=80=9D and =E2=80=9C
> revocation_endpoint_auth_signing_alg_values_supported=E2=80=9D for the re=
vocation
> endpoint.
>
> =C2=B7       Added =E2=80=9Cintrospection_endpoint_auth_methods_supported=
=E2=80=9D and =E2=80=9C
> introspection_endpoint_auth_signing_alg_values_supported=E2=80=9D for the
> introspection endpoint.
>
> =C2=B7       Added =E2=80=9Ccode_challenge_methods_supported=E2=80=9D for=
 PKCE.
>
>
>
> The specification is available at:
>
> =C2=B7       http://tools.ietf.org/html/draft-jones-oauth-discovery-01
>
>
>
> An HTML-formatted version is also available at:
>
> =C2=B7       http://self-issued.info/docs/draft-jones-oauth-discovery-01.=
html
>
>
>
>                                                           -- Mike
>
>
>
> P.S.  This note was also published at http://self-issued.info/?p=3D1531 a=
nd
> as @selfissued .
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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


Thanks for the update Mike.

On Thu, Jan 28, 2016 at 11:27 AM, Mike Jon=
es <Michael.Jones@microsoft.com> wrote:











The OAuth Discovery specification has been updated t=
o add metadata values for
revocation=
, 
introspection, and PKCE.=C2=A0 Changes were:


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Added =E2=80=9Crevocation_endpoint_auth_methods_supported=E2=80=
=9D and =E2=80=9Crevoca=
tion_endpoint_auth_signing_alg_values_supported=E2=80=9D for the rev=
ocation endpoint.



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Added =E2=80=9Cintrospection_endpoint_auth_methods_supported=E2=
=80=9D and =E2=80=9Cint=
rospection_endpoint_auth_signing_alg_values_supported=E2=80=9D for t=
he introspection
 endpoint. 


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
Added =E2=80=9Ccode_challenge_methods_supported=E2=80=9D for PK=
CE.


=C2=A0


The specification is available at:


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
http://tools.ietf.or=
g/html/draft-jones-oauth-discovery-01


=C2=A0


An HTML-formatted version is also available at:


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0
http://self-i=
ssued.info/docs/draft-jones-oauth-discovery-01.html


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike<=
u>


=C2=A0


P.S.=C2=A0 This note was also published at 
http://self-issued.info/?p=3D1531 and as 
@selfissued.


=C2=A0







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--001a114075e4ea8447052a7cba63--


From nobody Fri Jan 29 15:22:48 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D83C1ACCF3 for ; Fri, 29 Jan 2016 15:22:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4JH6GtJpylJ for ; Fri, 29 Jan 2016 15:22:41 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 910B91ACD4B for ; Fri, 29 Jan 2016 15:22:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mqFUGbSD4Qk/xAXRp3TPo/qCuNriBrDZjSm1p6xxcFY=; b=bWPmUWpAjyawzPjJToIQbHyaO1zCFg7OZVJcHcz+J2w+e2JAVtCLDQZfuZANCb5whiYBnnnTBVREiMRdVTlkKQpypIXOpwMv1Pg1zi/nnARn+n7zwAthYUhyidNWbeMkOcXK0CdwmzD66B2YzWuGJnroYaatOx9Do3iCRxudhVM=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB441.namprd03.prod.outlook.com (10.141.141.142) with Microsoft SMTP Server (TLS) id 15.1.396.15; Fri, 29 Jan 2016 23:22:21 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0396.017; Fri, 29 Jan 2016 23:22:21 +0000
From: Mike Jones 
To: John Bradley , Nat Sakimura 
Thread-Topic: [OAUTH-WG] OAuth Discovery metadata values added for revocation,  introspection, and PKCE
Thread-Index: AdFZ+/MJivXRQw+8SrOHcZb7gBYlNwAk+5sAAAHSQoAAAfAPAAATOC4A
Date: Fri, 29 Jan 2016 23:22:21 +0000
Message-ID: 
References:  <56AB59CA.5070408@connect2id.com>  <5CDF5150-89C7-4EC7-92C8-EE356C30993F@ve7jtb.com>
In-Reply-To: <5CDF5150-89C7-4EC7-92C8-EE356C30993F@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none;ve7jtb.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [50.47.85.157]
x-ms-office365-filtering-correlation-id: d179dda7-ebe2-4875-e2a7-08d3290309e7
x-microsoft-exchange-diagnostics: 1; BY2PR03MB441; 5:59BKmi2Ic8iJlpDEIXEWyANIV5BX8h09+7YRgNdGEuGbqWOoLdmkpgRGfHH87GXFzjywD7Hp/j4635akZJYj3X4u8uAgWWMQypOX29T4FWFO3TdILnVe4QpHlBRNyENVndNHIlXVlVBICcLDm1PwCg==; 24:giEXMxa21pbdUOqFpLzzBHWYQmv4yhMmPysnRViDweUxtMPkeXno4esPuSPbfaCSdrf5NSwSs0Y2zDn/MGBN0P7x8Xf466Tn2/O6cexJj4Y=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB441;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BY2PR03MB441; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB441; 
x-forefront-prvs: 083691450C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(24454002)(377454003)(479174004)(92566002)(99286002)(3280700002)(2906002)(5003600100002)(76576001)(86362001)(15975445007)(5002640100001)(790700001)(3846002)(3660700001)(4326007)(5004730100002)(1220700001)(93886004)(1096002)(10090500001)(6116002)(586003)(102836003)(2950100001)(77096005)(3470700001)(11100500001)(40100003)(19617315012)(19609705001)(33656002)(5008740100001)(19300405004)(10290500002)(2900100001)(10400500002)(5005710100001)(122556002)(50986999)(54356999)(74316001)(76176999)(19625215002)(189998001)(561944003)(19580405001)(87936001)(5001960100002)(86612001)(16236675004)(66066001)(19580395003)(5001770100001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB441; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB4429A6A763D5A283FC09B70F5DB0BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jan 2016 23:22:21.4548 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB441
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 29 Jan 2016 23:22:46 -0000

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

RG8gdGhlIFBLQ0UgYXV0aG9ycyB3YW50IHRvIG1ha2UgYSBjb25jcmV0ZSBwcm9wb3NhbCBmb3Ig
aG93IHRvIHJlcHJlc2VudCB0aGlzIGluIGRpc2NvdmVyeSBtZXRhZGF0YT8NCg0KRnJvbTogT0F1
dGggW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBCcmFk
bGV5DQpTZW50OiBGcmlkYXksIEphbnVhcnkgMjksIDIwMTYgNjoxMSBBTQ0KVG86IE5hdCBTYWtp
bXVyYSA8c2FraW11cmFAZ21haWwuY29tPg0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBS
ZTogW09BVVRILVdHXSBPQXV0aCBEaXNjb3ZlcnkgbWV0YWRhdGEgdmFsdWVzIGFkZGVkIGZvciBy
ZXZvY2F0aW9uLCBpbnRyb3NwZWN0aW9uLCBhbmQgUEtDRQ0KDQpUaGUgb25seSBwcm9ibGVtIHdp
dGggdGhhdCBpcyB0aGUgY2xpZW50IG1heSBvbmx5IHJlcXVpcmUgaXQgZm9yIHNvbWUgdHlwZXMg
b2YgY2xpZW50cyAocHVibGljKSBvciByZXNwb25zZSB0eXBlcy4NCg0KSXQgbWF5IG5lZWQgdG8g
YmUgZmluZXIgZ3JhaW5lZCB0aGFuIHRoYXQsIG9yIGRlZmluZSBpdCBhcyByZXF1aXJlZCBmb3Ig
YWxsIHB1YmxpYyBjbGllbnRzIHVzaW5nIHRoZSB0b2tlbiBlbmRwb2ludC4NCg0KSm9obiBCLg0K
DQoNCk9uIEphbiAyOSwgMjAxNiwgYXQgMTA6MTUgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFA
Z21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCg0KR29vZCBxdWVz
dGlvbi4NCg0KSXQncyBwcm9iYWJseSBhIGdvb2QgaWRlYSB0byBiZSBhYmxlIHRvIGFkdmVydGlz
ZSB0aGlzIHBvbGljeSBpbiB0aGUgZGlzY292ZXJ5Lg0KDQpQZXJoYXBzIGluIHRoZSBsaW5lIG9m
DQoNCnBrY2VfcmVxdWlyZWQgb3IgcmZjNzYzNl9yZXF1aXJlZD8NClRoZSB2YWx1ZSBzaG91bGQg
YmUgQm9vbGVhbi4NCg0KTmF0IGZyb20gaVBob25lDQoNCjIwMTblubQx5pyIMjnml6Uo6YeRKSAy
MToyMyBWbGFkaW1pciBEemh1dmlub3YgPHZsYWRpbWlyQGNvbm5lY3QyaWQuY29tPG1haWx0bzp2
bGFkaW1pckBjb25uZWN0MmlkLmNvbT4+Og0KVGhhbmtzIE1pa2UsIHRoZSB1cGRhdGVkIHNwZWMg
bG9va3MgZ29vZCENCg0KSSBoYXZlIGEgcXVlc3Rpb24gcmVsYXRlZCB0byBQS0NFOg0KDQpUaGUg
UEtDRSBzcGVjIHNlZW1zIHRvIGltcGx5IHRoYXQgYW4gQVMgbWF5IHJlcXVpcmUgcHVibGljIGNs
aWVudHMgdG8gdXNlIGEgY29kZSBjaGFsbGVuZ2U6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9yZmM3NjM2I3NlY3Rpb24tNC40LjENCg0KSWYgYW4gQVMgaGFzIHN1Y2ggYSBwb2xpY3kg
aW4gcGxhY2UsIGhvdyBpcyB0aGlzIHRvIGJlIGFkdmVydGlzZWQ/IE9yIGlzIHRoYXQgc3VwcG9z
ZWQgdG8gdGhlIGVuZm9yY2VkIHdoZW4gdGhlIGNsaWVudCBnZXRzIHJlZ2lzdGVyZWQgKHRoZXJl
IGFyZSBubyByZWcgcGFyYW1zIGZvciB0aGF0IGF0IHByZXNlbnQpPw0KDQpPbiAyOC8wMS8xNiAx
OToyNywgTWlrZSBKb25lcyB3cm90ZToNCg0KVGhlIE9BdXRoIERpc2NvdmVyeSBzcGVjaWZpY2F0
aW9uIGhhcyBiZWVuIHVwZGF0ZWQgdG8gYWRkIG1ldGFkYXRhIHZhbHVlcyBmb3IgcmV2b2NhdGlv
bjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MDA5PjxodHRwOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9yZmM3MDA5PiwgaW50cm9zcGVjdGlvbjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9yZmM3NjYyPjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjYyPiwgYW5kIFBLQ0U8
aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzYzNj48aHR0cDovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvcmZjNzYzNj4uICBDaGFuZ2VzIHdlcmU6DQoNCg0KDQoqICAgICAgIEFkZGVkICJyZXZv
Y2F0aW9uX2VuZHBvaW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQiIGFuZCAicmV2b2NhdGlvbl9l
bmRwb2ludF9hdXRoX3NpZ25pbmdfYWxnX3ZhbHVlc19zdXBwb3J0ZWQiIGZvciB0aGUgcmV2b2Nh
dGlvbiBlbmRwb2ludC4NCg0KDQoNCiogICAgICAgQWRkZWQgImludHJvc3BlY3Rpb25fZW5kcG9p
bnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCIgYW5kICJpbnRyb3NwZWN0aW9uX2VuZHBvaW50X2F1
dGhfc2lnbmluZ19hbGdfdmFsdWVzX3N1cHBvcnRlZCIgZm9yIHRoZSBpbnRyb3NwZWN0aW9uIGVu
ZHBvaW50Lg0KDQoNCg0KKiAgICAgICBBZGRlZCAiY29kZV9jaGFsbGVuZ2VfbWV0aG9kc19zdXBw
b3J0ZWQiIGZvciBQS0NFLg0KDQoNCg0KVGhlIHNwZWNpZmljYXRpb24gaXMgYXZhaWxhYmxlIGF0
Og0KDQoNCg0KKiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb25lcy1v
YXV0aC1kaXNjb3ZlcnktMDENCg0KDQoNCkFuIEhUTUwtZm9ybWF0dGVkIHZlcnNpb24gaXMgYWxz
byBhdmFpbGFibGUgYXQ6DQoNCg0KDQoqICAgICAgIGh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2Rv
Y3MvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5LTAxLmh0bWwNCg0KDQoNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoN
Cg0KDQpQLlMuICBUaGlzIG5vdGUgd2FzIGFsc28gcHVibGlzaGVkIGF0IGh0dHA6Ly9zZWxmLWlz
c3VlZC5pbmZvLz9wPTE1MzEgYW5kIGFzIEBzZWxmaXNzdWVkPGh0dHBzOi8vdHdpdHRlci5jb20v
c2VsZmlzc3VlZD48aHR0cHM6Ly90d2l0dGVyLmNvbS9zZWxmaXNzdWVkPi4NCg0KDQoNCg0KDQoN
Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KT0F1
dGggbWFpbGluZyBsaXN0DQoNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4N
Cg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KLS0N
Cg0KVmxhZGltaXIgRHpodXZpbm92DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86
T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1
dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBh
bm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl
ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ
e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7
DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z
b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs
b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj
b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291
cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN
Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K
CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu
LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS
b21hbiIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt
ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7
fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQouTXNv
Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu
MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46
MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT
ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk
ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t
PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K
PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+
PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp
bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkRvIHRoZSBQS0NFIGF1dGhvcnMg
d2FudCB0byBtYWtlIGEgY29uY3JldGUgcHJvcG9zYWwgZm9yIGhvdyB0byByZXByZXNlbnQgdGhp
cyBpbiBkaXNjb3ZlcnkgbWV0YWRhdGE/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxl
PSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gT0F1dGggW21haWx0bzpvYXV0aC1i
b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb2huIEJyYWRsZXk8YnI+DQo8
Yj5TZW50OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDI5LCAyMDE2IDY6MTEgQU08YnI+DQo8Yj5Ubzo8
L2I+IE5hdCBTYWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwv
Yj4gb2F1dGhAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gT0F1
dGggRGlzY292ZXJ5IG1ldGFkYXRhIHZhbHVlcyBhZGRlZCBmb3IgcmV2b2NhdGlvbiwgaW50cm9z
cGVjdGlvbiwgYW5kIFBLQ0U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5UaGUgb25seSBwcm9ibGVtIHdpdGggdGhhdCBpcyB0aGUgY2xpZW50IG1heSBvbmx5
IHJlcXVpcmUgaXQgZm9yIHNvbWUgdHlwZXMgb2YgY2xpZW50cyAocHVibGljKSBvciByZXNwb25z
ZSB0eXBlcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0
IG1heSBuZWVkIHRvIGJlIGZpbmVyIGdyYWluZWQgdGhhbiB0aGF0LCBvciBkZWZpbmUgaXQgYXMg
cmVxdWlyZWQgZm9yIGFsbCBwdWJsaWMgY2xpZW50cyB1c2luZyB0aGUgdG9rZW4gZW5kcG9pbnQu
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpv
aG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+T24gSmFuIDI5LCAyMDE2LCBhdCAxMDoxNSBBTSwgTmF0IFNha2ltdXJhICZsdDs8YSBo
cmVmPSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIj5zYWtpbXVyYUBnbWFpbC5jb208L2E+Jmd0
OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1ib3R0b206MTIuMHB0Ij5Hb29kIHF1ZXN0aW9uLiA8YnI+DQo8YnI+DQpJdCdzIHByb2Jh
Ymx5IGEgZ29vZCBpZGVhIHRvIGJlIGFibGUgdG8gYWR2ZXJ0aXNlIHRoaXMgcG9saWN5IGluIHRo
ZSBkaXNjb3ZlcnkuIDxicj4NCjxicj4NClBlcmhhcHMgaW4gdGhlIGxpbmUgb2YgPGJyPg0KPGJy
Pg0KcGtjZV9yZXF1aXJlZCBvciByZmM3NjM2X3JlcXVpcmVkPyA8YnI+DQpUaGUgdmFsdWUgc2hv
dWxkIGJlIEJvb2xlYW4uIDxicj4NCjxicj4NCk5hdCBmcm9tIGlQaG9uZTxicj4NCjxicj4NCjxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yMDE2PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+5bm0PC9zcGFuPjE8c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6U2ltU3VuIj7mnIg8L3NwYW4+Mjk8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2lt
U3VuIj7ml6U8L3NwYW4+KDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPumHkTwvc3Bh
bj4pIDIxOjIzIFZsYWRpbWlyIER6aHV2aW5vdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZsYWRpbWly
QGNvbm5lY3QyaWQuY29tIj52bGFkaW1pckBjb25uZWN0MmlkLmNvbTwvYT4mZ3Q7OjxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s
ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhhbmtzIE1pa2UsIHRoZSB1cGRhdGVkIHNw
ZWMgbG9va3MgZ29vZCE8YnI+DQo8YnI+DQpJIGhhdmUgYSBxdWVzdGlvbiByZWxhdGVkIHRvIFBL
Q0U6PGJyPg0KPGJyPg0KVGhlIFBLQ0Ugc3BlYyBzZWVtcyB0byBpbXBseSB0aGF0IGFuIEFTIG1h
eSByZXF1aXJlIHB1YmxpYyBjbGllbnRzIHRvIHVzZSBhIGNvZGUgY2hhbGxlbmdlOjxicj4NCjxi
cj4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjM2I3NlY3Rpb24t
NC40LjEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzYz
NiNzZWN0aW9uLTQuNC4xPC9hPjxicj4NCjxicj4NCklmIGFuIEFTIGhhcyBzdWNoIGEgcG9saWN5
IGluIHBsYWNlLCBob3cgaXMgdGhpcyB0byBiZSBhZHZlcnRpc2VkPyBPciBpcyB0aGF0IHN1cHBv
c2VkIHRvIHRoZSBlbmZvcmNlZCB3aGVuIHRoZSBjbGllbnQgZ2V0cyByZWdpc3RlcmVkICh0aGVy
ZSBhcmUgbm8gcmVnIHBhcmFtcyBmb3IgdGhhdCBhdCBwcmVzZW50KT88YnI+DQo8YnI+DQo8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyOC8wMS8xNiAxOToy
NywgTWlrZSBKb25lcyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPlRoZSBP
QXV0aCBEaXNjb3Zlcnkgc3BlY2lmaWNhdGlvbiBoYXMgYmVlbiB1cGRhdGVkIHRvIGFkZCBtZXRh
ZGF0YSB2YWx1ZXMgZm9yIHJldm9jYXRpb248YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9yZmM3MDA5IiB0YXJnZXQ9Il9ibGFuayI+Jmx0O2h0dHA6Ly90b29scy5pZXRmLm9yZy9o
dG1sL3JmYzcwMDkmZ3Q7PC9hPiwgaW50cm9zcGVjdGlvbjxhIGhyZWY9Imh0dHA6Ly90b29scy5p
ZXRmLm9yZy9odG1sL3JmYzc2NjIiIHRhcmdldD0iX2JsYW5rIj4mbHQ7aHR0cDovL3Rvb2xzLmll
dGYub3JnL2h0bWwvcmZjNzY2MiZndDs8L2E+LCBhbmQgUEtDRTxhIGhyZWY9Imh0dHA6Ly90b29s
cy5pZXRmLm9yZy9odG1sL3JmYzc2MzYiIHRhcmdldD0iX2JsYW5rIj4mbHQ7aHR0cDovL3Rvb2xz
LmlldGYub3JnL2h0bWwvcmZjNzYzNiZndDs8L2E+LiZuYnNwOyBDaGFuZ2VzIHdlcmU6PG86cD48
L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+KiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBZGRlZCAmcXVvdDtyZXZvY2F0aW9uX2VuZHBv
aW50X2F1dGhfbWV0aG9kc19zdXBwb3J0ZWQmcXVvdDsgYW5kICZxdW90O3Jldm9jYXRpb25fZW5k
cG9pbnRfYXV0aF9zaWduaW5nX2FsZ192YWx1ZXNfc3VwcG9ydGVkJnF1b3Q7IGZvciB0aGUgcmV2
b2NhdGlvbiBlbmRwb2ludC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT4qJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFkZGVk
ICZxdW90O2ludHJvc3BlY3Rpb25fZW5kcG9pbnRfYXV0aF9tZXRob2RzX3N1cHBvcnRlZCZxdW90
OyBhbmQgJnF1b3Q7aW50cm9zcGVjdGlvbl9lbmRwb2ludF9hdXRoX3NpZ25pbmdfYWxnX3ZhbHVl
c19zdXBwb3J0ZWQmcXVvdDsgZm9yIHRoZSBpbnRyb3NwZWN0aW9uIGVuZHBvaW50LjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiombmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQWRkZWQgJnF1b3Q7Y29kZV9jaGFsbGVuZ2VfbWV0
aG9kc19zdXBwb3J0ZWQmcXVvdDsgZm9yIFBLQ0UuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86
cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhlIHNwZWNpZmljYXRpb24gaXMgYXZhaWxhYmxl
IGF0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PiombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtZGlzY292ZXJ5LTAxIiB0YXJnZXQ9
Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9uZXMtb2F1dGgtZGlz
Y292ZXJ5LTAxPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPkFuIEhUTUwtZm9ybWF0dGVkIHZlcnNpb24gaXMgYWxzbyBhdmFpbGFibGUgYXQ6
PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+KiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vc2VsZi1p
c3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWpvbmVzLW9hdXRoLWRpc2NvdmVyeS0wMS5odG1sIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1qb25lcy1vYXV0
aC1kaXNjb3ZlcnktMDEuaHRtbDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlAuUy4mbmJzcDsgVGhpcyBub3RlIHdhcyBhbHNvIHB1
Ymxpc2hlZCBhdCA8YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby8/cD0xNTMxIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cDovL3NlbGYtaXNzdWVkLmluZm8vP3A9MTUzMTwvYT4gYW5kIGFzIEBz
ZWxmaXNzdWVkPGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9zZWxmaXNzdWVkIiB0YXJnZXQ9
Il9ibGFuayI+Jmx0O2h0dHBzOi8vdHdpdHRlci5jb20vc2VsZmlzc3VlZCZndDs8L2E+LjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8
cHJlPk9BdXRoIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1h
aWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPk9BdXRoQGlldGYub3JnPC9hPjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwv
bzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+VmxhZGltaXIgRHpodXZp
bm92PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWls
aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0iX2Js
YW5rIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx
dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8
YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxh
IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_BY2PR03MB4429A6A763D5A283FC09B70F5DB0BY2PR03MB442namprd_--


From nobody Sun Jan 31 04:13:53 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF8F1A0173 for ; Sun, 31 Jan 2016 04:13:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.709
X-Spam-Level: 
X-Spam-Status: No, score=0.709 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nkR0Fl0iu3P for ; Sun, 31 Jan 2016 04:13:48 -0800 (PST)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) (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 1B5B61A0169 for ; Sun, 31 Jan 2016 04:13:47 -0800 (PST)
Received: from [79.218.87.147] (helo=[192.168.71.102]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aPqsz-000762-7C; Sun, 31 Jan 2016 13:13:45 +0100
To: Mike Jones , "oauth@ietf.org" 
References: 
From: Torsten Lodderstedt 
Message-ID: <56ADFA72.5090407@lodderstedt.net>
Date: Sun, 31 Jan 2016 13:13:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070004040603020308090002"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jan 2016 12:13:51 -0000

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

Hi Mike,

the current revocation RFC does not support request signing. So what is 
the intention of revocation_endpoint_auth_signing_alg_values_supported?

best regards,
Torsten.

Am 28.01.2016 um 20:27 schrieb Mike Jones:
>
> The OAuth Discovery specification has been updated to add metadata 
> values for revocation , 
> introspection , and PKCE 
> .  Changes were:
>
> ·Added “revocation_endpoint_auth_methods_supported” and 
> “revocation_endpoint_auth_signing_alg_values_supported” for the 
> revocation endpoint.
>
> ·Added “introspection_endpoint_auth_methods_supported” and 
> “introspection_endpoint_auth_signing_alg_values_supported” for the 
> introspection endpoint.
>
> ·Added “code_challenge_methods_supported” for PKCE.
>
> The specification is available at:
>
> ·http://tools.ietf.org/html/draft-jones-oauth-discovery-01
>
> An HTML-formatted version is also available at:
>
> ·http://self-issued.info/docs/draft-jones-oauth-discovery-01.html
>
> -- Mike
>
> P.S.  This note was also published at http://self-issued.info/?p=1531 
>  and as @selfissued 
> .
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--------------070004040603020308090002
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Mike,

    

    the current revocation RFC does not support request signing. So what
    is the intention of
    revocation_endpoint_auth_signing_alg_values_supported?

    

    best regards,

    Torsten.

    

    
Am 28.01.2016 um 20:27 schrieb Mike
      Jones:

    

    

      
      
      
      

        
The OAuth Discovery specification has been
          updated to add metadata values for
          revocation, 
            introspection, and PKCE.  Changes
          were:

        
·      
              Added “revocation_endpoint_auth_methods_supported”
          and “revocation_endpoint_auth_signing_alg_values_supported”
          for the revocation endpoint.
          

        
·      
              Added “introspection_endpoint_auth_methods_supported”
          and “introspection_endpoint_auth_signing_alg_values_supported”
          for the introspection endpoint. 

        
·      
              Added “code_challenge_methods_supported”
          for PKCE.

        
 

        
The specification is available at:

        
·      
              http://tools.ietf.org/html/draft-jones-oauth-discovery-01

        
 

        
An HTML-formatted version is also available
          at:

        
·      
              http://self-issued.info/docs/draft-jones-oauth-discovery-01.html

        
 

        
                                                         
          -- Mike

        
 

        
P.S.  This note was also published at 
            http://self-issued.info/?p=1531 and as 
            @selfissued.

        
 

      

      

      

      

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


    

    

  


--------------070004040603020308090002--


From nobody Sun Jan 31 05:47:31 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F7A1A1A97 for ; Sun, 31 Jan 2016 05:47:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.941
X-Spam-Level: 
X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYFybsLVs4LY for ; Sun, 31 Jan 2016 05:47:26 -0800 (PST)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A645E1A026C for ; Sun, 31 Jan 2016 05:47:24 -0800 (PST)
X-AuditID: 1209190f-1a7ff7000000099f-09-56ae106b4737
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 CC.0E.02463.B601EA65; Sun, 31 Jan 2016 08:47:23 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u0VDlMjF029132; Sun, 31 Jan 2016 08:47:22 -0500
Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u0VDlKcR028986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 31 Jan 2016 08:47:21 -0500
To: Torsten Lodderstedt , Mike Jones , "oauth@ietf.org" 
References:  <56ADFA72.5090407@lodderstedt.net>
From: Justin Richer 
Message-ID: <56AE105B.9080101@mit.edu>
Date: Sun, 31 Jan 2016 08:47:07 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56ADFA72.5090407@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------010404070407000905050508"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hRV1s0WWBdmsLtR1GLvtE8sFiffvmKz eHXsKYsDs8eSJT+ZPI719LN6tO74yx7AHMVlk5Kak1mWWqRvl8CVcWfKSbaCGVMYK07+dmhg fFLdxcjJISFgIvH+53UWEFtIoI1JYma/UhcjF5C9kVFi3YSnjBDObSaJqe3HGEGqhAXSJf7c /sUMkhARmMAosezxAlaI9nqJjolXwGw2AVWJ6WtamEBsXgE1iXUNPWwgNgtQfMWUJWBxUYEY iYudR6BqBCVOznwCdgangL7ErY33mUFsZoEwidlbzrFMYOSbhaRsFpIUhG0rcWfubmYIW16i eetsKFtXYtG2FezI4gsY2VYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmujlZpbopaaUbmIEh7Uk /w7GbweVDjEKcDAq8fByGKwNE2JNLCuuzD3EKMnBpCTK264FFOJLyk+pzEgszogvKs1JLT7E KMHBrCTCe/wPUI43JbGyKrUoHyYlzcGiJM67q2NumJBAemJJanZqakFqEUxWhoNDSYK3jX9d mJBgUWp6akVaZk4JQpqJgxNkOA/Q8EkgNbzFBYm5xZnpEPlTjIpS4rxGIAkBkERGaR5cLyjt JLw9bPqKURzoFWHeK3xAVTzAlAXX/QpoMBPQYBfZ1SCDSxIRUlINjCrmzkefcXkldu7eLX35 SbVWtYZA4e5vn9suJAcVxikbGqgvf3b1QePSK3K6WuIXbBsMJ2+o//19ioHS5El7/V1znrya mb+lfdnkrblXLIzFbdpM81161q4wd9w4u6ws9rr+qR4WrcStJhNt69+1zr29S9+/6vjJOVnT tPz1F5wUPlDT2L+2QYmlOCPRUIu5qDgRAETqriYWAwAA
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jan 2016 13:47:29 -0000

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

It would be for client authentication to the revocation endpoint, if the 
client were to use client_secret_jwt or private_key_jwt methods to 
authenticate. Our implementation actually allows this, but we don't let 
clients choose more than one authentication method across three 
endpoints (token, revocation, and introspection).

A value we might want to add for revocation and introspection is 
"bearer_token", since it makes sense in both cases to give a client an 
access token to call these endpoints as opposed to credentials. This 
would need to be added to the token endpoint authentication methods 
registry.

  -- Justin

On 1/31/2016 7:13 AM, Torsten Lodderstedt wrote:
> Hi Mike,
>
> the current revocation RFC does not support request signing. So what 
> is the intention of revocation_endpoint_auth_signing_alg_values_supported?
>
> best regards,
> Torsten.
>
> Am 28.01.2016 um 20:27 schrieb Mike Jones:
>>
>> The OAuth Discovery specification has been updated to add metadata 
>> values for revocation , 
>> introspection , and PKCE 
>> . Changes were:
>>
>> ·Added “revocation_endpoint_auth_methods_supported” and 
>> “revocation_endpoint_auth_signing_alg_values_supported” for the 
>> revocation endpoint.
>>
>> ·Added “introspection_endpoint_auth_methods_supported” and 
>> “introspection_endpoint_auth_signing_alg_values_supported” for the 
>> introspection endpoint.
>>
>> ·Added “code_challenge_methods_supported” for PKCE.
>>
>> The specification is available at:
>>
>> ·http://tools.ietf.org/html/draft-jones-oauth-discovery-01
>>
>> An HTML-formatted version is also available at:
>>
>> ·http://self-issued.info/docs/draft-jones-oauth-discovery-01.html
>>
>> -- Mike
>>
>> P.S.  This note was also published at 
>> http://self-issued.info/?p=1531 and 
>> as @selfissued .
>>
>>
>>
>> _______________________________________________
>> 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


--------------010404070407000905050508
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    It would be for client authentication to the revocation endpoint, if
    the client were to use client_secret_jwt or private_key_jwt methods
    to authenticate. Our implementation actually allows this, but we
    don't let clients choose more than one authentication method across
    three endpoints (token, revocation, and introspection). 

    

    A value we might want to add for revocation and introspection is
    "bearer_token", since it makes sense in both cases to give a client
    an access token to call these endpoints as opposed to credentials.
    This would need to be added to the token endpoint authentication
    methods registry.

    

     -- Justin

    

    
On 1/31/2016 7:13 AM, Torsten
      Lodderstedt wrote:

    

    

      
      Hi Mike,

      

      the current revocation RFC does not support request signing. So
      what is the intention of
      revocation_endpoint_auth_signing_alg_values_supported?

      

      best regards,

      Torsten.

      

      
Am 28.01.2016 um 20:27 schrieb Mike
        Jones:

      

      

        
        
        

          
The OAuth Discovery specification has
            been updated to add metadata values for revocation,
             introspection,
            and PKCE. 
            Changes were:

          
·      
                Added “revocation_endpoint_auth_methods_supported”
            and “revocation_endpoint_auth_signing_alg_values_supported”
            for the revocation endpoint. 

          
·      
                Added “introspection_endpoint_auth_methods_supported”
            and “introspection_endpoint_auth_signing_alg_values_supported”
            for the introspection endpoint. 

          
·      
                Added “code_challenge_methods_supported”
            for PKCE.

          
 

          
The specification is available at:

          
·      
                http://tools.ietf.org/html/draft-jones-oauth-discovery-01

          
 

          
An HTML-formatted version is also
            available at:

          
·      
                http://self-issued.info/docs/draft-jones-oauth-discovery-01.html

          
 

          
                                                         

            -- Mike

          
 

          
P.S.  This note was also published at  http://self-issued.info/?p=1531
            and as  @selfissued.

          
 

        

        

        

        

        
_______________________________________________
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


    

    

  


--------------010404070407000905050508--


From nobody Sun Jan 31 08:22:05 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C1F1A8824 for ; Sun, 31 Jan 2016 08:22:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.991
X-Spam-Level: 
X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpLVUzS5Wgta for ; Sun, 31 Jan 2016 08:22:01 -0800 (PST)
Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C1A1A872D for ; Sun, 31 Jan 2016 08:22:00 -0800 (PST)
Received: from [79.218.87.147] (helo=[192.168.71.102]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aPukf-0004CX-7b; Sun, 31 Jan 2016 17:21:25 +0100
To: Justin Richer , Mike Jones , "oauth@ietf.org" 
References:  <56ADFA72.5090407@lodderstedt.net> <56AE105B.9080101@mit.edu>
From: Torsten Lodderstedt 
Message-ID: <56AE349F.6040103@lodderstedt.net>
Date: Sun, 31 Jan 2016 17:21:51 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56AE105B.9080101@mit.edu>
Content-Type: multipart/alternative; boundary="------------020901040606040408020003"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: 
Subject: Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jan 2016 16:22:04 -0000

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

sounds reasonable - but is not covered by the current RFC, which would 
be the pre-requisite for interop. That's what I wanted to point out.

kind regards,
Torsten.

Am 31.01.2016 um 14:47 schrieb Justin Richer:
> It would be for client authentication to the revocation endpoint, if 
> the client were to use client_secret_jwt or private_key_jwt methods to 
> authenticate. Our implementation actually allows this, but we don't 
> let clients choose more than one authentication method across three 
> endpoints (token, revocation, and introspection).
>
> A value we might want to add for revocation and introspection is 
> "bearer_token", since it makes sense in both cases to give a client an 
> access token to call these endpoints as opposed to credentials. This 
> would need to be added to the token endpoint authentication methods 
> registry.
>
>  -- Justin
>
> On 1/31/2016 7:13 AM, Torsten Lodderstedt wrote:
>> Hi Mike,
>>
>> the current revocation RFC does not support request signing. So what 
>> is the intention of 
>> revocation_endpoint_auth_signing_alg_values_supported?
>>
>> best regards,
>> Torsten.
>>
>> Am 28.01.2016 um 20:27 schrieb Mike Jones:
>>>
>>> The OAuth Discovery specification has been updated to add metadata 
>>> values for revocation , 
>>> introspection , and PKCE 
>>> . Changes were:
>>>
>>> ·Added “revocation_endpoint_auth_methods_supported” and 
>>> “revocation_endpoint_auth_signing_alg_values_supported” for the 
>>> revocation endpoint.
>>>
>>> ·Added “introspection_endpoint_auth_methods_supported” and 
>>> “introspection_endpoint_auth_signing_alg_values_supported” for the 
>>> introspection endpoint.
>>>
>>> ·Added “code_challenge_methods_supported” for PKCE.
>>>
>>> The specification is available at:
>>>
>>> ·http://tools.ietf.org/html/draft-jones-oauth-discovery-01
>>>
>>> An HTML-formatted version is also available at:
>>>
>>> ·http://self-issued.info/docs/draft-jones-oauth-discovery-01.html
>>>
>>> -- Mike
>>>
>>> P.S.  This note was also published at 
>>> http://self-issued.info/?p=1531 and 
>>> as @selfissued .
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>


--------------020901040606040408020003
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    sounds reasonable - but is not covered by the current RFC, which
    would be the pre-requisite for interop. That's what I wanted to
    point out. 

    

    kind regards,

    Torsten.

    

    
Am 31.01.2016 um 14:47 schrieb Justin
      Richer:

    

    

      
      It would be for client authentication to the revocation endpoint,
      if the client were to use client_secret_jwt or private_key_jwt
      methods to authenticate. Our implementation actually allows this,
      but we don't let clients choose more than one authentication
      method across three endpoints (token, revocation, and
      introspection). 

      

      A value we might want to add for revocation and introspection is
      "bearer_token", since it makes sense in both cases to give a
      client an access token to call these endpoints as opposed to
      credentials. This would need to be added to the token endpoint
      authentication methods registry.

      

       -- Justin

      

      
On 1/31/2016 7:13 AM, Torsten
        Lodderstedt wrote:

      

      

        
        Hi Mike,

        

        the current revocation RFC does not support request signing. So
        what is the intention of
        revocation_endpoint_auth_signing_alg_values_supported?

        

        best regards,

        Torsten.

        

        
Am 28.01.2016 um 20:27 schrieb Mike
          Jones:

        

        

          
          
          

            
The OAuth Discovery specification has
              been updated to add metadata values for revocation,
               introspection,
              and PKCE. 
              Changes were:

            
·      

                  Added “revocation_endpoint_auth_methods_supported”
              and “revocation_endpoint_auth_signing_alg_values_supported”
              for the revocation endpoint. 

            
·      

                  Added “introspection_endpoint_auth_methods_supported”
              and “introspection_endpoint_auth_signing_alg_values_supported”
              for the introspection endpoint. 

            
·      

                  Added “code_challenge_methods_supported”
              for PKCE.

            
 

            
The specification is available at:

            
·      

                  http://tools.ietf.org/html/draft-jones-oauth-discovery-01

            
 

            
An HTML-formatted version is also
              available at:

            
·      

                  http://self-issued.info/docs/draft-jones-oauth-discovery-01.html

            
 

            
                                                         


              -- Mike

            
 

            
P.S.  This note was also published at  http://self-issued.info/?p=1531
              and as  @selfissued.

            
 

          

          

          

          

          
_______________________________________________
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


      

      

    

    

  


--------------020901040606040408020003--


From nobody Sun Jan 31 10:51:31 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163D91B2BBA for ; Sun, 31 Jan 2016 10:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHnCyhhJO5Ew for ; Sun, 31 Jan 2016 10:51:27 -0800 (PST)
Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496921B2BB5 for ; Sun, 31 Jan 2016 10:51:25 -0800 (PST)
X-AuditID: 1209190f-1a7ff7000000099f-bb-56ae57ab3764
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 D6.B7.02463.BA75EA65; Sun, 31 Jan 2016 13:51:24 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id u0VIpNUG022236; Sun, 31 Jan 2016 13:51:23 -0500
Received: from [192.168.128.48] (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 u0VIpKlY005501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 31 Jan 2016 13:51:22 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_44F1D92A-7A97-44CC-B109-97D45BA64DE6"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Justin Richer 
In-Reply-To: <56AE349F.6040103@lodderstedt.net>
Date: Sun, 31 Jan 2016 13:51:20 -0500
Message-Id: <46E8C558-F030-4049-86E1-D0A61FCA3A10@mit.edu>
References:  <56ADFA72.5090407@lodderstedt.net> <56AE105B.9080101@mit.edu> <56AE349F.6040103@lodderstedt.net>
To: Torsten Lodderstadt 
X-Mailer: Apple Mail (2.2104)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IR4hRV1l0Tvi7MYPcVZou90z6xWJx8+4rN 4tWxpywOzB5Llvxk8jjW08/q0brjL3sAcxSXTUpqTmZZapG+XQJXxo+zu1kLNu9krHjUu4i9 gfH6PMYuRk4OCQETifYL3cxdjFwcQgJtTBI/Jy6DcjYySkz5vY8NpEpI4DaTxKSL+V2MHBzM AgkSN89zgYR5BfQkXt26zApiCwukStzb9IYZxGYTUJWYvqaFCaScU0BfovGMDkiYBSi8qXcT WDmzQJRE9+6f7BBjrCRWNP2G2rSbUeJCsylIq4iAocSvOZkQZ8pK7P79iGkCI/8shBtmIblh FthQbYllC18zQ9gGEk87X2ER15d4824O0wJGtlWMsim5Vbq5iZk5xanJusXJiXl5qUW6Jnq5 mSV6qSmlmxjBgS7Jv4Px20GlQ4wCHIxKPLwcBmvDhFgTy4orcw8xSnIwKYnytmsBhfiS8lMq MxKLM+KLSnNSiw8xSnAwK4nwPjVZFybEm5JYWZValA+TkuZgURLn3dUxN0xIID2xJDU7NbUg tQgmK8PBoSTBeywMqFGwKDU9tSItM6cEIc3EwQkynAdo+FmQGt7igsTc4sx0iPwpRkUpcd5i kIQASCKjNA+uF5SIEt4eNn3FKA70ijDvF5AqHmASg+t+BTSYCWiwi+xqkMEliQgpqQbGyXee /BKeLyySlmcZWvirWn/5btMITgE2lvCjTQkcJ2XN6ksX7DsT1L/smoOdoOaZf6klP9quSOdE XP+18m7/npg/F89+XJnamuW/WOL876qHT1XETc0YNdX+7/7+K/hB0k/zKCX3lxO7brd3PY+I tTnLoSty4XOrYLuTecXvc3If+hQdQn8rsRRnJBpqMRcVJwIAqmocKR8DAAA=
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] OAuth Discovery metadata values added for revocation, introspection, and PKCE
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 31 Jan 2016 18:51:30 -0000

--Apple-Mail=_44F1D92A-7A97-44CC-B109-97D45BA64DE6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Both RFC7009 and RFC7662 just say that the client/protected resource =
authenticate just like they would at the token endpoint, punting to =
RFC6749 on how that happens. Since that=92s extensible, and has been =
extended, that=92s what we=92re going on.

It=92s an unfortunate case where the actual definition is now spread =
across several documents over time. I=92d honestly feel bad for someone =
writing an OAuth2 server from scratch without a guide.

 =97 Justin

> On Jan 31, 2016, at 11:21 AM, Torsten Lodderstedt =
 wrote:
>=20
> sounds reasonable - but is not covered by the current RFC, which would =
be the pre-requisite for interop. That's what I wanted to point out.=20
>=20
> kind regards,
> Torsten.
>=20
> Am 31.01.2016 um 14:47 schrieb Justin Richer:
>> It would be for client authentication to the revocation endpoint, if =
the client were to use client_secret_jwt or private_key_jwt methods to =
authenticate. Our implementation actually allows this, but we don't let =
clients choose more than one authentication method across three =
endpoints (token, revocation, and introspection).=20
>>=20
>> A value we might want to add for revocation and introspection is =
"bearer_token", since it makes sense in both cases to give a client an =
access token to call these endpoints as opposed to credentials. This =
would need to be added to the token endpoint authentication methods =
registry.
>>=20
>>  -- Justin
>>=20
>> On 1/31/2016 7:13 AM, Torsten Lodderstedt wrote:
>>> Hi Mike,
>>>=20
>>> the current revocation RFC does not support request signing. So what =
is the intention of =
revocation_endpoint_auth_signing_alg_values_supported?
>>>=20
>>> best regards,
>>> Torsten.
>>>=20
>>> Am 28.01.2016 um 20:27 schrieb Mike Jones:
>>>> The OAuth Discovery specification has been updated to add metadata =
values for revocation , =
introspection , and PKCE =
.  Changes were:
>>>> =B7       Added =93revocation_endpoint_auth_methods_supported=94 =
and =93revocation_endpoint_auth_signing_alg_values_supported=94 for the =
revocation endpoint.
>>>> =B7       Added =93introspection_endpoint_auth_methods_supported=94 =
and =93introspection_endpoint_auth_signing_alg_values_supported=94 for =
the introspection endpoint.
>>>> =B7       Added =93code_challenge_methods_supported=94 for PKCE.
>>>> =20
>>>> The specification is available at:
>>>> =B7        =
http://tools.ie=
tf.org/html/draft-jones-oauth-discovery-01 =

>>>> =20
>>>> An HTML-formatted version is also available at:
>>>> =B7        =
http://s=
elf-issued.info/docs/draft-jones-oauth-discovery-01.html =

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

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

>>=20
>=20


--Apple-Mail=_44F1D92A-7A97-44CC-B109-97D45BA64DE6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Both RFC7009 and RFC7662 just say that the client/protected =
resource authenticate just like they would at the token endpoint, =
punting to RFC6749 on how that happens. Since that=92s extensible, and =
has been extended, that=92s what we=92re going on.

It=92s an unfortunate case where the =
actual definition is now spread across several documents over time. I=92d =
honestly feel bad for someone writing an OAuth2 server from scratch =
without a guide.

 =97 Justin

On =
Jan 31, 2016, at 11:21 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:



 =20
  

    sounds reasonable - but is not covered by the current RFC, which
    would be the pre-requisite for interop. That's what I wanted to
    point out. 

    

    kind regards,

    Torsten.

    

    
Am 31.01.2016 um 14:47 schrieb Justin
      Richer:

    

    

     =20
      It would be for client authentication to the revocation endpoint,
      if the client were to use client_secret_jwt or private_key_jwt
      methods to authenticate. Our implementation actually allows this,
      but we don't let clients choose more than one authentication
      method across three endpoints (token, revocation, and
      introspection). 

      

      A value we might want to add for revocation and introspection is
      "bearer_token", since it makes sense in both cases to give a
      client an access token to call these endpoints as opposed to
      credentials. This would need to be added to the token endpoint
      authentication methods registry.

      

       -- Justin

      

      
On 1/31/2016 7:13 AM, Torsten
        Lodderstedt wrote:

      

      

       =20
        Hi Mike,

        

        the current revocation RFC does not support request signing. So
        what is the intention of
        revocation_endpoint_auth_signing_alg_values_supported?

        

        best regards,

        Torsten.

        

        
Am 28.01.2016 um 20:27 schrieb =
Mike
          Jones:

        

        

          
          
          
The OAuth =
Discovery specification has
              been updated to add metadata values for revocation,
               =
introspection,
              and PKCE. 
              Changes were:
=B7      

                  Added =93revocation_endpoint_auth_methods_supported=94
              and =93revocation_endpoint_auth_signing_alg_values_supported=94=

              for the revocation endpoint. 
=B7      

                  Added =93introspection_endpoint_auth_methods_supported=94
              and =93introspection_endpoint_auth_signing_alg_values_supported=
=94
              for the introspection endpoint. 
=B7      

                  Added =93code_challenge_methods_supported=94
              for PKCE.
 
The specification is available at:
=B7      

                  http://=
tools.ietf.org/html/draft-jones-oauth-discovery-01
 
An HTML-formatted =
version is also
              available at:
=B7      

                  =
http://self-issued.info/docs/draft-jones-oauth-discovery-01.html
 
         =
            &n=
bsp;           &nbs=
p;            =
           


              -- Mike
 
P.S.  This note =
was also published at  http://self-issued.info/?p=3D15=
31
              and as  @selfissued.
 

          

          

          

          

          
_______________________________________________
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=_44F1D92A-7A97-44CC-B109-97D45BA64DE6--


On =
Jan 26, 2016, at 1:14 AM, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

Still don't see =
it. Though i think the diagram is wrong (the rp should redirct to the ua =
and not call the authz direct), the IDP should either return an error or =
redirect the RP to TLS. 

I don't see this as proper oauth =
protocol since the RP is MITM the UA rather than acting as a =
client. 

Phil

On Jan 25, 2016, at 19:57, nov matake <matake@gmail.com> =
wrote:

=10In this flow, AuthZ =
endpoint is forced to be TLS-protected.
http://nat.sakimura.org/wp-content/uploads/2016/01/oauth-idp-mi=
xup.png

However, RP=E2=80=99s redirect response which causes =
following AuthZ request is still not TLS-protected, and modified on the =
attacker=E2=80=99s proxy.

Section 3.2 of this report also describes the same =
flow.
http://arxiv.org/pdf/1601.01229v2.pdf

On Jan 26, 2016, at 12:37, Phil Hunt (IDM) =
<phil.hunt@oracle.com> wrote:

Also the authz =
endpoint is required to force tls. So if the client doesn't do it the =
authz should reject (eg by upgrading to tls). 

Phil

On Jan 25, 2016, at =
19:29, Phil Hunt (IDM) <phil.hunt@oracle.com> wrote:

When the RP acting as the =
client issues a authorize redirect to the UA it has to make it with =
TLS

Phil

On Jan 25, 2016, at 17:53, Nov Matake <matake@gmail.com> =
wrote:

It =
doen't say anything about the first request which initiate the login =
flow.
It is still a reasonable assumption that RP puts a "login =
with FB" button on a non TLS-protected page.

nov

On Jan 26, 2016, at 10:45, Phil Hunt <phil.hunt@oracle.com> wrote:

I would find it hard to believe that is =
true.

=46rom 6749 =
Sec 3.1 
   Since requests to the authorization =
endpoint result in user
   authentication and the transmission of clear-text credentials (in the
   HTTP response), the authorization server MUST require the use of TLS
   as described in Section 1.6 when sending requests to the
   authorization endpoint.


Sec =
3.1.2.1 
   The redirection endpoint SHOULD require =
the use of TLS as described
   in Section 1.6 when the requested response type is "code" or =
"token",
   or when the redirection request will result in the transmission of
   sensitive credentials over an open network.  This specification does
   not mandate the use of TLS because at the time of this writing,
   requiring clients to deploy TLS is a significant hurdle for many
   client developers.  If TLS is not available, the authorization server
   SHOULD warn the resource owner about the insecure endpoint prior to
   redirection (e.g., display a message during the authorization
   request).

   Lack of transport-layer security can have a severe impact on the
   security of the client and the protected resources it is authorized
   to access.  The use of transport-layer security is particularly
   critical when the authorization process is used as a form of
   delegated end-user authentication by the client (e.g., third-party
   sign-in service).


Section =
10.5 talks about transmission of authorization codes in connection with =
redirects.

Also =
see 6819, Sec 4.4.1.1 regarding eavesdropping or leaking of authz =
codes.











On Jan 25, 2016, at 4:52 PM, nov matake <matake@gmail.com> =
wrote:

The first =
assumption is coming from the original security report at http://arxiv.org/abs/1601.01229.
RFC 6749 =
requires TLS between RS and AS, and also between UA and AS, but not =
between UA and RS.

The blog post is based on my Japanese post, and it describes =
multi-AS case.
Nat's another post describes the =
case which can affect single-AS case too.
http://nat.sakimura.org/2016/01/22/code-phishing-attack-on-oaut=
h-2-0-rfc6749/

nov

On Jan =
26, 2016, at 08:22, Phil Hunt <phil.hunt@oracle.com> wrote:

Sorry, meant =
to reply-all.











Begin forwarded message:

From: Phil Hunt <phil.hunt@oracle.com>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up =
Mitigation
Date: January 25, 2016 at 3:20:19 PM PST
To: Nat Sakimura <sakimura@gmail.com>

I am having trouble with the very first =
assumption. The user-agent sets up a non TLS protected connection to the =
RP? That=E2=80=99s a fundamental violation of 6749.

Also, the second statement says the RP =
(assuming it acts as OAuth client) is talking to two IDPs. =
 That=E2=80=99s still a multi-AS case is it not?










On Jan 25, 2016, at 2:58 PM, Nat Sakimura <sakimura@gmail.com> =
wrote:

Hi Phil, 

Since I was not in Darmstadt, I really =
do not know what was discussed there, but with the compromised developer =
documentation described in http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-r=
fc6749/, all RFC6749 clients with a naive implementer will be =
affected. The client does not need to be talking to multiple =
IdPs. 

Nat

2016=E5=B9=B41=E6=9C=882=
6=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) <phil.hunt@oracle.com>:
I recall making this point in Germany. 99% of =
existing use is fine. OIDC is probably the largest community that =
*might* have an issue.



I recall proposing a new security document that covers oauth security =
for dynamic scenarios. "Dynamic" being broadly defined to mean:

* clients who have configured at runtime or install time (including =
clients that do discovery)

* clients that communicate with more than one endpoint

* clients that are deployed in large volume and may update frequently =
(more discussion of "public" cases)

* clients that are script based (loaded into browser on the fly)

* others?



Phil



> On Jan 25, 2016, at 10:39, George Fletcher <gffletch@aol.com> wrote:

>

> would



_______________________________________________

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
Re: iss. I discussed this a bit with Nov in more details. =
It probably is a sloppy language of the specs that is making it difficult t=
o read what you wanted to achieve.=C2=A0

In mix-up-mitigati=
on draft, OAuth issuer is "the URL of the authorization server's c=
onfiguration information location". In OAuth discovery draft, there is=
 something called "OAuth 2.0 Configuration Information Location URL&qu=
ot;, which is equal to "OpenID Connect Issuer".=C2=A0
When I wrot=
e the statement, I thought you were pointing to the URL that you can actual=
ly pull the configuration information by "the URL of the authorizaiton=
 server's configuration information location" since otherwise you =
would have used the term "OAuth 2.0 Configuration Information Location=
 URL". But after all, you probably meant these two are the same. Then =
I would strongly recommend to fix the language.=C2=A0
Now, even If that is =
the case, the relationship like=C2=A0
  • iss + .well-know/openid-configurat=
ion =3D Connect OP config endoint
  • OA=
uth config endpoint - .well-known/openid-configuration =3D OAuth iss
    • is very confusing.=C2=A0

    You also claim that your approach is simpler, but to me, you=
r approach seem to be overly complex. It requires discovery and the check f=
or the value of the discovered config information to work as the mitigation=
. (Right. Draft -01 does not have it, so it does not solve the mix-up issue=
.) With oauth-meta, you do not need it.=C2=A0

    Fin=
ally, your point that HATEOAS reminds you of WSDL, it is not. If you want t=
o have something similar to WSDL in REST API area, it is Swagger. (Actually=
, it is gaining a lot of momentum recently, but that's beside the fact =
;-). And the point here is not the format but the fact that we need to have=
 a way to associate metadata to the data. The root cause of this mix-up att=
ack is that the metadata and data is not associated properly. We have a sta=
ndard way of associating the data and metadata with link-rel such as RFC598=
8 so why not use it? Link-rel-href pattern is used a lot now. Most modern w=
eb pages actually have it. Using a proper way to associate metadata with da=
ta will save you from a lot of other attacks in the future. Instead of doin=
g patch works, we should solve it=C2=A0architecturally.=C2=A0=


    Nat


=

2016=E5=B9=B41=E6=9C=8822=
=E6=97=A5(=E9=87=91) 10:34 Mike Jones <Michael.Jones@microsoft.com>:











Nat, I=E2=80=99m confused by this sta=
tement in the message you reference =E2=80=9CUnfortunately, this does not match the value
 of OAuth issuer defined in Section 2 of=C2=A0draft-jones-oauth-mix-up-miti=
gation-01 nor the 'iss' returned as specified in 3.1.=C2=A0As such,=
 validation as specified in bullet 1 of Section 4 fails in Google's cas=
e -- OR it means that the document is internally inconsistent.=E2=80=9D.=C2=A0
 The issuer definition in draft-jones-oauth-discovery is 100% compatible wi=
th the one in OpenID Connect Discovery, by design.=C2=A0 In the Google exam=
ple, both the OpenID issuer and the OAuth issuer values would be the string=
 =E2=80=9Chttps:/=
/accounts.google.com=E2=80=9D.=C2=A0 What
 is the inconsistency that you perceive?


=C2=A0


The discussion of the duplication pro=
blem happened in the private meetings in Yokohama.


=C2=A0


I will admit, in Yokohama, I didn=E2=
=80=99t speak up in the public meetings to point out that a simpler alterna=
tive to oauth-meta was already being discussed there in
 private, because then I would have had to talk about the security issues, =
which we=E2=80=99d decided not to publicly do at that point.=C2=A0 So I sta=
yed silent during the poll, out of politeness.=C2=A0 Perhaps I should have =
found a way to say something then anyway, but that=E2=80=99s
 water under the bridge now.


=C2=A0


Finally, for what it=E2=80=99s worth,=
 the HATEOAS stuff reminds me far too much of Web Services Description Lang=
uage (WSDL) =E2=80=93 part of the complexity baggage that helped
 sink Web Services.=C2=A0 The use of =E2=80=9Clink rel=E2=80=9D to define a=
n interaction vocabulary and publish endpoints for that vocabulary seems pr=
etty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=93 an=
other cute =E2=80=9CWebby=E2=80=9D innovation that never caught on.=C2=A0 T=
he industry has pretty
 much voted with its feet and is using JSON for publishing discovery data s=
tructures =E2=80=93 not =E2=80=9Clink rel=E2=80=9D.=C2=A0 I am against us r=
everting to the =E2=80=9Clink rel=E2=80=9D proposal from 2008 that never ca=
ught on when JSON is simpler and does a better job.

=C2=A0


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


=C2=A0


From: Nat Sakimura [mailto:sakimura@gmail.com]


Sent: Thursday, January 21, 2016 6:24 AM

To: Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>
Cc: William Denniss <wdenniss@google.com>; <oauth@ietf.org> <oauth@ietf.org>


Subject: Re: [OAUTH-WG] Call for Adoption


=C2=A0




Mike,=C2=A0




=C2=A0






You just criticize my draft. That's ok, but I wo=
uld really like to get some response to my questions stated in=C2=A0https://www.ietf.org/mail-archive/web/oauth/current/msg15483.=
html=C2=A0.
 To me, it just does not seem to work, and the combination of the oauth-met=
a and PKCE seems to be much more elegan, nicer, and much simpler to impleme=
nt. If you just give up the dynamic response at the authorization endpoint,=
 then you even do not have to touch
 the code but just change a config file.=C2=A0






=C2=A0






Please convince me by answering to my questions.=C2=
=A0






=C2=A0






For the record of Yokohama, I do not recall much abo=
ut duplication in OAuth session. The poll in the room was=C2=A019 for / zero against / 4 persons need mor=
e information. Indeed, it is not duplicating
 much. And if you move to a new model without pre-configured discovery, it =
is not duplicating any but the resource endpoint URI, which is optional and=
 is for the cases where the client did not know the concrete resource endpo=
int to start with.=C2=A0






=C2=A0






I unders=
tand your usecases always start from a concrete endpoint location. Mine do =
not. In a four party model, it is likely not. The user just want to have th=
e service to fetch his data from some
 resource endpoint. He just hits the service. He does not hit the resource =
endpoint directly. For example, in the case of a consumer using a personal =
finance platform (PFP)to manage his pension fund, he hits the PFP and not t=
he Pension fund. Assuming that the
 pension fund has delegated the authorization control to the authorization =
server, then, the authorization server should return both the access token =
and the endpoint of the pension fund so that the PFP can pull the data usin=
g them. A similar model holds for
 personal health service and health care providers.=C2=A0<=
/u>






=C2=A0






Best,=C2=
=A0






=C2=A0






Nat






=C2=A0






=C2=A0






2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
 21:18 Justin Richer <jricher@mit.edu>:








Convergence is exactly what I=E2=80=99m arguing for,=
 though. These things ought to work together.








=C2=A0






=C2=A0=E2=80=94 Justin










=C2=A0








On Jan 21, 2016, at 2:55 AM, Mike Jones <Michael.Jones@mic=
rosoft.com> wrote:




=C2=A0








My memory of the discussions of the o=
auth-meta draft in Yokohama were that many people felt that it
 was unnecessarily dynamically duplicating a lot of information that the cl=
ient already had.=C2=A0 Most of us that were aware of the attacks then were=
 in favor of a more targeted, minimal approach.=C2=A0 You were listened to =
in Yokohama, but that didn=E2=80=99t necessarily mean
 that people agreed with the approach.=C2=A0 Participants were already awar=
e of the oauth-meta proposal in Darmstadt but no one spoke up in favor of i=
t that I can recall.=C2=A0 Rather, I think people were thinking that =E2=80=
=9Cless is more=E2=80=9D.


=C2=A0


There have also been discussions in t=
he last day about how dynamically returning a resource URL, which
 oauth-meta does, is both unnecessary (since the client initiated the resou=
rce authorization already knowing what resource it wants to access) and oft=
en problematic, since many authorization servers can authorize access to mu=
ltiple resources.=C2=A0 If anything,
 the client should be telling the authorization server what resource it wan=
ts to access =E2=80=93 not the other way around.


=C2=A0


I=E2=80=99m not saying that there are=
n=E2=80=99t some good ideas in the oauth-meta draft =E2=80=93 I=E2=80=99m s=
ure there are, just
 as there are in the approach designed by the participants in Darmstadt.=C2=
=A0 While I volunteered to write the first draft of the mix-up-mitigation a=
pproach, it really reflects something a lot of people have already bought i=
nto =E2=80=93 as evidenced in the passion in
 the high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D threa=
d, and not just my personal project.


=C2=A0


If you think there are things missing=
 or wrong in the mix-up-mitigation draft, please say what they
 are.=C2=A0 That will help us quickly converge on a solution that will work=
 for everyone.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Sincerely,


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


=C2=A0

From: Nat Sakimura [mailto:sakimura@gmail.com]


Sent: Wednesday, January 20, 2016 11:17 PM

To: Mike Jones <Michael.Jones@microsoft.com>; William Denniss <wdenniss@google.com<=
/a>>; Justin Richer <jricher@mit.edu>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Call for Adoption


=C2=A0




Hi Mike.=C2=A0




=C2=A0






Conversely, I would like to ask why this approach do=
es not work for Mix-up attack.=C2=A0As Nov stated, we in fact have discusse=
d the approach in quite a length back in Yokohama. I really
 would like to know why it does not work.=C2=A0






=C2=A0






Besides, for oauth-meta approach, mix-up attack is o=
nly one of the thing it solves.=C2=A0






=C2=A0






Nat Sakimura






=C2=A0






2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
 16:02 Mike Jones <Michael.Jones@microsoft.com>:










Not to be negative, but I disagree wi=
th adopting draft-sakimura-oauth-meta.=C2=A0 We should define and promote
 one mitigation approach to the mix-up attacks.=C2=A0 Having two would conf=
use implementers and cause compatibility problems =E2=80=93 reducing overal=
l security.


=C2=A0


The approach defined in draft-jones-o=
auth-mix-up-mitigation was created in collaboration with the security
 researchers who identified the problems in the first place, was vigorously=
 discussed in the security meeting Hannes and Torsten held in Darmstadt, an=
d has been since refined based on substantial input from the working group.=
=C2=A0 And at least three implementers
 have already stated that they=E2=80=99ve implemented it.=C2=A0 I=E2=80=99m=
 not saying that it=E2=80=99s, but if there are things missing or things th=
at need to be improved in our approach, we should do it there, rather intro=
ducing a competing approach.


=C2=A0


Also, standard OAuth deployments regi=
ster the client and then use the information gathered at registration
 time for subsequent protocol interactions.=C2=A0 They do not need all the =
configuration information for the authorization server to be retransmitted =
at runtime.=C2=A0 The oauth-meta draft goes too far in that direction, at l=
east as I see it.=C2=A0 Returning things two ways
 creates its own problems, as discussed in the Duplicate Information Attack=
s security considerations section (7.2) of the mix-up-mitigation draft.


=C2=A0


I=E2=80=99ll note that the mix-up-mit=
igation approach is compatible with existing practice in both static and
 dynamic metadata discovery.=C2=A0 Replying to Justin=E2=80=99s comment tha=
t =E2=80=9CIt's the pre-configured discovery document that's=
 at the root of the mix-up attack in the first place=E2=80=
=9D =E2=80=93 this
 is not the case.=C2=A0 The attacks can be performed without either discove=
ry or dynamic registration.


=C2=A0


I would be interested in hearing a te=
chnical discussion on whether there are aspects of the oauth-meta
 approach that mitigate aspects of the attacks that the mix-up-mitigation a=
pproach does not.=C2=A0 That could help inform whether there are additional=
 things we should add to or change in the mix-up draft.


=C2=A0


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


=C2=A0

From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of William Denniss

Sent: Wednesday, January 20, 2016 10:37 PM

To: Justin Richer <jricher@mit.edu>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Call for Adoption










=C2=A0




+1 to adopt this, and I agree with Justin's comm=
ents.




=C2=A0




On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer <<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>=
 wrote:






+1



Inline discovery and pre-configured discovery (ie, .well-known) should at t=
he very least be compatible and developed together. It's the pre-config=
ured discovery document that's at the root of the mix-up attack in the =
first place.



=C2=A0-- Justin






=C2=A0<=
/p>



On 1/19/2016 10:30 PM, Nat Sakimura wrote:=









Just to give more context, at IETF 94, I have done a=
 presentation on discovery.=C2=A0





=C2=A0






According to the minutes,=C2=A0






=C2=A0






=C2=A0=C2=A0=C2=A0 (f) Discovery (Nat)=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Nat explains his document as an e=
xample of the work that has to be done


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the area of discovery, which is a t=
opic that has been identified


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as necessary for interoperability sinc=
e many years but so far there


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was not time to work on it. Mike, John=
 and Nat are working on a new


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document that describes additional dis=
covery-relevant components.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Poll: 19 for / zero against / 4 p=
ersons need more information.


=C2=A0


The document discussed there was

https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a sim=
ple (only 1-page!) but a very powerful document that nudges towards HATEOAS=
 which is at the core of RESTful-ness. It also mitigates the Mix-up attack =
without introducing the concept
 of issuer which is not in RFC6749. It is also good for selecting different=
 endpoints depending on the user authentication and authorization results a=
nd more privacy sensitive than pre-announced Discovery document. It also al=
lows you to find to which protected
 resource endpoint you can use the access token against.=C2=A0






=C2=A0




In the last sentence of the minutes, it talks about =
"a new document that describes additional discovery-relevant component=
s". This is=C2=A0https://tools.ietf.org/html/draft-jones=
-oauth-discovery-00.=C2=A0
 It went for the call for adoption. However, it is only a half of the story=
. I believe=C2=A0https://tools.ietf.org/html/draft-sakimura-oau=
th-meta-05=C2=A0that was discussed at IETF
 94 and had support there=C2=A0should be adopted as well.=C2=A0 <=
/u>




=C2=A0






Nat Sakimura




=C2=A0






=C2=A0






=C2=A0








=C2=A0






2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4)
 12:05 Nat Sakimura <sakimura@gmail.com>:








Thanks Hannes.=C2=A0





=C2=A0






I did not find=C2=A0https://tools.ietf.o=
rg/html/draft-sakimura-oauth-meta-05,=C2=A0which was discussed
 in Yokohama, and was largely in agreement if my recollection is correct. W=
hy is it not in the call for adoption?=C2=A0






=C2=A0






=C2=A0






=C2=A0






2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB)
 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:










Hi all,



we have submitted our new charter to the IESG (see

http://www.ietf.org/mail-archive/web/oauth/current/msg1=
5379.html) and

since some IESG members like to see an updated list of milestones as

well. For this reason, based on a suggestion from Barry, we are also

starting a call for adoption concurrently with the review of the charter
text by the IESG.



We will post separate mails on the individual documents. Your feedback

is important! Please take the time to look at the documents and provide

your feedback.



Ciao

Hannes & Derek



_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth










=C2=A0<=
/p>

_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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




=C2=A0










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth






=C2=A0










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth
















=C2=A0












--001a113a7e3caed6010529e2b098--


From nobody Thu Jan 21 18:11:39 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 352651B3612 for ; Thu, 21 Jan 2016 18:11:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level: 
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgo8g1bDabIu for ; Thu, 21 Jan 2016 18:11:33 -0800 (PST)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::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 DFCB11B3607 for ; Thu, 21 Jan 2016 18:11:32 -0800 (PST)
Received: by mail-ob0-x22b.google.com with SMTP id is5so51543697obc.0 for ; Thu, 21 Jan 2016 18:11:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jdeRd+UNkf/F4b68VselJnEBWQhSET7Xt+C3s9mZW0A=; b=F7ZmZmDCMmHQG6ZIiK7eHp+Sp3fZ+nuwX7C6eGfWodt1SO3XEivWG0ZTCUJpG05Xte lQLJq0ZVErVsbbLxYmO4AB3LNTjJQz9sEFw60JgzYf3Da/aiXnQvVyG4XzMKD8RFBxah n51NMNIu5Gl5bF+ciPrvEHDxNz2pGYykIjYGAxa9+9q6Plg2iqC/yZ1KS3ReTSGdqF47 17DwpKmKrLkVlZvotXX7fJsv+64ynck992b+TU4og8NC+9wk5knC5+f8hdzVBF0H6Hai USVrHp3rwezz0ESN+RQS1cxcGm90QASAWf5jLpu1mdWRByThlK7Ip7bPlVKW3Fel8wGh OHRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jdeRd+UNkf/F4b68VselJnEBWQhSET7Xt+C3s9mZW0A=; b=c14140+jfa1t5gXELpqNyYQeR7knKLlhBPcyXZf8dW3M/ErTvW/BLh5jSpcZ5VGIzY ChtslLQ1QxjUYyzrSdROPvRhWHfrIMsUhZKM+S43g3822tYoWA/M/4lxxNn9R5hhKQ/f zzOkLS8x5d+N33iEHimaz7y5akYxkOn8HkPx7BgHU5eYbfxdJdeqmKPVG2i3GrGBW6w9 95DUF30o+OtGH3gk0XkpjbJsLfMO3BSkmOS1xfcxdBkV49xr4hBA4AGWcK6z0l+85nnF YJ7Z9gpcQXyM5okeuX6peG5CsbMLsHM5ObGZgwS6Wd26cGHTBnx+6lUU8X0Hnl/377uh b0rw==
X-Gm-Message-State: AG10YOTMxIx7E2JxDMArrWsPkY/FQEUsb2E5eTfQNZS/IHnNut9r7HPBXMNGMEKWuAyFA4ISYRYyu5OoZaqadg0c
X-Received: by 10.60.67.34 with SMTP id k2mr368906oet.67.1453428692021; Thu, 21 Jan 2016 18:11:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.227.39 with HTTP; Thu, 21 Jan 2016 18:11:12 -0800 (PST)
In-Reply-To: 
References: <569E2076.2090405@gmx.net>   <569F915D.8020806@mit.edu>       
From: William Denniss 
Date: Fri, 22 Jan 2016 10:11:12 +0800
Message-ID: 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=001a11c2e298e555280529e2bce2
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 02:11:38 -0000

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

These params could also be part of the OAuth2 JSON response payload.
Perhaps we should evaluate the concept of incremental discovery and how
it's delivered separately?

Also, discovery does not solve the question of authorization-grant specific
RS endpoint metadata.

On Fri, Jan 22, 2016 at 9:34 AM, Mike Jones 
wrote:

> Nat, I=E2=80=99m confused by this statement in the message you reference =
=E2=80=9CUnfortunately,
> this does not match the value of OAuth issuer defined in Section 2
> of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as
> specified in 3.1. As such, validation as specified in bullet 1 of Section=
 4
> fails in Google's case -- OR it means that the document is internally
> inconsistent.=E2=80=9D.  The issuer definition in draft-jones-oauth-disco=
very is
> 100% compatible with the one in OpenID Connect Discovery, by design.  In
> the Google example, both the OpenID issuer and the OAuth issuer values
> would be the string =E2=80=9Chttps://accounts.google.com=E2=80=9D.  What =
is the
> inconsistency that you perceive?
>
>
>
> The discussion of the duplication problem happened in the private meeting=
s
> in Yokohama.
>
>
>
> I will admit, in Yokohama, I didn=E2=80=99t speak up in the public meetin=
gs to
> point out that a simpler alternative to oauth-meta was already being
> discussed there in private, because then I would have had to talk about t=
he
> security issues, which we=E2=80=99d decided not to publicly do at that po=
int.  So I
> stayed silent during the poll, out of politeness.  Perhaps I should have
> found a way to say something then anyway, but that=E2=80=99s water under =
the bridge
> now.
>
>
>
> Finally, for what it=E2=80=99s worth, the HATEOAS stuff reminds me far to=
o much of
> Web Services Description Language (WSDL) =E2=80=93 part of the complexity=
 baggage
> that helped sink Web Services.  The use of =E2=80=9Clink rel=E2=80=9D to =
define an
> interaction vocabulary and publish endpoints for that vocabulary seems
> pretty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=
=93 another cute =E2=80=9CWebby=E2=80=9D
> innovation that never caught on.  The industry has pretty much voted with
> its feet and is using JSON for publishing discovery data structures =E2=
=80=93 not
> =E2=80=9Clink rel=E2=80=9D.  I am against us reverting to the =E2=80=9Cli=
nk rel=E2=80=9D proposal from 2008
> that never caught on when JSON is simpler and does a better job.
>
>
>
>                                                                 -- Mike
>
>
>
> *From:* Nat Sakimura [mailto:sakimura@gmail.com]
> *Sent:* Thursday, January 21, 2016 6:24 AM
> *To:* Justin Richer ; Mike Jones <
> Michael.Jones@microsoft.com>
> *Cc:* William Denniss ;  <
> oauth@ietf.org>
>
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>
> Mike,
>
>
>
> You just criticize my draft. That's ok, but I would really like to get
> some response to my questions stated in
> https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To
> me, it just does not seem to work, and the combination of the oauth-meta
> and PKCE seems to be much more elegan, nicer, and much simpler to
> implement. If you just give up the dynamic response at the authorization
> endpoint, then you even do not have to touch the code but just change a
> config file.
>
>
>
> Please convince me by answering to my questions.
>
>
>
> For the record of Yokohama, I do not recall much about duplication in
> OAuth session. The poll in the room was 19 for / zero against / 4 persons
> need more information. Indeed, it is not duplicating much. And if you mov=
e
> to a new model without pre-configured discovery, it is not duplicating an=
y
> but the resource endpoint URI, which is optional and is for the cases whe=
re
> the client did not know the concrete resource endpoint to start with.
>
>
>
> I understand your usecases always start from a concrete endpoint location=
.
> Mine do not. In a four party model, it is likely not. The user just want =
to
> have the service to fetch his data from some resource endpoint. He just
> hits the service. He does not hit the resource endpoint directly. For
> example, in the case of a consumer using a personal finance platform
> (PFP)to manage his pension fund, he hits the PFP and not the Pension fund=
.
> Assuming that the pension fund has delegated the authorization control to
> the authorization server, then, the authorization server should return bo=
th
> the access token and the endpoint of the pension fund so that the PFP can
> pull the data using them. A similar model holds for personal health servi=
ce
> and health care providers.
>
>
>
> Best,
>
>
>
> Nat
>
>
>
>
>
> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 21:18 Justin Richer :
>
> Convergence is exactly what I=E2=80=99m arguing for, though. These things=
 ought to
> work together.
>
>
>
>  =E2=80=94 Justin
>
>
>
> On Jan 21, 2016, at 2:55 AM, Mike Jones 
> wrote:
>
>
>
> My memory of the discussions of the oauth-meta draft in Yokohama were tha=
t
> many people felt that it was unnecessarily dynamically duplicating a lot =
of
> information that the client already had.  Most of us that were aware of t=
he
> attacks then were in favor of a more targeted, minimal approach.  You wer=
e
> listened to in Yokohama, but that didn=E2=80=99t necessarily mean that pe=
ople
> agreed with the approach.  Participants were already aware of the
> oauth-meta proposal in Darmstadt but no one spoke up in favor of it that =
I
> can recall.  Rather, I think people were thinking that =E2=80=9Cless is m=
ore=E2=80=9D.
>
>
>
> There have also been discussions in the last day about how dynamically
> returning a resource URL, which oauth-meta does, is both unnecessary (sin=
ce
> the client initiated the resource authorization already knowing what
> resource it wants to access) and often problematic, since many
> authorization servers can authorize access to multiple resources.  If
> anything, the client should be telling the authorization server what
> resource it wants to access =E2=80=93 not the other way around.
>
>
>
> I=E2=80=99m not saying that there aren=E2=80=99t some good ideas in the o=
auth-meta draft =E2=80=93
> I=E2=80=99m sure there are, just as there are in the approach designed by=
 the
> participants in Darmstadt.  While I volunteered to write the first draft =
of
> the mix-up-mitigation approach, it really reflects something a lot of
> people have already bought into =E2=80=93 as evidenced in the passion in =
the
> high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D thread, =
and not just my
> personal project.
>
>
>
> If you think there are things missing or wrong in the mix-up-mitigation
> draft, please say what they are.  That will help us quickly converge on a
> solution that will work for everyone.
>
>
>
>                                                           Sincerely,
>
>                                                           -- Mike
>
>
>
> *From:* Nat Sakimura [mailto:sakimura@gmail.com ]
> *Sent:* Wednesday, January 20, 2016 11:17 PM
> *To:* Mike Jones ; William Denniss <
> wdenniss@google.com>; Justin Richer 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>
> Hi Mike.
>
>
>
> Conversely, I would like to ask why this approach does not work for Mix-u=
p
> attack. As Nov stated, we in fact have discussed the approach in quite a
> length back in Yokohama. I really would like to know why it does not work=
.
>
>
>
> Besides, for oauth-meta approach, mix-up attack is only one of the thing
> it solves.
>
>
>
> Nat Sakimura
>
>
>
> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones :
>
> Not to be negative, but I disagree with adopting
> draft-sakimura-oauth-meta.  We should define and promote one mitigation
> approach to the mix-up attacks.  Having two would confuse implementers an=
d
> cause compatibility problems =E2=80=93 reducing overall security.
>
>
>
> The approach defined in draft-jones-oauth-mix-up-mitigation was created i=
n
> collaboration with the security researchers who identified the problems i=
n
> the first place, was vigorously discussed in the security meeting Hannes
> and Torsten held in Darmstadt, and has been since refined based on
> substantial input from the working group.  And at least three implementer=
s
> have already stated that they=E2=80=99ve implemented it.  I=E2=80=99m not=
 saying that it=E2=80=99s,
> but if there are things missing or things that need to be improved in our
> approach, we should do it there, rather introducing a competing approach.
>
>
>
> Also, standard OAuth deployments register the client and then use the
> information gathered at registration time for subsequent protocol
> interactions.  They do not need all the configuration information for the
> authorization server to be retransmitted at runtime.  The oauth-meta draf=
t
> goes too far in that direction, at least as I see it.  Returning things t=
wo
> ways creates its own problems, as discussed in the Duplicate Information
> Attacks security considerations section (7.2) of the mix-up-mitigation
> draft.
>
>
>
> I=E2=80=99ll note that the mix-up-mitigation approach is compatible with =
existing
> practice in both static and dynamic metadata discovery.  Replying to
> Justin=E2=80=99s comment that =E2=80=9CIt's the pre-configured discovery =
document that's
> at the root of the mix-up attack in the first place=E2=80=9D =E2=80=93 th=
is is not the
> case.  The attacks can be performed without either discovery or dynamic
> registration.
>
>
>
> I would be interested in hearing a technical discussion on whether there
> are aspects of the oauth-meta approach that mitigate aspects of the attac=
ks
> that the mix-up-mitigation approach does not.  That could help inform
> whether there are additional things we should add to or change in the
> mix-up draft.
>
>
>
>                                                           -- Mike
>
>
>
> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William
> Denniss
> *Sent:* Wednesday, January 20, 2016 10:37 PM
> *To:* Justin Richer 
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Call for Adoption
>
>
>
> +1 to adopt this, and I agree with Justin's comments.
>
>
>
> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer  wrote:
>
> +1
>
> Inline discovery and pre-configured discovery (ie, .well-known) should at
> the very least be compatible and developed together. It's the
> pre-configured discovery document that's at the root of the mix-up attack
> in the first place.
>
>  -- Justin
>
>
>
> On 1/19/2016 10:30 PM, Nat Sakimura wrote:
>
> Just to give more context, at IETF 94, I have done a presentation on
> discovery.
>
>
>
> According to the minutes,
>
>
>
>     (f) Discovery (Nat)
>
>
>
>              Nat explains his document as an example of the work that has=
 to be done
>
>              in the area of discovery, which is a topic that has been ide=
ntified
>
>              as necessary for interoperability since many years but so fa=
r there
>
>              was not time to work on it. Mike, John and Nat are working o=
n a new
>
>              document that describes additional discovery-relevant compon=
ents.
>
>
>
>              Poll: 19 for / zero against / 4 persons need more informatio=
n.
>
>
>
> The document discussed there was
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
> simple (only 1-page!) but a very powerful document that nudges towards
> HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-u=
p
> attack without introducing the concept of issuer which is not in RFC6749.
> It is also good for selecting different endpoints depending on the user
> authentication and authorization results and more privacy sensitive than
> pre-announced Discovery document. It also allows you to find to which
> protected resource endpoint you can use the access token against.
>
>
>
> In the last sentence of the minutes, it talks about "a new document that
> describes additional discovery-relevant components". This is
> https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went for
> the call for adoption. However, it is only a half of the story. I believe
> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was
> discussed at IETF 94 and had support there should be adopted as well.
>
>
>
> Nat Sakimura
>
>
>
>
>
>
>
>
>
> 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura :
>
> Thanks Hannes.
>
>
>
> I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05, =
which
> was discussed in Yokohama, and was largely in agreement if my recollectio=
n
> is correct. Why is it not in the call for adoption?
>
>
>
>
>
>
>
> 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig :
>
> Hi all,
>
> we have submitted our new charter to the IESG (see
> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
> since some IESG members like to see an updated list of milestones as
> well. For this reason, based on a suggestion from Barry, we are also
> starting a call for adoption concurrently with the review of the charter
> text by the IESG.
>
> We will post separate mails on the individual documents. Your feedback
> is important! Please take the time to look at the documents and provide
> your feedback.
>
> Ciao
> Hannes & Derek
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>

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


These params could also be part of the OAuth2 JSON respons=
e payload. Perhaps we should evaluate the concept of incremental discovery =
and how it's delivered separately?

Also, discovery d=
oes not solve the question of authorization-grant specific RS endpoint meta=
data.

=
On Fri, Jan 22, 2016 at 9:34 AM, Mike Jones <Michael.Jones@mic=
rosoft.com> wrote:











Nat, I=E2=80=99m confused by this sta=
tement in the message you reference =E2=80=9CUnfortunately, this does not match the value
 of OAuth issuer defined in Section 2 of=C2=A0draft-jones-oauth-mix-up-miti=
gation-01 nor the 'iss' returned as specified in 3.1.=C2=A0As such,=
 validation as specified in bullet 1 of Section 4 fails in Google's cas=
e -- OR it means that the document is internally inconsistent.=E2=80=9D.=C2=A0
 The issuer definition in draft-jones-oauth-discovery is 100% compatible wi=
th the one in OpenID Connect Discovery, by design.=C2=A0 In the Google exam=
ple, both the OpenID issuer and the OAuth issuer values would be the string=
 =E2=80=9Chttps:/=
/accounts.google.com=E2=80=9D.=C2=A0 What
 is the inconsistency that you perceive?


=C2=A0


The discussion of the duplication pro=
blem happened in the private meetings in Yokohama.


=C2=A0


I will admit, in Yokohama, I didn=E2=
=80=99t speak up in the public meetings to point out that a simpler alterna=
tive to oauth-meta was already being discussed there in
 private, because then I would have had to talk about the security issues, =
which we=E2=80=99d decided not to publicly do at that point.=C2=A0 So I sta=
yed silent during the poll, out of politeness.=C2=A0 Perhaps I should have =
found a way to say something then anyway, but that=E2=80=99s
 water under the bridge now.


=C2=A0


Finally, for what it=E2=80=99s worth,=
 the HATEOAS stuff reminds me far too much of Web Services Description Lang=
uage (WSDL) =E2=80=93 part of the complexity baggage that helped
 sink Web Services.=C2=A0 The use of =E2=80=9Clink rel=E2=80=9D to define a=
n interaction vocabulary and publish endpoints for that vocabulary seems pr=
etty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=93 an=
other cute =E2=80=9CWebby=E2=80=9D innovation that never caught on.=C2=A0 T=
he industry has pretty
 much voted with its feet and is using JSON for publishing discovery data s=
tructures =E2=80=93 not =E2=80=9Clink rel=E2=80=9D.=C2=A0 I am against us r=
everting to the =E2=80=9Clink rel=E2=80=9D proposal from 2008 that never ca=
ught on when JSON is simpler and does a better job.

=C2=A0


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


=C2=A0


From: Nat Sakimura [mailto:sakimura@gmail.com]


Sent: Thursday, January 21, 2016 6:24 AM

To: Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>
Cc: William Denniss <wdenniss@google.com>; <oauth@ietf.org> <oauth@ietf.org>


Subject: Re: [OAUTH-WG] Call for Adoption
<=
p>


=C2=A0




Mike,=C2=A0




=C2=A0






You just criticize my draft. That's ok, but I wo=
uld really like to get some response to my questions stated in=C2=A0https://www.ietf.org/mail-archive/web/oauth/current/msg15483.=
html=C2=A0.
 To me, it just does not seem to work, and the combination of the oauth-met=
a and PKCE seems to be much more elegan, nicer, and much simpler to impleme=
nt. If you just give up the dynamic response at the authorization endpoint,=
 then you even do not have to touch
 the code but just change a config file.=C2=A0






=C2=A0






Please convince me by answering to my questions.=C2=
=A0






=C2=A0






For the record of Yokohama, I do not recall much abo=
ut duplication in OAuth session. The poll in the room was=C2=A019 for / zero against / 4 persons need mor=
e information. Indeed, it is not duplicating
 much. And if you move to a new model without pre-configured discovery, it =
is not duplicating any but the resource endpoint URI, which is optional and=
 is for the cases where the client did not know the concrete resource endpo=
int to start with.=C2=A0






=C2=A0






I unders=
tand your usecases always start from a concrete endpoint location. Mine do =
not. In a four party model, it is likely not. The user just want to have th=
e service to fetch his data from some
 resource endpoint. He just hits the service. He does not hit the resource =
endpoint directly. For example, in the case of a consumer using a personal =
finance platform (PFP)to manage his pension fund, he hits the PFP and not t=
he Pension fund. Assuming that the
 pension fund has delegated the authorization control to the authorization =
server, then, the authorization server should return both the access token =
and the endpoint of the pension fund so that the PFP can pull the data usin=
g them. A similar model holds for
 personal health service and health care providers.=C2=A0<=
/u>






=C2=A0






Best,=C2=
=A0






=C2=A0






Nat






=C2=A0






=C2=A0






2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
 21:18 Justin Richer <jricher@mit.edu>:








Convergence is exactly what I=E2=80=99m arguing for,=
 though. These things ought to work together.








=C2=A0






=C2=A0=E2=80=94 Justin










=C2=A0








On Jan 21, 2016, at 2:55 AM, Mike Jones <Michael.Jones@mic=
rosoft.com> wrote:




=C2=A0








My memory of the discussions of the o=
auth-meta draft in Yokohama were that many people felt that it
 was unnecessarily dynamically duplicating a lot of information that the cl=
ient already had.=C2=A0 Most of us that were aware of the attacks then were=
 in favor of a more targeted, minimal approach.=C2=A0 You were listened to =
in Yokohama, but that didn=E2=80=99t necessarily mean
 that people agreed with the approach.=C2=A0 Participants were already awar=
e of the oauth-meta proposal in Darmstadt but no one spoke up in favor of i=
t that I can recall.=C2=A0 Rather, I think people were thinking that =E2=80=
=9Cless is more=E2=80=9D.


=C2=A0


There have also been discussions in t=
he last day about how dynamically returning a resource URL, which
 oauth-meta does, is both unnecessary (since the client initiated the resou=
rce authorization already knowing what resource it wants to access) and oft=
en problematic, since many authorization servers can authorize access to mu=
ltiple resources.=C2=A0 If anything,
 the client should be telling the authorization server what resource it wan=
ts to access =E2=80=93 not the other way around.


=C2=A0


I=E2=80=99m not saying that there are=
n=E2=80=99t some good ideas in the oauth-meta draft =E2=80=93 I=E2=80=99m s=
ure there are, just
 as there are in the approach designed by the participants in Darmstadt.=C2=
=A0 While I volunteered to write the first draft of the mix-up-mitigation a=
pproach, it really reflects something a lot of people have already bought i=
nto =E2=80=93 as evidenced in the passion in
 the high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D threa=
d, and not just my personal project.


=C2=A0


If you think there are things missing=
 or wrong in the mix-up-mitigation draft, please say what they
 are.=C2=A0 That will help us quickly converge on a solution that will work=
 for everyone.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Sincerely,


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


=C2=A0


From: Nat Sakimura [mailto:sakimura@gmail.com]


Sent: Wednesday, January 20, 2016 11:17 PM

To: Mike Jones <Michael.Jones@microsoft.com>; William Denniss <wdenniss@google.com<=
/a>>; Justin Richer <jricher@mit.edu>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Call for Adoption


=C2=A0




Hi Mike.=C2=A0




=C2=A0






Conversely, I would like to ask why this approach do=
es not work for Mix-up attack.=C2=A0As Nov stated, we in fact have discusse=
d the approach in quite a length back in Yokohama. I really
 would like to know why it does not work.=C2=A0






=C2=A0






Besides, for oauth-meta approach, mix-up attack is o=
nly one of the thing it solves.=C2=A0






=C2=A0






Nat Sakimura






=C2=A0






2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
 16:02 Mike Jones <Michael.Jones@microsoft.com>:










Not to be negative, but I disagree wi=
th adopting draft-sakimura-oauth-meta.=C2=A0 We should define and promote
 one mitigation approach to the mix-up attacks.=C2=A0 Having two would conf=
use implementers and cause compatibility problems =E2=80=93 reducing overal=
l security.


=C2=A0


The approach defined in draft-jones-o=
auth-mix-up-mitigation was created in collaboration with the security
 researchers who identified the problems in the first place, was vigorously=
 discussed in the security meeting Hannes and Torsten held in Darmstadt, an=
d has been since refined based on substantial input from the working group.=
=C2=A0 And at least three implementers
 have already stated that they=E2=80=99ve implemented it.=C2=A0 I=E2=80=99m=
 not saying that it=E2=80=99s, but if there are things missing or things th=
at need to be improved in our approach, we should do it there, rather intro=
ducing a competing approach.


=C2=A0


Also, standard OAuth deployments regi=
ster the client and then use the information gathered at registration
 time for subsequent protocol interactions.=C2=A0 They do not need all the =
configuration information for the authorization server to be retransmitted =
at runtime.=C2=A0 The oauth-meta draft goes too far in that direction, at l=
east as I see it.=C2=A0 Returning things two ways
 creates its own problems, as discussed in the Duplicate Information Attack=
s security considerations section (7.2) of the mix-up-mitigation draft.


=C2=A0


I=E2=80=99ll note that the mix-up-mit=
igation approach is compatible with existing practice in both static and
 dynamic metadata discovery.=C2=A0 Replying to Justin=E2=80=99s comment tha=
t =E2=80=9CIt's the pre-configured discovery document that's=
 at the root of the mix-up attack in the first place=E2=80=
=9D =E2=80=93 this
 is not the case.=C2=A0 The attacks can be performed without either discove=
ry or dynamic registration.


=C2=A0


I would be interested in hearing a te=
chnical discussion on whether there are aspects of the oauth-meta
 approach that mitigate aspects of the attacks that the mix-up-mitigation a=
pproach does not.=C2=A0 That could help inform whether there are additional=
 things we should add to or change in the mix-up draft.


=C2=A0


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


=C2=A0


From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of William Denniss

Sent: Wednesday, January 20, 2016 10:37 PM

To: Justin Richer <jricher@mit.edu>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Call for Adoption










=C2=A0




+1 to adopt this, and I agree with Justin's comm=
ents.




=C2=A0




On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer <<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>=
 wrote:






+1



Inline discovery and pre-configured discovery (ie, .well-known) should at t=
he very least be compatible and developed together. It's the pre-config=
ured discovery document that's at the root of the mix-up attack in the =
first place.



=C2=A0-- Justin






=C2=A0<=
/p>



On 1/19/2016 10:30 PM, Nat Sakimura wrote:=









Just to give more context, at IETF 94, I have done a=
 presentation on discovery.=C2=A0





=C2=A0






According to the minutes,=C2=A0






=C2=A0






=C2=A0=C2=A0=C2=A0 (f) Discovery (Nat)=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Nat explains his document as an e=
xample of the work that has to be done


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the area of discovery, which is a t=
opic that has been identified


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as necessary for interoperability sinc=
e many years but so far there


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was not time to work on it. Mike, John=
 and Nat are working on a new


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document that describes additional dis=
covery-relevant components.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Poll: 19 for / zero against / 4 p=
ersons need more information.


=C2=A0


The document discussed there was

https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a sim=
ple (only 1-page!) but a very powerful document that nudges towards HATEOAS=
 which is at the core of RESTful-ness. It also mitigates the Mix-up attack =
without introducing the concept
 of issuer which is not in RFC6749. It is also good for selecting different=
 endpoints depending on the user authentication and authorization results a=
nd more privacy sensitive than pre-announced Discovery document. It also al=
lows you to find to which protected
 resource endpoint you can use the access token against.=C2=A0






=C2=A0




In the last sentence of the minutes, it talks about =
"a new document that describes additional discovery-relevant component=
s". This is=C2=A0https://tools.ietf.org/html/draft-jones=
-oauth-discovery-00.=C2=A0
 It went for the call for adoption. However, it is only a half of the story=
. I believe=C2=A0https://tools.ietf.org/html/draft-sakimura-oau=
th-meta-05=C2=A0that was discussed at IETF
 94 and had support there=C2=A0should be adopted as well.=C2=A0 <=
/u>




=C2=A0






Nat Sakimura




=C2=A0






=C2=A0






=C2=A0








=C2=A0






2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4)
 12:05 Nat Sakimura <sakimura@gmail.com>:








Thanks Hannes.=C2=A0





=C2=A0






I did not find=C2=A0https://tools.ietf.o=
rg/html/draft-sakimura-oauth-meta-05,=C2=A0which was discussed
 in Yokohama, and was largely in agreement if my recollection is correct. W=
hy is it not in the call for adoption?=C2=A0






=C2=A0






=C2=A0






=C2=A0






2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB)
 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:










Hi all,



we have submitted our new charter to the IESG (see

http://www.ietf.org/mail-archive/web/oauth/current/msg1=
5379.html) and

since some IESG members like to see an updated list of milestones as

well. For this reason, based on a suggestion from Barry, we are also

starting a call for adoption concurrently with the review of the charter
text by the IESG.



We will post separate mails on the individual documents. Your feedback

is important! Please take the time to look at the documents and provide

your feedback.



Ciao

Hannes & Derek



_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth










=C2=A0<=
/p>

_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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




=C2=A0










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth






=C2=A0










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth
















=C2=A0


















--001a11c2e298e555280529e2bce2--


From nobody Thu Jan 21 18:25:49 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296D71B365C for ; Thu, 21 Jan 2016 18:25:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5hMcKgPb0pa for ; Thu, 21 Jan 2016 18:25:41 -0800 (PST)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DB841B3659 for ; Thu, 21 Jan 2016 18:25:41 -0800 (PST)
Received: by mail-qk0-x22c.google.com with SMTP id s68so23853770qkh.3 for ; Thu, 21 Jan 2016 18:25:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=GGM0o4YxHx95GUNNcwH4rVAT9MQ1LivSB984jPl0G00=; b=XkusDrFa83TrwbtxeAJoi7y95i/jNdsx4FOJfPHdfJPIOhvhDnFb0O6CsesLcc/Gr8 GY2/SARq8qeSOZyVvBvP3AtLsOXST/xnR1Yq0/lyCTcQV116wzU+PJ0jt0qCUInrAgYa SUgdY54IA9WBwzj72ivQ5sXidfin5XJzBjmXm+pdqZWtY42PS3uUqO9KPAPgAHFC+I5N VZ9HnKS2IdmcUrULL5H3pumRfiRY0oPUDDKZPVrwsRTueSB90j4XT9uclYvsxq+klil0 87FLHfdPE+jKiD11TnLBkIZ3SOrOO/811TYJFWQiHjVsHSu+zIMj+oxh7/eBmz0Cidvk h1Yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=GGM0o4YxHx95GUNNcwH4rVAT9MQ1LivSB984jPl0G00=; b=TM7z1Lxz3mQcYS6xnehFGRLKHP1gIRoWEfNiVNZYl5QrXvKNtlzaQfgJK7YdqnOek4 NyWEjRhUqFzQ4QNI3fOoiMmpb5ODU4TZQBgCduV72Xv15zrnCvSBwFaEECzBd3gu5f5z Khe29ZPOo/rslfMEGYxeUx4CHfOpeIhrPItwoO7C/HyZEx/D1bfT8JQAzl2xxXijS1Zr U0HMex4Nj5SeIeMurQ8EjTRjloFYQD3hfaB+DGMKW+r5MHLQb+fOMaINUb20QZqPNr54 YwBaTN6dkTsfZu/+NJDT1wreqrpSTJCpTsOoV4+uwlNvFq5FmF6DF+QP0mXIzsPqzHSP Yoew==
X-Gm-Message-State: AG10YOT+fR28UxsgL25i4+ABwJhlWefkDpYPpG4QLWtrz1bpjGFEzlTyf6rBm2vBktDmX1T5C2cDPU031bLxyw==
X-Received: by 10.55.78.207 with SMTP id c198mr698072qkb.34.1453429540470; Thu, 21 Jan 2016 18:25:40 -0800 (PST)
MIME-Version: 1.0
References: <569E2076.2090405@gmx.net>   <569F915D.8020806@mit.edu>        
In-Reply-To: 
From: Nat Sakimura 
Date: Fri, 22 Jan 2016 02:25:31 +0000
Message-ID: 
To: William Denniss , Mike Jones 
Content-Type: multipart/alternative; boundary=001a114a7c9c776ad40529e2ef03
Archived-At: 
Cc: "" 
Subject: Re: [OAUTH-WG] Call for Adoption
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 02:25:47 -0000

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

Right. OAuth-meta is not only for this particular attack. It actually
predates the attack by three years. It just happens to mitigate the attack
because it is addressing the root issue of decoupled data and meta-data
problem.

Re: returning as part of JSON payload, my earlier draft actually contained
a way to return the metadata within JSON (see
https://tools.ietf.org/html/draft-sakimura-oauth-meta-04). RFC5988 works as
long as we are using HTTPS, but once we get to other protocols, it does
not. So we need a way to represent it in native JSON. Swagger is using JSON
Schema way of it. I slightly prefer HAL way of it as you can leverage on
the JSON parser directly, making the code shorter, but I am fine either
way. I removed all those staff from OAuth-meta because that's not oauth
specific, but if people wants it, I can always bring it back.

Also, +1 for your point on "discovery does not solve the question of
authorization-grant specific RS endpoint metadata."

When I gave the idea back in 2012 in the work group meeting, a lot of
people said YES, but we needed complete other stuff and this thing has been
sitting there for 3 years now. IMHO, it should be adopted as a WG item now.
It will save a lot of headache down the road.

Nat

2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 11:11 William Denniss :

> These params could also be part of the OAuth2 JSON response payload.
> Perhaps we should evaluate the concept of incremental discovery and how
> it's delivered separately?
>
> Also, discovery does not solve the question of authorization-grant
> specific RS endpoint metadata.
>
> On Fri, Jan 22, 2016 at 9:34 AM, Mike Jones 
> wrote:
>
>> Nat, I=E2=80=99m confused by this statement in the message you reference=
 =E2=80=9CUnfortunately,
>> this does not match the value of OAuth issuer defined in Section 2
>> of draft-jones-oauth-mix-up-mitigation-01 nor the 'iss' returned as
>> specified in 3.1. As such, validation as specified in bullet 1 of Sectio=
n 4
>> fails in Google's case -- OR it means that the document is internally
>> inconsistent.=E2=80=9D.  The issuer definition in draft-jones-oauth-disc=
overy is
>> 100% compatible with the one in OpenID Connect Discovery, by design.  In
>> the Google example, both the OpenID issuer and the OAuth issuer values
>> would be the string =E2=80=9Chttps://accounts.google.com=E2=80=9D.  What=
 is the
>> inconsistency that you perceive?
>>
>>
>>
>> The discussion of the duplication problem happened in the private
>> meetings in Yokohama.
>>
>>
>>
>> I will admit, in Yokohama, I didn=E2=80=99t speak up in the public meeti=
ngs to
>> point out that a simpler alternative to oauth-meta was already being
>> discussed there in private, because then I would have had to talk about =
the
>> security issues, which we=E2=80=99d decided not to publicly do at that p=
oint.  So I
>> stayed silent during the poll, out of politeness.  Perhaps I should have
>> found a way to say something then anyway, but that=E2=80=99s water under=
 the bridge
>> now.
>>
>>
>>
>> Finally, for what it=E2=80=99s worth, the HATEOAS stuff reminds me far t=
oo much
>> of Web Services Description Language (WSDL) =E2=80=93 part of the comple=
xity
>> baggage that helped sink Web Services.  The use of =E2=80=9Clink rel=E2=
=80=9D to define an
>> interaction vocabulary and publish endpoints for that vocabulary seems
>> pretty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=
=93 another cute =E2=80=9CWebby=E2=80=9D
>> innovation that never caught on.  The industry has pretty much voted wit=
h
>> its feet and is using JSON for publishing discovery data structures =E2=
=80=93 not
>> =E2=80=9Clink rel=E2=80=9D.  I am against us reverting to the =E2=80=9Cl=
ink rel=E2=80=9D proposal from 2008
>> that never caught on when JSON is simpler and does a better job.
>>
>>
>>
>>                                                                 -- Mike
>>
>>
>>
>> *From:* Nat Sakimura [mailto:sakimura@gmail.com]
>> *Sent:* Thursday, January 21, 2016 6:24 AM
>> *To:* Justin Richer ; Mike Jones <
>> Michael.Jones@microsoft.com>
>> *Cc:* William Denniss ;  <
>> oauth@ietf.org>
>>
>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>
>>
>> Mike,
>>
>>
>>
>> You just criticize my draft. That's ok, but I would really like to get
>> some response to my questions stated in
>> https://www.ietf.org/mail-archive/web/oauth/current/msg15483.html . To
>> me, it just does not seem to work, and the combination of the oauth-meta
>> and PKCE seems to be much more elegan, nicer, and much simpler to
>> implement. If you just give up the dynamic response at the authorization
>> endpoint, then you even do not have to touch the code but just change a
>> config file.
>>
>>
>>
>> Please convince me by answering to my questions.
>>
>>
>>
>> For the record of Yokohama, I do not recall much about duplication in
>> OAuth session. The poll in the room was 19 for / zero against / 4
>> persons need more information. Indeed, it is not duplicating much. And i=
f
>> you move to a new model without pre-configured discovery, it is not
>> duplicating any but the resource endpoint URI, which is optional and is =
for
>> the cases where the client did not know the concrete resource endpoint t=
o
>> start with.
>>
>>
>>
>> I understand your usecases always start from a concrete endpoint
>> location. Mine do not. In a four party model, it is likely not. The user
>> just want to have the service to fetch his data from some resource
>> endpoint. He just hits the service. He does not hit the resource endpoin=
t
>> directly. For example, in the case of a consumer using a personal financ=
e
>> platform (PFP)to manage his pension fund, he hits the PFP and not the
>> Pension fund. Assuming that the pension fund has delegated the
>> authorization control to the authorization server, then, the authorizati=
on
>> server should return both the access token and the endpoint of the pensi=
on
>> fund so that the PFP can pull the data using them. A similar model holds
>> for personal health service and health care providers.
>>
>>
>>
>> Best,
>>
>>
>>
>> Nat
>>
>>
>>
>>
>>
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 21:18 Justin Richer :
>>
>> Convergence is exactly what I=E2=80=99m arguing for, though. These thing=
s ought
>> to work together.
>>
>>
>>
>>  =E2=80=94 Justin
>>
>>
>>
>> On Jan 21, 2016, at 2:55 AM, Mike Jones 
>> wrote:
>>
>>
>>
>> My memory of the discussions of the oauth-meta draft in Yokohama were
>> that many people felt that it was unnecessarily dynamically duplicating =
a
>> lot of information that the client already had.  Most of us that were aw=
are
>> of the attacks then were in favor of a more targeted, minimal approach.
>> You were listened to in Yokohama, but that didn=E2=80=99t necessarily me=
an that
>> people agreed with the approach.  Participants were already aware of the
>> oauth-meta proposal in Darmstadt but no one spoke up in favor of it that=
 I
>> can recall.  Rather, I think people were thinking that =E2=80=9Cless is =
more=E2=80=9D.
>>
>>
>>
>> There have also been discussions in the last day about how dynamically
>> returning a resource URL, which oauth-meta does, is both unnecessary (si=
nce
>> the client initiated the resource authorization already knowing what
>> resource it wants to access) and often problematic, since many
>> authorization servers can authorize access to multiple resources.  If
>> anything, the client should be telling the authorization server what
>> resource it wants to access =E2=80=93 not the other way around.
>>
>>
>>
>> I=E2=80=99m not saying that there aren=E2=80=99t some good ideas in the =
oauth-meta draft
>> =E2=80=93 I=E2=80=99m sure there are, just as there are in the approach =
designed by the
>> participants in Darmstadt.  While I volunteered to write the first draft=
 of
>> the mix-up-mitigation approach, it really reflects something a lot of
>> people have already bought into =E2=80=93 as evidenced in the passion in=
 the
>> high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D thread,=
 and not just my
>> personal project.
>>
>>
>>
>> If you think there are things missing or wrong in the mix-up-mitigation
>> draft, please say what they are.  That will help us quickly converge on =
a
>> solution that will work for everyone.
>>
>>
>>
>>                                                           Sincerely,
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* Nat Sakimura [mailto:sakimura@gmail.com ]
>> *Sent:* Wednesday, January 20, 2016 11:17 PM
>> *To:* Mike Jones ; William Denniss <
>> wdenniss@google.com>; Justin Richer 
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>
>>
>> Hi Mike.
>>
>>
>>
>> Conversely, I would like to ask why this approach does not work for
>> Mix-up attack. As Nov stated, we in fact have discussed the approach in
>> quite a length back in Yokohama. I really would like to know why it does
>> not work.
>>
>>
>>
>> Besides, for oauth-meta approach, mix-up attack is only one of the thing
>> it solves.
>>
>>
>>
>> Nat Sakimura
>>
>>
>>
>> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 16:02 Mike Jones :
>>
>> Not to be negative, but I disagree with adopting
>> draft-sakimura-oauth-meta.  We should define and promote one mitigation
>> approach to the mix-up attacks.  Having two would confuse implementers a=
nd
>> cause compatibility problems =E2=80=93 reducing overall security.
>>
>>
>>
>> The approach defined in draft-jones-oauth-mix-up-mitigation was created
>> in collaboration with the security researchers who identified the proble=
ms
>> in the first place, was vigorously discussed in the security meeting Han=
nes
>> and Torsten held in Darmstadt, and has been since refined based on
>> substantial input from the working group.  And at least three implemente=
rs
>> have already stated that they=E2=80=99ve implemented it.  I=E2=80=99m no=
t saying that it=E2=80=99s,
>> but if there are things missing or things that need to be improved in ou=
r
>> approach, we should do it there, rather introducing a competing approach=
.
>>
>>
>>
>> Also, standard OAuth deployments register the client and then use the
>> information gathered at registration time for subsequent protocol
>> interactions.  They do not need all the configuration information for th=
e
>> authorization server to be retransmitted at runtime.  The oauth-meta dra=
ft
>> goes too far in that direction, at least as I see it.  Returning things =
two
>> ways creates its own problems, as discussed in the Duplicate Information
>> Attacks security considerations section (7.2) of the mix-up-mitigation
>> draft.
>>
>>
>>
>> I=E2=80=99ll note that the mix-up-mitigation approach is compatible with=
 existing
>> practice in both static and dynamic metadata discovery.  Replying to
>> Justin=E2=80=99s comment that =E2=80=9CIt's the pre-configured discovery=
 document that's
>> at the root of the mix-up attack in the first place=E2=80=9D =E2=80=93 t=
his is not the
>> case.  The attacks can be performed without either discovery or dynamic
>> registration.
>>
>>
>>
>> I would be interested in hearing a technical discussion on whether there
>> are aspects of the oauth-meta approach that mitigate aspects of the atta=
cks
>> that the mix-up-mitigation approach does not.  That could help inform
>> whether there are additional things we should add to or change in the
>> mix-up draft.
>>
>>
>>
>>                                                           -- Mike
>>
>>
>>
>> *From:* OAuth [mailto:oauth-bounces@ietf.org] *On Behalf Of *William
>> Denniss
>> *Sent:* Wednesday, January 20, 2016 10:37 PM
>> *To:* Justin Richer 
>> *Cc:* oauth@ietf.org
>> *Subject:* Re: [OAUTH-WG] Call for Adoption
>>
>>
>>
>> +1 to adopt this, and I agree with Justin's comments.
>>
>>
>>
>> On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer  wrote:
>>
>> +1
>>
>> Inline discovery and pre-configured discovery (ie, .well-known) should a=
t
>> the very least be compatible and developed together. It's the
>> pre-configured discovery document that's at the root of the mix-up attac=
k
>> in the first place.
>>
>>  -- Justin
>>
>>
>>
>> On 1/19/2016 10:30 PM, Nat Sakimura wrote:
>>
>> Just to give more context, at IETF 94, I have done a presentation on
>> discovery.
>>
>>
>>
>> According to the minutes,
>>
>>
>>
>>     (f) Discovery (Nat)
>>
>>
>>
>>              Nat explains his document as an example of the work that ha=
s to be done
>>
>>              in the area of discovery, which is a topic that has been id=
entified
>>
>>              as necessary for interoperability since many years but so f=
ar there
>>
>>              was not time to work on it. Mike, John and Nat are working =
on a new
>>
>>              document that describes additional discovery-relevant compo=
nents.
>>
>>
>>
>>              Poll: 19 for / zero against / 4 persons need more informati=
on.
>>
>>
>>
>> The document discussed there was
>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a
>> simple (only 1-page!) but a very powerful document that nudges towards
>> HATEOAS which is at the core of RESTful-ness. It also mitigates the Mix-=
up
>> attack without introducing the concept of issuer which is not in RFC6749=
.
>> It is also good for selecting different endpoints depending on the user
>> authentication and authorization results and more privacy sensitive than
>> pre-announced Discovery document. It also allows you to find to which
>> protected resource endpoint you can use the access token against.
>>
>>
>>
>> In the last sentence of the minutes, it talks about "a new document that
>> describes additional discovery-relevant components". This is
>> https://tools.ietf.org/html/draft-jones-oauth-discovery-00.  It went for
>> the call for adoption. However, it is only a half of the story. I believ=
e
>> https://tools.ietf.org/html/draft-sakimura-oauth-meta-05 that was
>> discussed at IETF 94 and had support there should be adopted as well.
>>
>>
>>
>> Nat Sakimura
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4) 12:05 Nat Sakimura :
>>
>> Thanks Hannes.
>>
>>
>>
>> I did not find https://tools.ietf.org/html/draft-sakimura-oauth-meta-05,=
 which
>> was discussed in Yokohama, and was largely in agreement if my recollecti=
on
>> is correct. Why is it not in the call for adoption?
>>
>>
>>
>>
>>
>>
>>
>> 2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB) 20:39 Hannes Tschofenig :
>>
>> Hi all,
>>
>> we have submitted our new charter to the IESG (see
>> http://www.ietf.org/mail-archive/web/oauth/current/msg15379.html) and
>> since some IESG members like to see an updated list of milestones as
>> well. For this reason, based on a suggestion from Barry, we are also
>> starting a call for adoption concurrently with the review of the charter
>> text by the IESG.
>>
>> We will post separate mails on the individual documents. Your feedback
>> is important! Please take the time to look at the documents and provide
>> your feedback.
>>
>> Ciao
>> Hannes & Derek
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>>
>> OAuth mailing list
>>
>> OAuth@ietf.org
>>
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>>
>

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


Right. OAuth-meta is not only for this particular attack. =
It actually predates the attack by three years. It just happens to mitigate=
 the attack because it is addressing the root issue of decoupled data and m=
eta-data problem.=C2=A0

Re: returning as part of JS=
ON payload, my earlier draft actually contained a way to return the metadat=
a within JSON (see https://tools.ietf.org/html/draft-sakimura-oauth-meta-04).=
 RFC5988 works as long as we are using HTTPS, but once we get to other prot=
ocols, it does not. So we need a way to represent it in native JSON. Swagge=
r is using JSON Schema way of it. I slightly prefer HAL way of it as you ca=
n leverage on the JSON parser directly, making the code shorter, but I am f=
ine either way. I removed all those staff from OAuth-meta because that'=
s not oauth specific, but if people wants it, I can always bring it back.=
=C2=A0

Also,=C2=A0+1 for your point on "discovery does not solve the question of authori=
zation-grant specific RS endpoint metadata."

When I gave the idea back in 2012 in the wo=
rk group meeting, a lot of people said YES, but we needed complete other st=
uff and this thing has been sitting there for 3 years now. IMHO, it should =
be adopted as a WG item now. It will save a lot of headache down the road.=
=C2=A0

Nat<=
/span>

201=
6=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 11:11 William Denniss <wdenniss@google.com>:
These params could also be part=
 of the OAuth2 JSON response payload. Perhaps we should evaluate the concep=
t of incremental discovery and how it's delivered separately?

<=
/div>
Also, discovery does not solve the question of authorization-gran=
t specific RS endpoint metadata.

=

On Fri, Jan 22, 2016 at 9:34 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:











Nat, I=E2=80=99m confused by this sta=
tement in the message you reference =E2=80=9CUnfortunately, this does not match the value
 of OAuth issuer defined in Section 2 of=C2=A0draft-jones-oauth-mix-up-miti=
gation-01 nor the 'iss' returned as specified in 3.1.=C2=A0As such,=
 validation as specified in bullet 1 of Section 4 fails in Google's cas=
e -- OR it means that the document is internally inconsistent.=E2=80=9D.=C2=A0
 The issuer definition in draft-jones-oauth-discovery is 100% compatible wi=
th the one in OpenID Connect Discovery, by design.=C2=A0 In the Google exam=
ple, both the OpenID issuer and the OAuth issuer values would be the string=
 =E2=80=9Chttps:/=
/accounts.google.com=E2=80=9D.=C2=A0 What
 is the inconsistency that you perceive?


=C2=A0


The discussion of the duplication pro=
blem happened in the private meetings in Yokohama.


=C2=A0


I will admit, in Yokohama, I didn=E2=
=80=99t speak up in the public meetings to point out that a simpler alterna=
tive to oauth-meta was already being discussed there in
 private, because then I would have had to talk about the security issues, =
which we=E2=80=99d decided not to publicly do at that point.=C2=A0 So I sta=
yed silent during the poll, out of politeness.=C2=A0 Perhaps I should have =
found a way to say something then anyway, but that=E2=80=99s
 water under the bridge now.


=C2=A0


Finally, for what it=E2=80=99s worth,=
 the HATEOAS stuff reminds me far too much of Web Services Description Lang=
uage (WSDL) =E2=80=93 part of the complexity baggage that helped
 sink Web Services.=C2=A0 The use of =E2=80=9Clink rel=E2=80=9D to define a=
n interaction vocabulary and publish endpoints for that vocabulary seems pr=
etty baroque and reminiscent of =E2=80=9Cmicroformats=E2=80=9D =E2=80=93 an=
other cute =E2=80=9CWebby=E2=80=9D innovation that never caught on.=C2=A0 T=
he industry has pretty
 much voted with its feet and is using JSON for publishing discovery data s=
tructures =E2=80=93 not =E2=80=9Clink rel=E2=80=9D.=C2=A0 I am against us r=
everting to the =E2=80=9Clink rel=E2=80=9D proposal from 2008 that never ca=
ught on when JSON is simpler and does a better job.

=C2=A0


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


=C2=A0


From: Nat Sakimura [mailto:sakimura@gmail.com]


Sent: Thursday, January 21, 2016 6:24 AM

To: Justin Richer <jricher@mit.edu>; Mike Jones <Michael.Jones@microsoft.com>
Cc: William Denniss <wdenniss@google.com>; <oauth@ietf.org> <oauth@ietf.org>


Subject: Re: [OAUTH-WG] Call for Adoption
<=
p>


=C2=A0




Mike,=C2=A0




=C2=A0






You just criticize my draft. That's ok, but I wo=
uld really like to get some response to my questions stated in=C2=A0https://www.ietf.org/mail-archive/web/oauth/current/msg15483.=
html=C2=A0.
 To me, it just does not seem to work, and the combination of the oauth-met=
a and PKCE seems to be much more elegan, nicer, and much simpler to impleme=
nt. If you just give up the dynamic response at the authorization endpoint,=
 then you even do not have to touch
 the code but just change a config file.=C2=A0






=C2=A0






Please convince me by answering to my questions.=C2=
=A0






=C2=A0






For the record of Yokohama, I do not recall much abo=
ut duplication in OAuth session. The poll in the room was=C2=A019 for / zero against / 4 persons need mor=
e information. Indeed, it is not duplicating
 much. And if you move to a new model without pre-configured discovery, it =
is not duplicating any but the resource endpoint URI, which is optional and=
 is for the cases where the client did not know the concrete resource endpo=
int to start with.=C2=A0






=C2=A0






I unders=
tand your usecases always start from a concrete endpoint location. Mine do =
not. In a four party model, it is likely not. The user just want to have th=
e service to fetch his data from some
 resource endpoint. He just hits the service. He does not hit the resource =
endpoint directly. For example, in the case of a consumer using a personal =
finance platform (PFP)to manage his pension fund, he hits the PFP and not t=
he Pension fund. Assuming that the
 pension fund has delegated the authorization control to the authorization =
server, then, the authorization server should return both the access token =
and the endpoint of the pension fund so that the PFP can pull the data usin=
g them. A similar model holds for
 personal health service and health care providers.=C2=A0<=
/u>






=C2=A0






Best,=C2=
=A0






=C2=A0






Nat






=C2=A0






=C2=A0






2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
 21:18 Justin Richer <jricher@mit.edu>:








Convergence is exactly what I=E2=80=99m arguing for,=
 though. These things ought to work together.








=C2=A0






=C2=A0=E2=80=94 Justin










=C2=A0








On Jan 21, 2016, at 2:55 AM, Mike Jones <Michael.Jones@mic=
rosoft.com> wrote:




=C2=A0








My memory of the discussions of the o=
auth-meta draft in Yokohama were that many people felt that it
 was unnecessarily dynamically duplicating a lot of information that the cl=
ient already had.=C2=A0 Most of us that were aware of the attacks then were=
 in favor of a more targeted, minimal approach.=C2=A0 You were listened to =
in Yokohama, but that didn=E2=80=99t necessarily mean
 that people agreed with the approach.=C2=A0 Participants were already awar=
e of the oauth-meta proposal in Darmstadt but no one spoke up in favor of i=
t that I can recall.=C2=A0 Rather, I think people were thinking that =E2=80=
=9Cless is more=E2=80=9D.


=C2=A0


There have also been discussions in t=
he last day about how dynamically returning a resource URL, which
 oauth-meta does, is both unnecessary (since the client initiated the resou=
rce authorization already knowing what resource it wants to access) and oft=
en problematic, since many authorization servers can authorize access to mu=
ltiple resources.=C2=A0 If anything,
 the client should be telling the authorization server what resource it wan=
ts to access =E2=80=93 not the other way around.


=C2=A0


I=E2=80=99m not saying that there are=
n=E2=80=99t some good ideas in the oauth-meta draft =E2=80=93 I=E2=80=99m s=
ure there are, just
 as there are in the approach designed by the participants in Darmstadt.=C2=
=A0 While I volunteered to write the first draft of the mix-up-mitigation a=
pproach, it really reflects something a lot of people have already bought i=
nto =E2=80=93 as evidenced in the passion in
 the high-volume =E2=80=9CMix-Up About The Mix-Up Mitigation=E2=80=9D threa=
d, and not just my personal project.


=C2=A0


If you think there are things missing=
 or wrong in the mix-up-mitigation draft, please say what they
 are.=C2=A0 That will help us quickly converge on a solution that will work=
 for everyone.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 Sincerely,


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


=C2=A0<=
/u>


From: Nat Sakimura [mailto:sakimura@gmail.com]


Sent: Wednesday, January 20, 2016 11:17 PM

To: Mike Jones <Michael.Jones@microsoft.com>; William Denniss <wdenniss@google.com<=
/a>>; Justin Richer <jricher@mit.edu>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Call for Adoption


=C2=A0




Hi Mike.=C2=A0




=C2=A0






Conversely, I would like to ask why this approach do=
es not work for Mix-up attack.=C2=A0As Nov stated, we in fact have discusse=
d the approach in quite a length back in Yokohama. I really
 would like to know why it does not work.=C2=A0






=C2=A0






Besides, for oauth-meta approach, mix-up attack is o=
nly one of the thing it solves.=C2=A0






=C2=A0






Nat Sakimura






=C2=A0






2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8)
 16:02 Mike Jones <Michael.Jones@microsoft.com>:










Not to be negative, but I disagree wi=
th adopting draft-sakimura-oauth-meta.=C2=A0 We should define and promote
 one mitigation approach to the mix-up attacks.=C2=A0 Having two would conf=
use implementers and cause compatibility problems =E2=80=93 reducing overal=
l security.


=C2=A0


The approach defined in draft-jones-o=
auth-mix-up-mitigation was created in collaboration with the security
 researchers who identified the problems in the first place, was vigorously=
 discussed in the security meeting Hannes and Torsten held in Darmstadt, an=
d has been since refined based on substantial input from the working group.=
=C2=A0 And at least three implementers
 have already stated that they=E2=80=99ve implemented it.=C2=A0 I=E2=80=99m=
 not saying that it=E2=80=99s, but if there are things missing or things th=
at need to be improved in our approach, we should do it there, rather intro=
ducing a competing approach.


=C2=A0


Also, standard OAuth deployments regi=
ster the client and then use the information gathered at registration
 time for subsequent protocol interactions.=C2=A0 They do not need all the =
configuration information for the authorization server to be retransmitted =
at runtime.=C2=A0 The oauth-meta draft goes too far in that direction, at l=
east as I see it.=C2=A0 Returning things two ways
 creates its own problems, as discussed in the Duplicate Information Attack=
s security considerations section (7.2) of the mix-up-mitigation draft.


=C2=A0


I=E2=80=99ll note that the mix-up-mit=
igation approach is compatible with existing practice in both static and
 dynamic metadata discovery.=C2=A0 Replying to Justin=E2=80=99s comment tha=
t =E2=80=9CIt's the pre-configured discovery document that's=
 at the root of the mix-up attack in the first place=E2=80=
=9D =E2=80=93 this
 is not the case.=C2=A0 The attacks can be performed without either discove=
ry or dynamic registration.


=C2=A0


I would be interested in hearing a te=
chnical discussion on whether there are aspects of the oauth-meta
 approach that mitigate aspects of the attacks that the mix-up-mitigation a=
pproach does not.=C2=A0 That could help inform whether there are additional=
 things we should add to or change in the mix-up draft.


=C2=A0


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


=C2=A0<=
/u>


From: OAuth [mailto:oauth-bounces@ietf.org]
On Behalf Of William Denniss

Sent: Wednesday, January 20, 2016 10:37 PM

To: Justin Richer <jricher@mit.edu>

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Call for Adoption










=C2=A0




+1 to adopt this, and I agree with Justin's comm=
ents.




=C2=A0




On Wed, Jan 20, 2016 at 9:53 PM, Justin Richer <<=
a href=3D"mailto:jricher@mit.edu" target=3D"_blank">jricher@mit.edu>=
 wrote:






+1



Inline discovery and pre-configured discovery (ie, .well-known) should at t=
he very least be compatible and developed together. It's the pre-config=
ured discovery document that's at the root of the mix-up attack in the =
first place.



=C2=A0-- Justin






=C2=A0<=
/p>



On 1/19/2016 10:30 PM, Nat Sakimura wrote:=









Just to give more context, at IETF 94, I have done a=
 presentation on discovery.=C2=A0





=C2=A0






According to the minutes,=C2=A0






=C2=A0






=C2=A0=C2=A0=C2=A0 (f) Discovery (Nat)=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Nat explains his document as an e=
xample of the work that has to be done


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in the area of discovery, which is a t=
opic that has been identified


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 as necessary for interoperability sinc=
e many years but so far there


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was not time to work on it. Mike, John=
 and Nat are working on a new


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 document that describes additional dis=
covery-relevant components.


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Poll: 19 for / zero against / 4 p=
ersons need more information.


=C2=A0


The document discussed there was

https://tools.ietf.org/html/draft-sakimura-oauth-meta-05. This is a sim=
ple (only 1-page!) but a very powerful document that nudges towards HATEOAS=
 which is at the core of RESTful-ness. It also mitigates the Mix-up attack =
without introducing the concept
 of issuer which is not in RFC6749. It is also good for selecting different=
 endpoints depending on the user authentication and authorization results a=
nd more privacy sensitive than pre-announced Discovery document. It also al=
lows you to find to which protected
 resource endpoint you can use the access token against.=C2=A0






=C2=A0




In the last sentence of the minutes, it talks about =
"a new document that describes additional discovery-relevant component=
s". This is=C2=A0https://tools.ietf.org/html/draft-jones=
-oauth-discovery-00.=C2=A0
 It went for the call for adoption. However, it is only a half of the story=
. I believe=C2=A0https://tools.ietf.org/html/draft-sakimura-oau=
th-meta-05=C2=A0that was discussed at IETF
 94 and had support there=C2=A0should be adopted as well.=C2=A0 <=
/u>




=C2=A0






Nat Sakimura




=C2=A0






=C2=A0






=C2=A0








=C2=A0






2016=E5=B9=B41=E6=9C=8820=E6=97=A5(=E6=B0=B4)
 12:05 Nat Sakimura <sakimura@gmail.com>:








Thanks Hannes.=C2=A0





=C2=A0






I did not find=C2=A0https://tools.ietf.o=
rg/html/draft-sakimura-oauth-meta-05,=C2=A0which was discussed
 in Yokohama, and was largely in agreement if my recollection is correct. W=
hy is it not in the call for adoption?=C2=A0






=C2=A0






=C2=A0






=C2=A0






2016=E5=B9=B41=E6=9C=8819=E6=97=A5(=E7=81=AB)
 20:39 Hannes Tschofenig <hannes.tschofenig@gmx.net>:










Hi all,



we have submitted our new charter to the IESG (see

http://www.ietf.org/mail-archive/web/oauth/current/msg1=
5379.html) and

since some IESG members like to see an updated list of milestones as

well. For this reason, based on a suggestion from Barry, we are also

starting a call for adoption concurrently with the review of the charter
text by the IESG.



We will post separate mails on the individual documents. Your feedback

is important! Please take the time to look at the documents and provide

your feedback.



Ciao

Hannes & Derek



_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth










=C2=A0<=
/p>

_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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




=C2=A0










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth






=C2=A0










_______________________________________________

OAuth mailing list

OAuth@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/oauth
















=C2=A0




















--001a114a7c9c776ad40529e2ef03--


From nobody Thu Jan 21 18:29:25 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26ED1B3668 for ; Thu, 21 Jan 2016 18:29:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU1ix0QShzUG for ; Thu, 21 Jan 2016 18:29:18 -0800 (PST)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4DC1B365F for ; Thu, 21 Jan 2016 18:29:18 -0800 (PST)
Received: by mail-pf0-x235.google.com with SMTP id n128so33459319pfn.3 for ; Thu, 21 Jan 2016 18:29:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=xvOhbSEcXrCuNKqoR8maSYtsMg+Ww9h2xiYQPp/8cyc=; b=T26kJMHzQFxhif6RHmI091fn2sR6k5lW/TALqcvDGg5/ctb2zMQal6JXHTBUOJFdzH nf8dhir651e0PGKlkSBYXgrp/BXo281NBfdDn5AEv4Ymi3qNfF+RlnFSrqUgnRItKcIY 7ozPz6PVL5B8G1lUzm/5QICRfDpvObOF6Yr5ropSTD2LnxpNU1uhZKjyz/+JSqhjGol3 pf0nxK+MB/QoxpouO4yJ+vsTd7nvbSCi6eBaPlYOfLMyYHc92c9syN6o+RCtw+zkdkK+ P2zGUbOCaLq0WhQvfJjJ7AYrKpjpDmSfQ7JnuWNDYwSuQGOclM+sAqm6ZqTfEdhP9f35 kBag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=xvOhbSEcXrCuNKqoR8maSYtsMg+Ww9h2xiYQPp/8cyc=; b=TlZ7oYi9nYseR2n7nveLsph0aOO0lxiusjqGeAFHK/nSIyaPithOIhCWM6cOYx/Z1U DkQ6LPCWjH4tUADDDXtSglBK3k5cvERpaXUYXaPxDIH2VXbHO+vlq+3aZ9w8Kof3TMQY 58YyZrXBsIfX0qi1UP+N9h50MRGHn1mjf4nBraIIikPJTRu+uMIoPFV4zJFE46iOYxXq E6H3zXjsKjtP5WZVI9g2pM2n5uxO83DBkyKjCPgTLD8v/a9Ni1Gt6HHYc3rzoT7L077g 5AX7g1QlR7RQrjixzBp8/iP5m7WrGIb/adPbnmJJgby0p+3bBmHHE68e9DBpIM1bGvA2 Pi0Q==
X-Gm-Message-State: AG10YOT0Gr0cuGtPMXgDegtgO5Mk+G/1S4DDCKxXZHYDT65oWjLTZjKNHBqTQ/cJObyoVg==
X-Received: by 10.98.67.14 with SMTP id q14mr849554pfa.137.1453429758333; Thu, 21 Jan 2016 18:29:18 -0800 (PST)
Received: from tovan.intra.gree-office.net ([27.110.57.140]) by smtp.gmail.com with ESMTPSA id b84sm5469267pfj.25.2016.01.21.18.29.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 18:29:17 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_20CFB7B6-A9CE-4AC1-86F9-EFA0AD873BAB"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Nov Matake 
In-Reply-To: 
Date: Fri, 22 Jan 2016 11:29:15 +0900
Message-Id: 
References:  <5693F276.8020501@aol.com>  <56940CD8.8000701@aol.com>  <569411BF.5090500@pingidentity.com>  <716CAB07-0512-4A58-9002-18BB05C7129B@gmail.com> 
To: Mike Jones 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 02:29:23 -0000

--Apple-Mail=_20CFB7B6-A9CE-4AC1-86F9-EFA0AD873BAB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I agree the state token param solves code/token replace attack.

However, I still don't think it=E2=80=99s a good idea to introduce "iss" =
to OAuth servers which aren't going to support discovery at this point.

For Mix-up mitigation, RP just need to know Token endpoint they should =
use (rel=3Dnext), or AuthZ endpoint they used (rel=3Dself).

So adding =E2=80=9Cturi=E2=80=9D (Token endpoint, rel=3Dnext) and/or =
=E2=80=9Cauri=E2=80=9D (AuthZ endpoint, rel=3Dselft) in the AuthZ =
response and let clients do exact matching with what RP already know =
seems much simpler.
(=E2=80=9Cauri" will be defined in the next Nat=E2=80=99s draft)

nov

On Jan 21, 2016, at 17:03, Mike Jones > wrote:

> Sorry to be slow responding, Nov.  I wanted to wait to respond until a =
draft with the =E2=80=9Cstate=E2=80=9D token request parameter was =
published, which just happened.
> =20
> I think the oauth-meta spec solves some of them but not others.  There =
were a bunch of different attacks discussed by the security researchers =
in Darmstadt (see the notes at =
https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHAlJ6kM5OyeXz=
GptU4/edit#heading=3Dh.od92ummd22zs =
), some with interdependencies =
between them.  There are reasons, for instance, for sending the =
=E2=80=9Cstate=E2=80=9D value to the token endpoint so that the =
authorization server can check it.  The mitigations involve validations =
by both the client and the server =E2=80=93 not all of which the =
oauth-meta draft includes.
> =20
> Also, see the current discussion in the thread =E2=80=9C[OAUTH-WG] =
Call for Adoption=E2=80=9D.  In short, I think there should be one =
solution approach that we work on for this, not two.
> =20
>                                                 Best wishes,
>                                                 -- Mike
> =C2=A0 <>
> From: nov matake [mailto:matake@gmail.com ]=20=

> Sent: Monday, January 11, 2016 10:45 PM
> To: Mike Jones >
> Cc: Hans Zandbelt >; George Fletcher >; oauth@ietf.org 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation
> =20
> Hi Mike,
> =20
> Isn=E2=80=99t Nat=E2=80=99s "OAuth Response Metadata=E2=80=9D spec =
enough to solve those issues?
> https://tools.ietf.org/id/draft-sakimura-oauth-meta-05.txt =

> =20
> On Jan 12, 2016, at 05:40, Mike Jones > wrote:
> =20
> The specification describes this validation method (comparison of the =
issuer received to the issuer recorded at registration time) in step 2 =
of Section 4 (Validating the Response).  In fact, I added this in =
response to your feedback on an earlier draft, Hans.
>=20
> -----Original Message-----
> From: Hans Zandbelt [mailto:hzandbelt@pingidentity.com =
]=20
> Sent: Monday, January 11, 2016 12:34 PM
> To: Mike Jones >; George Fletcher >; oauth@ietf.org 
> Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation
>=20
> I disagree that validating endpoints "at this step" (which refers to =
right before making the token request) should be the default way of =
handling this. The vast majority of OAuth client deployments connecting =
to more than one AS will have a static configuration of the ASes =
issuer/endpoint information anyhow and they just need to confirm that =
the issuer value received in the authorization response is the same =
issuer as that the request was sent to.
>=20
> Hans.
>=20
> On 1/11/16 1:14 PM, Mike Jones wrote:
>=20
> Correct
>=20
> *From:*George Fletcher [mailto:gffletch@aol.com =
]
> *Sent:* Monday, January 11, 2016 12:13 PM
> *To:* Mike Jones >; oauth@ietf.org =

> *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation
>=20
> So just to make sure I understand...
>=20
> This specification requires the response from the Authorization Server
> to an successful /authorize call to pass back code=3D, state=3D and =
jwt=3D (?)
> or individually iss=3D and aud=3D as URL parameters on the 302 to the
> redirect_url. This way, before the client issues a call to the /token
> endpoint (with the code), it can verify that the token endpoint is =
correct.
>=20
> If the client doesn't validate the endpoints at this step, then it =
could
> disclose it's secret to a malicious endpoint. Correct?
>=20
> Thanks,
> George
>=20
> On 1/11/16 2:59 PM, Mike Jones wrote:
>=20
>    The alternatives for the code flow are to return them either in a
>    new JWT added to the reply containing them in the "iss" and "aud"
>    claims or to return them in new individual "client_id" and "iss"
>    authorization response parameters.  Both alternatives are described
>    in the draft.  I'm sure that we'll now be having a good engineering
>    discussion on the tradeoffs between the alternatives.,
>=20
>    In a separate draft, John Bradley will shortly also be describing
>    the possibility of securing the "state" value using a "state_hash"
>    value that works in a way that's similar to how "at_hash" and
>    "c_hash" secure the "access_token" and "code" values in Connect.
>    This would be an alternative means of binding the authorization
>    request and response to the session - accomplishing the same thing
>    that the Connect "nonce" does.
>=20
>    While I fully get that some OAuth implementations want to avoid
>    having to have crypto, it seems like at least support for
>    cryptographic hashing (SHA-256, etc.) may be necessary to mitigate
>    some of these attacks (at least for clients that use more than one
>    authorization server).
>=20
>    The other important engineering discussion I know we're going to
>    have is whether, when an OAuth profile already returns the
>    information needed for the mitigation, whether we want to specify
>    that the client obtain it from the existing location, or whether to
>    also return it in a duplicate location.  I'll note that OpenID
>    Connect already returns the client ID and issuer for the flows that
>    return an ID Token in the authorization response, so this isn't a
>    hypothetical question.
>=20
>    Finally, I know that we'll need to discuss the impact of
>    cut-and-paste attacks when the issuer and client ID are returned as
>    individual authorization response parameters that are not
>    cryptographically bound to the rest of the response.  The
>    cut-and-paste attack that returning the issuer and client_id values
>    as separate parameters enables, even when state_hash or nonce is
>    used, is for the attacker to capture the legitimate response
>    containing "iss" and "client_id" results and substitute different
>    values for these fields, then post that altered response to the
>    legitimate client.  The state and/or nonce values are protected
>    against substitution but "iss" and "client_id" are not.
>=20
>    And yes, I absolutely agree that good examples are essential.
>    That's high on my list for the -01 version.
>=20
>                                                               Thanks a
>    bunch,
>=20
>                                                               -- Mike
>=20
>    *From:*George Fletcher [mailto:gffletch@aol.com =
]
>    *Sent:* Monday, January 11, 2016 10:21 AM
>    *To:* Mike Jones >
>    >; oauth@ietf.org =

>    >
>    *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation
>=20
>    Thanks Mike. One question after reading about the different attack
>    vectors and this spec...
>=20
>    How are the 'iss' and 'aud' values returned with the 'code' and
>    'state' parameters. It seems the client needs to verify the
>    endpoints before making the request to exchange the code for a
>    token. If the client is using the default OAuth2 client_id and
>    client_secret these values will be sent to the malicious endpoint =
if
>    the client can't verify the endpoints before hand.
>=20
>    Also, it would be nice to add some non-normative examples to the =
spec.
>=20
>    Thanks,
>    George
>=20
>    On 1/11/16 4:27 AM, Mike Jones wrote:
>=20
>        Yesterday Hannes Tschofenig announced an OAuth Security =
Advisory
>        on Authorization Server Mix-Up
>        =
>=
.
>        This note announces the publication of the strawman OAuth 2.0
>        Mix-Up Mitigation draft he mentioned that mitigates the attacks
>        covered in the advisory.  The abstract of the specification is:
>=20
>        This specification defines an extension to The OAuth 2.0
>        Authorization Framework that enables an authorization server to
>        provide a client using it with a consistent set of metadata
>        about itself. This information is returned in the authorization
>        response. It can be used by the client to prevent classes of
>        attacks in which the client might otherwise be tricked into
>        using inconsistent sets of metadata from multiple authorization
>        servers, including potentially using a token endpoint that does
>        not belong to the same authorization server as the =
authorization
>        endpoint used. Recent research publications refer to these as
>        "IdP Mix-Up" and "Malicious Endpoint" attacks.
>=20
>        The gist of the mitigation is having the authorization server
>        return the client ID and its issuer identifier (a value defined
>        in the OAuth Discovery specification
>        >) so that the client can verify
>        that it is using a consistent set of authorization server
>        configuration information, that the client ID is for that
>        authorization server, and in particular, that the client is not
>        being confused into sending information intended for one
>        authorization server to a different one.  Note that these
>        attacks can only be made against clients that are configured to
>        use more than one authorization server.
>=20
>        Please give the draft a quick read and provide feedback to the
>        OAuth working group.  This draft is very much a starting point
>        intended to describe both the mitigations and the decisions and
>        analysis remaining before we can be confident in standardizing =
a
>        solution.  Please definitely read the Security Considerations
>        and Open Issues sections, as they contain important information
>        about the choices made and the decisions remaining.
>=20
>        Special thanks go to Daniel Fett (University of Trier),
>        Christian Mainka (Ruhr-University Bochum), Vladislav Mladenov
>        (Ruhr-University Bochum), and Guido Schmitz (University of
>        Trier) for notifying us of the attacks and working with us both
>        on understanding the attacks and on developing mitigations.
>        Thanks too to Hannes Tschofenig for organizing a meeting on =
this
>        topic last month and to Torsten Lodderstedt and Deutsche =
Telekom
>        for hosting the meeting.
>=20
>        The specification is available at:
>=20
>        =
*http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 =

>=20
>        An HTML-formatted version is also available at:
>=20
>        =
*http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-00.html =
=

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

>=20
>=20
>=20
>=20
>    --
>=20
>    Chief Architect
>=20
>    Identity Services Engineering     Work:george.fletcher@teamaol.com =
 >
>=20
>    AOL Inc.                          AIM:  gffletch
>=20
>    Mobile: +1-703-462-3494           =
Twitter:http://twitter.com/gffletch 
>=20
>    Office: +1-703-265-2544           =
Photos:http://georgefletcher.photography =

>=20
>=20
>=20
> --
>=20
> Chief Architect
>=20
> Identity Services Engineering     Work:george.fletcher@teamaol.com =
 >
>=20
> AOL Inc.                          AIM:  gffletch
>=20
> Mobile: +1-703-462-3494           Twitter:http://twitter.com/gffletch =

>=20
> Office: +1-703-265-2544           =
Photos:http://georgefletcher.photography =

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

>=20
> --=20
> Hans Zandbelt              | Sr. Technical Architect
> hzandbelt@pingidentity.com  | Ping =
Identity
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth =

> =20

--Apple-Mail=_20CFB7B6-A9CE-4AC1-86F9-EFA0AD873BAB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


I agree the state token param solves =
code/token replace attack.

However, I still don't think it=E2=80=99s a good idea to =
introduce "iss" to OAuth servers which aren't going to support discovery =
at this point.

For Mix-up mitigation, RP just need to know Token endpoint =
they should use (rel=3Dnext), or AuthZ endpoint they used =
(rel=3Dself).

So=
 adding =E2=80=9Cturi=E2=80=9D (Token endpoint, rel=3Dnext) and/or =
=E2=80=9Cauri=E2=80=9D (AuthZ endpoint, rel=3Dselft) in the AuthZ =
response and let clients do exact matching with what RP already know =
seems much simpler.
(=E2=80=9Cauri" will be defined =
in the next Nat=E2=80=99s draft)

nov

On Jan 21, 2016, at 17:03, =
Mike Jones <Michael.Jones@microsoft.com> wrote:











Sorry to be slow responding, Nov.  I wanted to =
wait to respond until a draft with the =E2=80=9Cstate=E2=80=9D token =
request parameter was published, which just happened.


 


I think the oauth-meta spec solves some of them but =
not others.  There were a bunch of different attacks discussed by =
the security researchers in Darmstadt (see
 the notes at https://docs.google.com/document/d/136Cz2iwUFMdoKWZPCqZRhkmfmHA=
lJ6kM5OyeXzGptU4/edit#heading=3Dh.od92ummd22zs),
 some with interdependencies between them.  There are reasons, for =
instance, for sending the =E2=80=9Cstate=E2=80=9D value to the token =
endpoint so that the authorization server can check it.  The =
mitigations involve validations by both the client and the server =E2=80=93=
 not all
 of which the oauth-meta draft includes.


 


Also, see the current =
discussion in the thread =E2=80=9C[OAUTH-WG] Call for Adoption=E2=80=9D.&n=
bsp; In short, I think there should be one solution approach that we =
work on for this,
 not two.


 


          &nb=
sp;            =
;            &=
nbsp;            =
Best wishes,


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


 







From: nov matake [mailto:matake@gmail.com]


Sent: Monday, January 11, 2016 10:45 PM

To: Mike Jones <Michael.Jones@microsoft.com>

Cc: Hans Zandbelt <hzandbelt@pingidentity.com>; George Fletcher <gffletch@aol.com>; oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up =
Mitigation






 




Hi Mike,






 






Isn=E2=80=99t Nat=E2=80=99s "OAuth Response =
Metadata=E2=80=9D spec enough to solve those issues?




https://tools.ietf.org/id/draft-sakimura-oauth-meta-05.txt<=
o:p class=3D"">




 








On Jan 12, 2016, at 05:40, Mike Jones <Michael.Jones@microsoft.com> wrote:




 




The specification describes this validation method =
(comparison of the issuer received to the issuer recorded at =
registration time) in step 2 of Section 4 (Validating the Response).
  In fact, I added this in response to your feedback on an earlier =
draft, Hans.



-----Original Message-----

From: Hans Zandbelt [mailto:hzandbelt@pingidentity.com] 

Sent: Monday, January 11, 2016 12:34 PM

To: Mike Jones <Michael.Jones@microsoft.com>; George Fletcher <gffletch@aol.com>; oauth@ietf.org

Subject: Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation



I disagree that validating endpoints "at this step" (which refers to =
right before making the token request) should be the default way of =
handling this. The vast majority of OAuth client deployments connecting =
to more than one AS will have a static configuration
 of the ASes issuer/endpoint information anyhow and they just need to =
confirm that the issuer value received in the authorization response is =
the same issuer as that the request was sent to.



Hans.



On 1/11/16 1:14 PM, Mike Jones wrote:








Correct



*From:*George Fletcher [mailto:gffletch@aol.com]

*Sent:* Monday, January 11, 2016 12:13 PM

*To:* Mike Jones <Michael.Jones@microsoft.com>;
oauth@ietf.org

*Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up Mitigation



So just to make sure I understand...



This specification requires the response from the Authorization =
Server

to an successful /authorize call to pass back code=3D, state=3D and jwt=3D=
 (?)

or individually iss=3D and aud=3D as URL parameters on the 302 to the

redirect_url. This way, before the client issues a call to the /token

endpoint (with the code), it can verify that the token endpoint is =
correct.



If the client doesn't validate the endpoints at this step, then it =
could

disclose it's secret to a malicious endpoint. Correct?



Thanks,

George



On 1/11/16 2:59 PM, Mike Jones wrote:



   The alternatives for the code flow are to return them =
either in a

   new JWT added to the reply containing them in the =
"iss" and "aud"

   claims or to return them in new individual "client_id" =
and "iss"

   authorization response parameters.  Both =
alternatives are described

   in the draft.  I'm sure that we'll now be having =
a good engineering

   discussion on the tradeoffs between the =
alternatives.,



   In a separate draft, John Bradley will shortly also be =
describing

   the possibility of securing the "state" value using a =
"state_hash"

   value that works in a way that's similar to how =
"at_hash" and

   "c_hash" secure the "access_token" and "code" values =
in Connect.

   This would be an alternative means of binding the =
authorization

   request and response to the session - accomplishing =
the same thing

   that the Connect "nonce" does.



   While I fully get that some OAuth implementations want =
to avoid

   having to have crypto, it seems like at least support =
for

   cryptographic hashing (SHA-256, etc.) may be necessary =
to mitigate

   some of these attacks (at least for clients that use =
more than one

   authorization server).



   The other important engineering discussion I know =
we're going to

   have is whether, when an OAuth profile already returns =
the

   information needed for the mitigation, whether we want =
to specify

   that the client obtain it from the existing location, =
or whether to

   also return it in a duplicate location.  I'll =
note that OpenID

   Connect already returns the client ID and issuer for =
the flows that

   return an ID Token in the authorization response, so =
this isn't a

   hypothetical question.



   Finally, I know that we'll need to discuss the impact =
of

   cut-and-paste attacks when the issuer and client ID =
are returned as

   individual authorization response parameters that are =
not

   cryptographically bound to the rest of the response. =
 The

   cut-and-paste attack that returning the issuer and =
client_id values

   as separate parameters enables, even when state_hash =
or nonce is

   used, is for the attacker to capture the legitimate =
response

   containing "iss" and "client_id" results and =
substitute different

   values for these fields, then post that altered =
response to the

   legitimate client.  The state and/or nonce values =
are protected

   against substitution but "iss" and "client_id" are =
not.



   And yes, I absolutely agree that good examples are =
essential.

   That's high on my list for the -01 version.



=
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;           &nbs=
p;Thanks a

   bunch,



=
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;           &nbs=
p;-- Mike



   *From:*George Fletcher [mailto:gffletch@aol.com]

   *Sent:* Monday, January 11, 2016 10:21 AM
=

   *To:* Mike Jones <Michael.Jones@microsoft.com>

   <mailto:Michael.Jones@microsoft.com>; oauth@ietf.org

   <mailto:oauth@ietf.org>

   *Subject:* Re: [OAUTH-WG] OAuth 2.0 Mix-Up =
Mitigation



   Thanks Mike. One question after reading about the =
different attack

   vectors and this spec...



   How are the 'iss' and 'aud' values returned with the =
'code' and

   'state' parameters. It seems the client needs to =
verify the

   endpoints before making the request to exchange the =
code for a

   token. If the client is using the default OAuth2 =
client_id and

   client_secret these values will be sent to the =
malicious endpoint if

   the client can't verify the endpoints before hand.



   Also, it would be nice to add some non-normative =
examples to the spec.



   Thanks,

   George



   On 1/11/16 4:27 AM, Mike Jones wrote:



       Yesterday Hannes Tschofenig =
announced an OAuth Security Advisory

       on Authorization Server =
Mix-Up

       <https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJh=
PUm3Fr-w>.

       This note announces the =
publication of the strawman OAuth 2.0

       Mix-Up Mitigation draft he =
mentioned that mitigates the attacks

       covered in the advisory. =
 The abstract of the specification is:



       This specification defines an =
extension to The OAuth 2.0

       Authorization Framework that =
enables an authorization server to

       provide a client using it with =
a consistent set of metadata

       about itself. This information =
is returned in the authorization

       response. It can be used by =
the client to prevent classes of

       attacks in which the client =
might otherwise be tricked into

       using inconsistent sets of =
metadata from multiple authorization

       servers, including potentially =
using a token endpoint that does

       not belong to the same =
authorization server as the authorization

       endpoint used. Recent research =
publications refer to these as

       "IdP Mix-Up" and "Malicious =
Endpoint" attacks.



       The gist of the mitigation is =
having the authorization server

       return the client ID and its =
issuer identifier (a value defined

       in the OAuth Discovery =
specification

       <http://self-issued.info/?p=3D1496>) so that the client =
can verify

       that it is using a consistent =
set of authorization server

       configuration information, =
that the client ID is for that

       authorization server, and in =
particular, that the client is not

       being confused into sending =
information intended for one

       authorization server to a =
different one.  Note that these

       attacks can only be made =
against clients that are configured to

       use more than one =
authorization server.



       Please give the draft a quick =
read and provide feedback to the

       OAuth working group. =
 This draft is very much a starting point

       intended to describe both the =
mitigations and the decisions and

       analysis remaining before we =
can be confident in standardizing a

       solution.  Please =
definitely read the Security Considerations

       and Open Issues sections, as =
they contain important information

       about the choices made and the =
decisions remaining.



       Special thanks go to Daniel =
Fett (University of Trier),

       Christian Mainka =
(Ruhr-University Bochum), Vladislav Mladenov

       (Ruhr-University Bochum), and =
Guido Schmitz (University of

       Trier) for notifying us of the =
attacks and working with us both

       on understanding the attacks =
and on developing mitigations.

       Thanks too to Hannes =
Tschofenig for organizing a meeting on this

       topic last month and to =
Torsten Lodderstedt and Deutsche Telekom

       for hosting the meeting.



       The specification is available =
at:



       *http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-=
00



       An HTML-formatted version is =
also available at:



       *http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigatio=
n-00.html



=
            &n=
bsp;           &nbs=
p;            =
            &n=
bsp;           &nbs=
p;    -- Mike



       P.S.  This note was also =
posted at

       http://self-issued.info/?p=3D1524 and as @selfissued

       <https://twitter.com/selfissued>.











=
       ________________________________=
_______________



       OAuth mailing list



       OAuth@ietf.org <mailto:OAuth@ietf.org>


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









   --



   Chief Architect



   Identity Services Engineering =
    Work:george.fletcher@teamaol.com <mailto:george.fletcher@teamaol.com>



   AOL Inc. =
            &n=
bsp;           &nbs=
p;AIM:  gffletch



   Mobile: +1-703-462-3494 =
          Twitter:http://twitter.com/gffletch



   Office: +1-703-265-2544 =
          Photos:http://georgefletcher.photography







--



Chief Architect



Identity Services Engineering     Work:george.fletcher@teamaol.com <mailto:george.fletcher@teamaol.com>



AOL Inc. =
            &n=
bsp;           &nbs=
p;AIM:  gffletch



Mobile: +1-703-462-3494 =
          Twitter:http://twitter.com/gffletch



Office: +1-703-265-2544 =
          Photos:http://georgefletcher.photography







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






-- 

Hans Zandbelt =
            &n=
bsp;| Sr. Technical Architect

hzandbelt@pingidentity.com |
 Ping Identity



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








 








=

--Apple-Mail=_20CFB7B6-A9CE-4AC1-86F9-EFA0AD873BAB--


From nobody Thu Jan 21 18:40:03 2016
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FC11B369B for ; Thu, 21 Jan 2016 18:40:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFTLf-OsE1Gd for ; Thu, 21 Jan 2016 18:39:57 -0800 (PST)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 57E241B369A for ; Thu, 21 Jan 2016 18:39:57 -0800 (PST)
Received: by mail-pa0-x22d.google.com with SMTP id ho8so33175408pac.2 for ; Thu, 21 Jan 2016 18:39:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=o1rUuk3Nmb2vcdsZUU23zSD+mNRuUO0SlM7xuvQXtX0=; b=ooXwq6zof1YTwBulxcLG4Ct9dsgwVBS/oQF3oyLwWOYBag2nH6O302n14LKUdLfFFc mHkmOHYCKmrzoLXixdW3iCnNitjagZCdL80Dxct3BEGdLbwNfqivpksHDDiqrxifEY72 AWzUtOje5v89fUgzwm3KZhtjpxh3WLLhISnmijxE7esf/7EspeoB9k4mZn6c14R62+dw FtzV5LKD8e9q2b3eUvtSrcswSMRcOIWG25EGXIbCrZmIw0F+9iE057qPtoFbJluM0XHL 1xrzT96SqxFytteY5NND+fTAPYTyPEgKT/RdW/1I5JnrpWNjLWa9KorkiqpydJ3dj/3Q 5NCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=o1rUuk3Nmb2vcdsZUU23zSD+mNRuUO0SlM7xuvQXtX0=; b=liuG/c6daQSogc1C7nU7lr6K/IC4G/bp+1Vp8eUVWDJFhRNI7+yBMcRt/pXEDr+8pJ ovAnl94IWnM25grQK4a08y7PjRfJ0GJiEhvJYVUplo2caxBQB8SKKC2pO6pkSJQ01ga7 0wkj+hnkuPXmnHdQNQwcy4L03NjEtVZXq1gXthiMggVRoxRlbBvNPRzDyAMzS0hKvKmy 79aX8rSK7FLYZ9Myac/Oq0xaG293VUtMe7d1qXmviYQk1miPTDC17uXnuicY/TjNysSa RRBP16URsxCgZgEl4dsW4bm4l1woqEH5aBu8zCL1JRhtDlzo58r5CJx59d5hwQyyLGTs SN2Q==
X-Gm-Message-State: AG10YOTMLKeSXu6pcu1xSmapH2U8NSzuNibTJ1fPv9yItEjvfClCo2cPBm/BMn43Nk6l1Q==
X-Received: by 10.66.102.40 with SMTP id fl8mr937707pab.136.1453430397002; Thu, 21 Jan 2016 18:39:57 -0800 (PST)
Received: from tovan.intra.gree-office.net ([27.110.57.140]) by smtp.gmail.com with ESMTPSA id v2sm5407575pfi.93.2016.01.21.18.39.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 21 Jan 2016 18:39:56 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_ED800867-02A0-4F12-A3B7-4F1FEDE1029D"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: nov matake 
In-Reply-To: 
Date: Fri, 22 Jan 2016 11:39:54 +0900
Message-Id: <2A3855B0-022A-4D34-BEB8-C5E261CE72D7@gmail.com>
References: <569E22E1.5010402@gmx.net>    <537B9D13-1159-4B2D-9E1A-A245C9B3659C@ve7jtb.com>  <2019564A-9F00-4FDA-9AD8-420F9789DF44@ve7jtb.com> 
To: Mike Jones 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 22 Jan 2016 02:40:02 -0000

--Apple-Mail=_ED800867-02A0-4F12-A3B7-4F1FEDE1029D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

If the OAuth server supports discovery, =E2=80=9Ciss=E2=80=9D can be =
used.
If not, attacker=E2=80=99s OAuth server can describe honest OAuth =
server=E2=80=99s =E2=80=9Ciss=E2=80=9D in its developer document.

So returning =E2=80=9Ciss=E2=80=9D would require discovery support NOW, =
not in the future.

> On Jan 22, 2016, at 10:04, Mike Jones  =
wrote:
>=20
> I believe that it=E2=80=99s simpler and more elegant to return an =
issuer, from which the discovery metadata document can be retrieved, =
which contains *all* the configuration information about the =
authorization server, than to return some of the configuration =
parameters but not most of them (which is what the oauth-meta proposal =
does).  There=E2=80=99s lots more in a typical discovery document than =
just a few endpoint addresses.  For instance, there are statements about =
what response types are supported, other configuration choices, keys, =
etc.
> =20
> I also think that returning the issuer is more future-proof than =
trying to decide now what all the configuration information is that =
might want to be verified by the client and hoping we get it right.  =
With the issuer, assuming that discovery is supported, it can retrieve =
and check all of it, should the client want/need to do so.  Even when =
discovery isn=E2=80=99t supported, the issuer still provides a concrete =
identifier for the authorization server that can be checked for =
equality.
> =20
> We talked about the value of that approach in the side meetings in =
Yokohama and people were supportive then.
> =20
>                                                                 -- =
Mike
> =20
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley
> Sent: Thursday, January 21, 2016 4:48 PM
> To: Nat Sakimura 
> Cc: oauth@ietf.org WG 
> Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation
> =20
> I will point out for clarification that this would be like IdP =
discovery in openID 2 that everyone did.  I think IdP not doing RP =
discovery in openID 2 is a weak argument.
> There may be other evidence that RP will not do discovery, but if that =
is the case why are we doing a OAuth discovery spec? =20
> Many people see your spec as discovery as well just in a different =
way.
> =20
> I think both ways can work, but doing both leaves too many options.=20
> =20
> John B.
> =20
> =20
> On Jan 21, 2016, at 9:38 PM, Nat Sakimura > wrote:
> =20
> Still doing the analysis. We spent 1.5 hours today with John, George, =
nov and me on the OpenID Connect WG call on this issue. John explained =
the mitigation, but none of us was convinced that it works.=20
> =20
> Then, after the call, I and nov went on with various scenarios. The =
interim conclusion is that:=20
> client_id response parameter does not help. There are legitimate cases =
that client_id duplicates out there and we cannot ban that. =20
> iss response parameter does not help unless the discovery is performed =
and the value of iss is checked against the value of OAuth issuer inside =
the document. (<- Discovery becomes mandatory. =46rom our experience on =
RP discovery step in OpenID 2.0, chance of this being done properly =
seems to be rather slim.)=20
> sending the state to the token endpoint helps in the case code was =
stollen, but code should not be stolen to start with.=20
> Cheers,=20
> =20
> Nat
> =20
> =20
> 2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John Bradley =
>:
> There have been a lot of discussions. I think Hannes posted some =
minutes of the F2F meeting we had with the security researchers.
> =20
> The problem can=E2=80=99t be mitigated without some action on the =
client side.  It boils down to the client making a request to AS1 (=46rom =
it=E2=80=99s perspective) and getting back a response from AS 2 (that it =
thinks is AS1)
> =20
> This can be done if AS1 is a good AS but has it=E2=80=99s logs =
compromised so that an attacker can read them. Hans Zandbelt built a =
proof of concept for the attack.=20
> =20
> In some cases the attacker gets the code and the credential to use it =
at the good AS token endpoint and in others it just gets the code and =
can replay that at the client to extract information from the API =
through the client by binding the api access to a new account.
> =20
> PKCE unfortunately mitigates a different attack, where the client is =
impersonated and trys to replay a intercepted code.  It however assumes =
the token endpoint is good, and is no help in the case of a compromised =
token endpoint.
> =20
> The client in these attacks is vulnerable because it relies on some =
local state, or the value of the state parameter to know who the =
response is coming from.  This allows a authorization request that is =
intercepted to be used to create a new request in that browser to a =
different AS, or trick the client into using a Authorization endpoint =
for a different authorization server.
> =20
> One problem is that OAuth doesn=E2=80=99t really have a unified =
concept of what a AS is.  Traditionally it is a Authorization endpoint =
URI, token end point URI and resource server URI that some one gives the =
client in some documentation.  =20
> =20
> As ling as a client only talks to one AS then there is no problem.   =
However once a client is configured to talk to more than one AS, we have =
problems if one of those AS lies about it=E2=80=99s endpoints, or is =
compromised and used to attack another AS.   As a design goal you =
don=E2=80=99t want the overall  security to be limited by the weakest =
system.
> =20
> One approach as Nat promotes is to have the authorization endpoint =
return the next hop, token endpoint for code or RS URI for token. The =
token endpoint must also return the RS URI or the client must push the =
RS URI to the token endpoint or the attacker just replaces the RS URI in =
the config and captures the token that way.=20
> =20
> The other way is to provide a name for each AS as part of registration =
and the client not allow duplicate registrations with the same name.  =
When the response comes back the client checks the name against the one =
it made the request to.  If the name dereferences to a discovery =
document then the client can check that name at registration or runtime =
to validate the net hops.
> =20
> I think the two approaches mitigate the attack in similar ways.  =
Nat=E2=80=99s is more REST friendly and returns the next hop as a =
parameter of header. =20
> =20
> The one Mike and I wrote up based on the meeting in Germany provides =
identifiers (iss and client_id) that can be checked for validity in the =
simple case and be dereferenced via .well-known to get the information =
Nat=E2=80=99s proposal is providing.
> =20
> Perhaps the main difference is Nat is using the token endpoint as the =
identifier for the AS and Mike=E2=80=99s is using location for a =
discovery document as the identifier.
> =20
> I don=E2=80=99t recall the reasons using the token endpoint as the =
identifier was rejected at the meeting.  Perhaps others can post the =
reasons.
> =20
> We need to close on this quickly, otherwise if we are indecisive fixes =
will not go into products for another year or so until this is a RFC.
> =20
> That is my main concern.
> =20
> John B.
> =20
> =20
> =20
> =20
> =20
> On Jan 21, 2016, at 11:50 AM, Josh Mandel > wrote:
> =20
> Thanks Nat - that's helpful. If both mitigations *can* work =
effectively, then I would like to see this group consider the decision =
between them carefully (if that hasn't happened yet). Again, don't =
hesitate to let me know if this is the wrong place/time for such =
discussion.
> At a high level, I would rather ask server developers to do some =
"coding", for two reasons:
> 1. Most OAuth servers talk to many, many clients. So consolidating the =
security critical work in one place (server) is a net savings of work =
(rather than asking each client to implement these checks.=20
> 2. OAuth server developers are typically more sophisticated than =
client developers, and therefore more likely to understand the =
implications and more likely to get these critical details correct. =
Asking each client developer to do something right is likely to result =
in heterogenius implementation and persistent security holes. But if the =
server does the heavy lifting, and clients just have to pass along an =
extra parameter, this is more likely to see consistent implementation =
(for example, clients will fail to work if misconfigured, which will =
prompt developers to fix them).
> On Jan 21, 2016 09:40, "Nat Sakimura" > wrote:
> Hi Josh,=20
> =20
> It is similar but slightly different IMHO.=20
> =20
> Section 4.6.4 of the RFC6819 is the access token phishing by a =
counterfeit resource server.=20
> The mix-up attack described here is the code phishing by a counterfeit =
token endpoint.=20
> =20
> In my view, both can be mitigated by the server returning the next =
step: i.e., authorization endpoint returning the legitimate token =
endpoint uri, and token endpoint returning legitimate resource endpoint =
uris. This involves no discovery endpoint, which is good.=20
> =20
> Your way also works. It is just the reverse of my proposal. The =
difference being that my proposal does not need any coding on the server =
but just configuration, and it can return more metadata if needed.=20
> =20
> Cheers,=20
> =20
> Nat
> =20
> 2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel =
>:
> Apologies if this is the wrong forum for my comment (and please direct =
me to the appropriate place in that case), but I have two questions =
about the propose mitigation (and the thinking behind it) that I think =
the write-up could address:
> 1. Could the writeup clarify whether/how the primary "mixup" threat =
differs from what RFC6819 identifies as in section 4.6.4?
> 2. Has the workgroup considered a mitigation that puts more =
responsibility on the authorization server, and less on the client? For =
example, if would be helpful for the writeup to clarify why having the =
client send an "audience field" (in the terminology of RFC6819) to the =
authorization endpoint would not mitigate the threat. (In that scenario, =
the authorization server can recognize that the audience does not =
correspond to a resource server it knows, rather than asking clients to =
make this check). I assume this approach has been considered and =
rejected as an incomplete mitigation, but I don't have visibility into =
where/how that discussion went.
> Thanks,
> Josh
> Hi all,
>=20
> this is the call for adoption of OAuth 2.0 Mix-Up Mitigation, see
> https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-00 =

>=20
> Please let us know by Feb 9th whether you accept / object to the
> adoption of this document as a starting point for work in the OAuth
> working group.
>=20
> Note: This call is related to the announcement made on the list =
earlier
> this month, see
> http://www.ietf.org/mail-archive/web/oauth/current/msg15336.html =
. More
> time for analysis is provided due to the complexity of the topic.
>=20
> Ciao
> Hannes & Derek
>=20
>=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 =

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

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


--Apple-Mail=_ED800867-02A0-4F12-A3B7-4F1FEDE1029D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

If the OAuth server supports discovery, =E2=80=9Ciss=E2=80=9D =
can be used.
If not, attacker=E2=80=99s OAuth server can =
describe honest OAuth server=E2=80=99s =E2=80=9Ciss=E2=80=9D in its =
developer document.

So returning =E2=80=9Ciss=E2=80=9D would require discovery =
support NOW, not in the future.

On =
Jan 22, 2016, at 10:04, Mike Jones <Michael.Jones@microsoft.com> wrote:

I =
believe that it=E2=80=99s simpler and more elegant to return an issuer, =
from which the discovery metadata document can be retrieved, which =
contains *all* the configuration information about the =
authorization server, than to return some of the configuration =
parameters but not most of them (which is what the oauth-meta proposal =
does).  There=E2=80=99s lots more in a typical discovery document =
than just a few endpoint addresses.  For instance, there are =
statements about what response types are supported, other configuration =
choices, keys, etc.
 
I also think that =
returning the issuer is more future-proof than trying to decide now what =
all the configuration information is that might want to be verified by =
the client and hoping we get it right.  With the issuer, assuming =
that discovery is supported, it can retrieve and check all of it, should =
the client want/need to do so.  Even when discovery isn=E2=80=99t =
supported, the issuer still provides a concrete identifier for the =
authorization server that can be checked for equality.
 
We =
talked about the value of that approach in the side meetings in Yokohama =
and people were supportive then.
 
          &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;            =
;    -- Mike
 
From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf =
Of John Bradley
Sent: Thursday, January 21, 2016 =
4:48 PM
To: Nat Sakimura <sakimura@gmail.com>
Cc: oauth@ietf.org WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Call for =
Adoption: OAuth 2.0 Mix-Up Mitigation
 
I will point out for clarification that this would be like =
IdP discovery in openID 2 that everyone did.  I think IdP not doing =
RP discovery in openID 2 is a weak argument.
There may be other evidence that RP will not do discovery, =
but if that is the case why are we doing a OAuth discovery spec? =
 
Many people see your spec as discovery as =
well just in a different way.
 
I think both ways can work, but doing both leaves too =
many options. 
 
John B.
 
 
On =
Jan 21, 2016, at 9:38 PM, Nat Sakimura <sakimura@gmail.com> =
wrote:
 
Still doing the =
analysis. We spent 1.5 hours today with John, George, nov and me on the =
OpenID Connect WG call on this issue. John explained the mitigation, but =
none of us was convinced that it works. 
 
Then, after the call, I and nov went on =
with various scenarios. The interim conclusion is that: 
  • client_id response parameter does not help. There are =
legitimate cases that client_id duplicates out there and we cannot ban =
that.  
  • iss response parameter does not help unless the =
discovery is performed and the value of iss is checked against the value =
of OAuth issuer inside the document. (<- Discovery becomes mandatory. =
=46rom our experience on RP discovery step in OpenID 2.0, chance of this =
being done properly seems to be rather slim.) 
  • sending the state to the token endpoint helps in the case =
code was stollen, but code should not be stolen to start with. 
Cheers, 
 
Nat
 
 
2016=E5=B9=B41=E6=9C=8822=E6=97=A5(=E9=87=91) 7:59 John =
Bradley <ve7jtb@ve7jtb.com>:
There have been a lot of discussions. I =
think Hannes posted some minutes of the F2F meeting we had with the =
security researchers.
 
The problem can=E2=80=99t be mitigated without some =
action on the client side.  It boils down to the client making a =
request to AS1 (=46rom it=E2=80=99s perspective) and getting back a =
response from AS 2 (that it thinks is AS1)
 
This can be done if AS1 is a good AS but =
has it=E2=80=99s logs compromised so that an attacker can read them. =
Hans Zandbelt built a proof of concept for the attack. 
 
In some cases the attacker gets the code =
and the credential to use it at the good AS token endpoint and in others =
it just gets the code and can replay that at the client to extract =
information from the API through the client by binding the api access to =
a new account.
 
PKCE unfortunately mitigates a different attack, =
where the client is impersonated and trys to replay a intercepted =
code.  It however assumes the token endpoint is good, and is no =
help in the case of a compromised token endpoint.
 
The client in these attacks is vulnerable =
because it relies on some local state, or the value of the state =
parameter to know who the response is coming from.  This allows a =
authorization request that is intercepted to be used to create a new =
request in that browser to a different AS, or trick the client into =
using a Authorization endpoint for a different authorization server.
 
One problem is that OAuth doesn=E2=80=99t =
really have a unified concept of what a AS is.  Traditionally it is =
a Authorization endpoint URI, token end point URI and resource server =
URI that some one gives the client in some documentation. =
  
 
As ling as a client only talks to one AS then there =
is no problem.   However once a client is configured to talk to =
more than one AS, we have problems if one of those AS lies about it=E2=80=99=
s endpoints, or is compromised and used to attack another AS.   As =
a design goal you don=E2=80=99t want the overall  security to be =
limited by the weakest system.
 
One approach as Nat promotes is to have the =
authorization endpoint return the next hop, token endpoint for code or =
RS URI for token. The token endpoint must also return the RS URI or the =
client must push the RS URI to the token endpoint or the attacker just =
replaces the RS URI in the config and captures the token that =
way. 
 
The other way is to provide a name for each AS as =
part of registration and the client not allow duplicate registrations =
with the same name.  When the response comes back the client checks =
the name against the one it made the request to.  If the name =
dereferences to a discovery document then the client can check that name =
at registration or runtime to validate the net hops.
 
I think the two approaches mitigate the =
attack in similar ways.  Nat=E2=80=99s is more REST friendly and =
returns the next hop as a parameter of header.  
 
The one Mike and I wrote up based on the =
meeting in Germany provides identifiers (iss and client_id) that can be =
checked for validity in the simple case and be dereferenced via =
.well-known to get the information Nat=E2=80=99s proposal is =
providing.
 
Perhaps the main difference is Nat is using the token =
endpoint as the identifier for the AS and Mike=E2=80=99s is using =
location for a discovery document as the identifier.
 
I don=E2=80=99t recall the reasons using =
the token endpoint as the identifier was rejected at the meeting.  =
Perhaps others can post the reasons.
 
We need to close on this quickly, otherwise if we are =
indecisive fixes will not go into products for another year or so until =
this is a RFC.
 
That is my main concern.
 
John B.
 
 
 
 
 
On Jan 21, 2016, at =
11:50 AM, Josh Mandel <jmandel@gmail.com> wrote:
 
Thanks Nat - that's helpful. If both mitigations *can* work =
effectively, then I would like to see this group consider the decision =
between them carefully (if that hasn't happened yet). Again, don't =
hesitate to let me know if this is the wrong place/time for such =
discussion.
At a high level, I would rather ask server developers to do =
some "coding", for two reasons:
1. Most OAuth servers talk to many, many =
clients. So consolidating the security critical work in one place =
(server) is a net savings of work (rather than asking each client to =
implement these checks. 
2. =
OAuth server developers are typically more sophisticated than client =
developers, and therefore more likely to understand the implications and =
more likely to get these critical details correct. Asking each client =
developer to do something right is likely to result in heterogenius =
implementation and persistent security holes. But if the server does the =
heavy lifting, and clients just have to pass along an extra parameter, =
this is more likely to see consistent implementation (for example, =
clients will fail to work if misconfigured, which will prompt developers =
to fix them).
On Jan 21, 2016 09:40, "Nat Sakimura" =
<sakimura@gmail.com> wrote:
Hi =
Josh, 
 
It is similar but slightly different IMHO. 
 
Section 4.6.4 of the RFC6819 is the =
access token phishing by a counterfeit resource server. 
The mix-up attack described here is the code phishing by a =
counterfeit token endpoint. 
 
In my view, both can be mitigated by the server =
returning the next step: i.e., authorization endpoint returning the =
legitimate token endpoint uri, and token endpoint returning legitimate =
resource endpoint uris. This involves no discovery endpoint, which is =
good. 
 
Your way also works. It is just the reverse of my =
proposal. The difference being that my proposal does not need any coding =
on the server but just configuration, and it can return more metadata if =
needed. 
 
Cheers, 
 
Nat
 
2016=E5=B9=B41=E6=9C=8821=E6=97=A5(=E6=9C=A8) 23:04 Josh Mandel <jmandel@gmail.com>:
Apologies if this is the wrong forum for my comment (and =
please direct me to the appropriate place in that case), but I have two =
questions about the propose mitigation (and the thinking behind it) that =
I think the write-up could address:
1. Could the writeup clarify whether/how =
the primary "mixup" threat differs from what RFC6819 identifies as in =
section 4.6.4?
2. Has the workgroup considered a mitigation that puts more =
responsibility on the authorization server, and less on the client? For =
example, if would be helpful for the writeup to clarify why having the =
client send an "audience field" (in the terminology of RFC6819) to the =
authorization endpoint would not mitigate the threat. (In that scenario, =
the authorization server can recognize that the audience does not =
correspond to a resource server it knows, rather than asking clients to =
make this check). I assume this approach has been considered and =
rejected as an incomplete mitigation, but I don't have visibility into =
where/how that discussion went.
Thanks,
Josh
Hi all,

this is the call for =
adoption of OAuth 2.0 Mix-Up Mitigation, see
https://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation=
-00

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

Note: This call is related to the =
announcement made on the list earlier
this month, see
http://www.ietf.org/mail-archive/web/oauth/current/msg15336.htm=
l. More
time for analysis is provided due to the =
complexity of the topic.

Ciao
Hannes & Derek


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

On =
Jan 26, 2016, at 08:22, Phil Hunt <phil.hunt@oracle.com> wrote:

Sorry, meant =
to reply-all.











Begin forwarded message:

From: Phil Hunt <phil.hunt@oracle.com>
Subject: Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up =
Mitigation
Date: January 25, 2016 at 3:20:19 PM PST
To: Nat Sakimura <sakimura@gmail.com>

I am having trouble with the very first =
assumption. The user-agent sets up a non TLS protected connection to the =
RP? That=E2=80=99s a fundamental violation of 6749.

Also, the second statement says the RP =
(assuming it acts as OAuth client) is talking to two IDPs. =
 That=E2=80=99s still a multi-AS case is it not?










On Jan 25, 2016, at 2:58 PM, Nat Sakimura <sakimura@gmail.com> =
wrote:

Hi Phil, 

Since I was not in Darmstadt, I really =
do not know what was discussed there, but with the compromised developer =
documentation described in http://nat.sakimura.org/2016/01/15/idp-mix-up-attack-on-oauth-r=
fc6749/, all RFC6749 clients with a naive implementer will be =
affected. The client does not need to be talking to multiple =
IdPs. 

Nat

2016=E5=B9=B41=E6=9C=882=
6=E6=97=A5(=E7=81=AB) 3:58 Phil Hunt (IDM) <phil.hunt@oracle.com>:
I recall making this point in Germany. 99% of =
existing use is fine. OIDC is probably the largest community that =
*might* have an issue.



I recall proposing a new security document that covers oauth security =
for dynamic scenarios. "Dynamic" being broadly defined to mean:

* clients who have configured at runtime or install time (including =
clients that do discovery)

* clients that communicate with more than one endpoint

* clients that are deployed in large volume and may update frequently =
(more discussion of "public" cases)

* clients that are script based (loaded into browser on the fly)

* others?



Phil



> On Jan 25, 2016, at 10:39, George Fletcher <gffletch@aol.com> wrote:

>

> would



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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